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.
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
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
The `FatalError.raise()` might seem unmotivated (in most places in
the compiler, `err.emit()` suffices), but it's actually used to
maintain behavior (viz., stop lexing, don't emit potentially spurious
errors looking for the next token after the bad Unicodepoint in the
exponent): the previous revision's `self.err_span_` ultimately calls
`Handler::emit`, which aborts if the `Handler`'s continue_after_error
flag is set, which seems to typically be true during lexing (see
`phase_1_parse_input` and and how `CompileController::basic` has
`continue_parse_after_error: false` in librustc_driver).
Also, let's avoid apostrophes in error messages (the present author
would argue that users expect a reassuringly detached, formal,
above-it-all tone from a Serious tool like a compiler), and use an
RLS-friendly structured suggestion.
Resolves#49746.
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
"crate-ify" paths that begin with a renamed crate
This does two things:
- crate-ify paths that begin with a renamed crate (i.e., add `crate::`) to the front
Fixes https://github.com/rust-lang/rust/issues/50996
I also added tests for a few other scenarios.
r? @alexcrichton
