Do not promote union field accesses
r? @eddyb
technically a breaking change, but the code errored on the previous stable and produces UB + a warning on the current stable. I don't think we need a crater run in that case.
merge unused-extern-crate and unnecessary-extern-crate lints
Extend the `unused_extern_crates` lint to offer a suggestion to remove the extern crate and remove the `unnecessary_extern_crate` lint.
Still a few minor issues to fix:
- [x] this *does* now leave a blank line... (defer to https://github.com/rust-lang/rust/issues/51176)
- idea: extend the span to be replaced by 1 character if the next character is a `\n`
- [x] what about macros? do we need to watch out for that? (defer to https://github.com/rust-lang/rust/issues/48704)
- [x] also it doesn't work for `extern crate foo; fn main() { foo::bar(); }`
- this is subtle: the `foo` might be shadowing a glob import too, can't always remove
- defer to https://github.com/rust-lang/rust/issues/51177
- [x] we also don't do the `pub use` rewrite thang (https://github.com/rust-lang/rust/issues/51013)
Spun off from https://github.com/rust-lang/rust/pull/51010Fixes#50672
r? @alexcrichton
Tweak output on E0599 for assoc fn used as method
- Use suggestion instead of `help` when possible
- Add primary span label
- Remove incorrect `help` suggestion using incorrect syntax
- Do not refer to only one possible candidate as `candidate #1`, refer to it as `the candidate`
Register outlives predicates from queries the right way around.
Closes#49354
The region constraints from queries need to be reversed from sub to outlives.
Note: wf checking reports these errors before NLL, so I'm not sure if there's any case when these predicates need to be created at all.
cc @nikomatsakis
remove notion of Implicit derefs from mem-cat
`PointerKind` is included in `LoanPath` and hence forms part of the equality check; this led to having two unequal paths that both represent `*x`, depending on whether the `*` was inserted automatically or explicitly. Bad mojo.
Fixes#51117
r? @eddyb
`PointerKind` is included in `LoanPath` and hence forms part of the
equality check; this led to having two unequal paths that both
represent `*x`, depending on whether the `*` was inserted
automatically or explicitly. Bad mojo. The `note` field, in contrast,
is intended more-or-less primarily for this purpose of adding extra
data.
reset anonymous-lifetime-mode as we enter `()` scopes
Background:
The anonymous lifetime mode is used to prohibit elided lifetimes where
they didn't used to be permitted, and instead require that `'_` be
used. For example:
```rust
impl Trait for Ref<T> { .. }
// ^^^^^^ ERROR: should be `Ref<'_, T>`
```
When we are parsing the parts of the impl header, we enter into an alternate mode called `CreateParameter`. In this mode, we give an error for things like `Ref<T>`, but for elided lifetimes in a reference type like `&T` we make the elided lifetime into an in-band lifetime:
4f99f37b7e/src/librustc/hir/lowering.rs (L4017-L4035)
This was not intended to change behavior because we only enter into that mode in contexts where elision was not historically permitted. However, the problem is that we fail to reset the mode when we enter into bounds like `Fn(&u32)`, where elision *was* allowed -- the same occurs for fn types like `fn(&u32`). This PR restores the original mode in those contexts.
Fixes#51008
r? @cramertj
Background:
The anonymous lifetime mode is used to prohibit elided lifetimes where
they didn't used to be permitted, and instead require that `'_` be
used. For example:
```rust
impl Trait for Ref<T> { .. }
// ^^^^^^ ERROR: should be `Ref<'_, T>`
```
When we are parsing the parts of the impl header, we enter into an
alternate mode called `CreateParameter`. In this mode, we give an
error for things like `Ref<T>`, but for elided lifetimes in a
reference type like `&T` we make the elided lifetime into an in-band
lifetime:
4f99f37b7e/src/librustc/hir/lowering.rs (L4017-L4035)
This was not intended to change behavior because we only enter into
that mode in contexts where elision was not historically
permitted. However, the problem is that we fail to reset the mode when
we enter into bounds like `Fn(&u32)`, where elision *was* allowed --
the same occurs for fn types like `fn(&u32`). This PR restores the
original mode in those contexts.
When encountering the following code:
```rust
struct Foo;
fn takes_ref(_: &Foo) {}
let ref opt = Some(Foo);
opt.map(|arg| takes_ref(arg));
```
Suggest using `opt.as_ref().map(|arg| takes_ref(arg));` instead.
This is a stop gap solution until we expand typeck to deal with these
cases in a more graceful way.
In particular, I am adding an implicit injected borrow on the pattern
matches, and when we go around the loop, the compiler is reporting
that this injected borrow is conflicting with the move of the original
value when the match succeeds.
add suggestion applicabilities to librustc and libsyntax
A down payment on #50723. Interested in feedback on whether my `MaybeIncorrect` vs. `MachineApplicable` judgement calls are well-calibrated (and that we have a consensus on what this means).
r? @Manishearth
cc @killercup @estebank
Make anon params lint warn-by-default
This is intended as a followup on anonymous parameters deprecation.
Cross-posting from #41686:
> After having read a bit more of the discussion that I can find, I propose a more aggressive deprecation strategy:
> - We make the lint warn-by-default as soon as possible
> - We make anon parameters a hard error at the epoch boundary
cc @matklad @est31 @aturon
When encountering an unexisting method for a given trait where an
associated function has the same name, suggest using the appropriate
syntax, instead of using `help` text.
When only one candidate is found, do not call it "candidate #1", just
call it "the candidate".
Point to the current box syntax tracking issue
The issue was used for both box syntax as well as placement new.
It got closed due to placement new being unapproved.
So a new one got created for box syntax, yet neither
the unstable book nor feature_gate.rs got updated.
We are doing this now.
r? @aidanhs
The issue was used for both box syntax as well as placement new.
It got closed due to placement new being unapproved.
So a new one got created for box syntax, yet neither
the unstable book nor feature_gate.rs got updated.
We are doing this now.
make ui tests robust with respect to NLL
This PR revises the `ui` tests that I could quickly identify that:
1. previously had successful compilations under non-lexical lifetimes (NLL) because they assumed lexical lifetimes, but
2. such assumption of lexical lifetimes was actually not necessarily part of the spirit of the original issue/bug we want to witness.
In many cases, this is simply a matter of adding a use of a borrow so that it gets extended long enough to observe a conflict.
(In some cases the revision was more subtle, such as adding a destructor, or revising the order of declaration of some variables.)
----
With these test revisions in place, I subsequently updated the expected stderr output under the NLL compiletest mode. So now we should get even more testing of NLL than we were before.
Fix#51025
Fix behaviour of divergence in while loop conditions
This fixes `'a: while break 'a {};` being treated as diverging, by tracking break expressions in the same way as in `loop` expressions.
Fixes#50856.
r? @nikomatsakis
Fail typecheck if we encounter a bogus break
Lone breaks outside of loops create errors in the
loop check pass but as they are not fatal,
compilation continues.
MIR building code assumes all HIR break statements
to point to valid locations and fires ICEs if this
assumption is violated. In normal compilation,
this causes no issues, as code apparently prevents
MIR from being built if errors are present.
However, before that, typecheck runs and with it
MIR const eval. Here we operate differently
from normal compilation: it doesn't check for any
errors except for type checker ones and then
directly builds the MIR.
This constellation causes an ICE-on-error if
bogus break statements are being put into array
length expressions.
This commit fixes this ICE by letting typecheck
fail if bogus break statements are encountered.
This way, MIR const eval fails cleanly with a
type check error.
Fixes#50576Fixes#50581
