When a parse error occurs on a block, the parser will recover and create
a block with the statements collected until that point. Now a flag
stating that a recovery has been performed in this block is propagated
so that the type checker knows that the type of the block (which will be
identified as `()`) shouldn't be checked against the expectation to
reduce the amount of irrelevant diagnostic errors shown to the user.
MIR: terminate unreachable blocks in construct_const
Fixes#46843.
#45821 added unreachable blocks in matches, which were terminated in
construct_fn but not in construct_const, causing a panic due to "no
terminator on block" when constants involved matching on enums.
The "unimplemented expression type" error may go away in the future, the
key is that we see the E0015 about using a non-const function and then
don't ICE.
Ensure separate activations only occur for assignments to locals
Ensure separate activations only occur for assignments to locals, not projections.
Fix#46746.
(I didn't make a regression test because we do not really have a good way to directly express the case that we are trying to catch, because we cannot write MIR directly.)
syntax: Follow-up to the incorrect qpath recovery PR
cc https://github.com/rust-lang/rust/pull/46788
Add tests checking that "priority" of qpath recovery is higher than priority of unary and binary operators
Fix regressed parsing of paths with fn-like generic arguments
r? @estebank
rustc: Work around `DICompileUnit` bugs in LLVM
This commit implements a workaround for #46346 which basically just
avoids triggering the situation that LLVM's bug
https://bugs.llvm.org/show_bug.cgi?id=35562 arises. More details can be
found in the code itself but this commit is also intended to ...
Closes#46346
Implement non-mod.rs mod statements
Fixes https://github.com/rust-lang/rust/issues/45385, cc https://github.com/rust-lang/rust/issues/44660
This will fail tidy right now because it doesn't recognize my UI tests as feature-gate tests. However, I'm not sure if compile-fail will work out either because compile-fail usually requires there to be error patterns in the top-level file, which isn't possible with this feature. What's the recommended way to handle this?
NLL feature complete (adds `feature(nll)`)!
This is the final PR for the nll-master branch; it brings over all remaining content.
The contents of the branch include:
- track causal information and use it to report extended errors
- handle `impl Trait` in NLL code
- improve printing of outlives errors
- add `#![feature(nll)]` and some more sample tests
The commits should for the most part build independently.
r? @pnkfelix (and/or @arielb1)
In particular, -Znll might as well imply -Zborrowck=mir by default,
just like `#![feature(nll)]` does.
Also, if NLL is in use, no reason to emit end regions. The NLL pass
just strips them out anyway.
This is more convenient, and allows us to be more independent from
infcx, particularly with respect to `in_progress_tables` field.
No functional change.
