| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
It's so confusing to have everything having the same name, at least while refactoring.
|
|
|
|
Add existential type definitions
Note: this does not allow creating named existential types, it just desugars `impl Trait` to a less (but still very) hacky version of actual `existential type` items.
r? @nikomatsakis
|
|
Fixed minor error in Compiler Error Index, E0603.
|
|
|
|
|
|
Fix for $crate var normalization in proc macro for externally defined macros
Fixes #51331, a bug that has existed in at least *some* form for a year and a half.
The PR includes the addition of a `fold_qpath` method to `syntax::fold::Folder`. Overriding this method is useful for folds that modify paths in a way that invalidates indices (insertion or removal of a component), as it provides the opportunity to update `qself.position` in `<A as B>::C` paths. I added it because the bugfix is messy without it.
(unfortunately, grepping around the codebase, I did not see anything else that could use it.)
|
|
|
|
|
|
Update E0423 description
E0423 doesn't apply only to structs, update the error index description
to make this clear.
Fix #42077.
|
|
E0423 doesn't apply only to structs, update the error index description
to make this clear.
|
|
Suggest parentheses when a struct literal needs them
When writing a struct literal in an expression that expects a block to
be started afterwards (like an `if` statement), do not suggest using the
same struct literal:
```
did you mean `S { /* fields * /}`?
```
Instead, suggest surrounding the expression with parentheses:
```
did you mean `(S { /* fields * /})`?
```
Fix #47360, #50090. Leaving #42982 open to come back to this problem with a better solution.
|
|
Add deprecation lint for duplicated `macro_export`s
cc https://github.com/rust-lang/rust/issues/35896#issuecomment-381370556
|
|
|
|
When writing a struct literal in an expression that expects a block to
be started afterwards (like an `if` statement), do not suggest using the
same struct literal:
```
did you mean `S { /* fields * /}`?
```
Instead, suggest surrounding the expression with parentheses:
```
did you mean `(S { /* fields * /})`?
```
|
|
|
|
Fixes #50605
|
|
generate errors
|
|
|
|
|
|
|
|
impl Trait diagnostic/test cleanups
|
|
|
|
r=alexcrichton
Issue 50970 migration lint fq path
Similar issue, but for fully qualified paths.
Fixes #50970
r? @alexcrichton
|
|
|
|
fixes #50970
|
|
|
|
|
|
This commit fixes another issue in the `absolute_path_not_starting_with_crate`
lint where it warns twice about an import which may contain `self`. It turns out
there were a few more locations that needed updating to use `root_id` and
`root_span` introduced in #50970 and after that it looks to work like a charm!
Closes #50978
|
|
r=alexcrichton
fix suggestions with nested paths
Fixes #50673
cc @Manishearth @petrochenkov
r? @alexcrichton
|
|
|
|
|
|
|
|
rustc: introduce {ast,hir}::AnonConst to consolidate so-called "embedded constants".
Previously, constants in array lengths and enum variant discriminants were "merely an expression", and had no separate ID for, e.g. type-checking or const-eval, instead reusing the expression's.
That complicated code working with bodies, because such constants were the only special case where the "owner" of the body wasn't the HIR parent, but rather the same node as the body itself.
Also, if the body happened to be a closure, we had no way to allocate a `DefId` for both the constant *and* the closure, leading to *several* bugs (mostly ICEs where type errors were expected).
This PR rectifies the situation by adding another (`{ast,hir}::AnonConst`) node around every such constant. Also, const generics are expected to rely on the new `AnonConst` nodes, as well (cc @varkor).
* fixes #48838
* fixes #50600
* fixes #50688
* fixes #50689
* obsoletes #50623
r? @nikomatsakis
|
|
|
|
constants".
|
|
Add lint checks for unused loop labels
Previously no warning was generated when a loop label was written out but never used (i.e. in a `break` or `continue` statement):
```rust
fn main() {
'unused_label: loop {}
}
```
would compile without complaint.
This fix introduces `-W unused_loop_label`, which generates the following warning message for the above snippet:
```
warning: unused loop label
--> main.rs:2:5
|
2 | 'unused_label: loop {}
| ^^^^^^^^^^^^^
|
= note: #[warn(unused_loop_label)] on by default
```
Fixes: #50751.
|
|
Turn deprecation lint `legacy_imports` into a hard error
Closes https://github.com/rust-lang/rust/issues/38260
The lint was introduced in Dec 2016, then made deny-by-default in Jun 2017 when crater run found 0 regressions caused by it.
This lint requires some not entirely trivial amount of import resolution logic that (surprisingly or not) interacts with `feature(use_extern_macros)` (https://github.com/rust-lang/rust/issues/35896), so it would be desirable to remove it before stabilizing `use_extern_macros`.
In particular, this PR fixes the failing example in https://github.com/rust-lang/rust/issues/50725 (but not the whole issue, `use std::panic::{self}` still can cause other undesirable errors when `use_extern_macros` is enabled).
|
|
|
|
|
|
|
|
|
|
rustc: Fix `crate` lint for single-item paths
This commit fixes recommending the `crate` prefix when migrating to 2018 for
paths that look like `use foo;` or `use {bar, baz}`
Closes #50660
|
|
No error checking or feature gating yet
|
|
This commit fixes recommending the `crate` prefix when migrating to 2018 for
paths that look like `use foo;` or `use {bar, baz}`
Closes #50660
|
