Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove hack around requiring Sized bound in collect.rs #13367

Closed
nrc opened this issue Apr 7, 2014 · 0 comments · Fixed by #15521
Closed

Remove hack around requiring Sized bound in collect.rs #13367

nrc opened this issue Apr 7, 2014 · 0 comments · Fixed by #15521

Comments

@nrc
Copy link
Member

nrc commented Apr 7, 2014

Requires a snapshot which supports type as a generalisation marker.

@nrc nrc mentioned this issue Apr 7, 2014
23 tasks
nrc added a commit to nrc/rust that referenced this issue Jul 8, 2014
closes rust-lang#13367

[breaking-change] Use `Sized?` to indicate a dynamically sized type parameter or trait (used to be `type`). E.g.,

```
trait Tr for Sized? {}

fn foo<Sized? X: Share>(x: X) {}
```
bors added a commit that referenced this issue Jul 8, 2014
closes #13367

[breaking-change] Use `Sized?` to indicate a dynamically sized type parameter or trait (used to be `type`). E.g.,

```
trait Tr for Sized? {}

fn foo<Sized? X: Share>(x: X) {}
```
bors added a commit to rust-lang-ci/rust that referenced this issue Oct 18, 2022
fix: in VSCode, correctly resolve relative paths to errors

VS Code problem matcher are restricted to be static "regexes". You can't create a problem matcher dynamically, and you can't use custom code in lieu of problem matcher.

This creates a problem for rust/cargo compiler errors. They use paths relative to the root of the Cargo workspace, but VS Code doesn't necessary know where that root is.

Luckily, there's a way out: our current problem matcher is defined like this:

    "fileLocation": [ "autoDetect", "${workspaceRoot}" ],

That means that relative pahts would be resoleved relative to workspace root. VS Code allows to specify a command inside `${}`. So we can plug custom logic there to fetch Cargo's workspace root!

And that's exactly what this PR is doing!
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 24, 2024
Visit struct fields recursively in uninit fallback check

This makes the fallback a bit more consistent with the other checks and rustc.

Fixes rust-lang#13364. When using a generic type as the `Vec` element type like the issue title says, rustc's uninit check fails and our fallback is used, which didn't look at struct fields when it could.

changelog: none
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant