CFG construction takes a large amount of time and memory, especially for
large constants. If such a constant contains no actions on lvalues, it
can't have borrowck problems and can be ignored by it.
This removes the 4.9GB borrowck peak from #36799. It seems that HIR had
grown by 300MB and MIR had grown by 500MB from the last massif
collection and that remains to be investigated, but this at least shaves
the borrowck peak.
Extended error message for mut borrow conflicts in loops
RFC issue: https://github.com/rust-lang/rfcs/issues/2080
The error message for multiple mutable borrows on the same value over loop iterations now makes it clear that the conflict comes from the borrow outlasting the loop. The wording of the error is based on the special case of the moved-value error for a value moved in a loop. Following the example of that error, the code remains the same for the special case.
This is mainly because I felt the current message is confusing in the loop case : https://github.com/rust-lang/rust/issues/43437. It's not clear that the two conflicting borrows are in different iterations of the loop, and instead it just looks like the compiler has an issue with a single line.
Error message now makes clear that mutable borrow conflicts on a single
value in a loop body is caused by the borrow outlasting a single pass of
the loop.
Loop conflicts are detected by seeing when two borrow locations are the
same - which indicates the same code being run more than once.
Turn `elaborate_drops` and `rustc_peek` implementations into MIR
passes that also live in `rustc_mir` crate.
Rewire things so `rustc_driver` uses the `ElaborateDrops` from
`rustc_mir` crate.
Replaced by adding extra imports, adding hidden code (`# ...`), modifying
examples to be runnable (sorry Homura), specifying non-Rust code, and
converting to should_panic, no_run, or compile_fail.
Remaining "```ignore"s received an explanation why they are being ignored.
MIR EndRegion Statements (was MIR dataflow for Borrows)
This PR adds an `EndRegion` statement to MIR (where the `EndRegion` statement is what terminates a borrow).
An earlier version of the PR implemented a dataflow analysis on borrow expressions, but I am now factoring that into a follow-up PR so that reviewing this one is easier. (And also because there are some revisions I want to make to that dataflow code, but I want this PR to get out of WIP status...)
This is a baby step towards MIR borrowck. I just want to get the review process going while I independently work on the remaining steps.
Also, I removed the `continue;` statement. I don't think it makes
a difference whether its there or not, but having it there confuses things
when the actual goal was to side-step the assertion in the default case.
* Emit `EndRegion` for every code-extent for which we observe a
borrow. To do this, we needed to thread source info back through
to `fn in_scope`, which makes this commit a bit more painful than
one might have expected.
* There is `end_region` emission in `Builder::pop_scope` and in
`Builder::exit_scope`; the first handles falling out of a scope
normally, the second handles e.g. `break`.
* Remove `EndRegion` statements during the erase_regions mir
transformation.
* Preallocate the terminator block, and throw an `Unreachable` marker
on it from the outset. Then overwrite that Terminator as necessary
on demand.
* Instead of marking the scope as needs_cleanup after seeing a
borrow, just treat every scope in the chain as being part of the
diverge_block (after any *one* of them has separately signalled
that it needs cleanup, e.g. due to having a destructor to run).
* Allow for resume terminators to be patched when looking up drop flags.
(In particular, `MirPatch::new` has an explicit code path,
presumably previously unreachable, that patches up such resume
terminators.)
* Make `Scope` implement `Debug` trait.
* Expanded a stray comment: we do not emit StorageDead on diverging
paths, but that end behavior might not be desirable.
Explain why a closure is `FnOnce` in closure errors.
Issue: #42065
@nikomatsakis Am I going the right direction with this?
~~I am stuck in a few bits:~~
~~1. How to trace the code to get the upvar instead of the original variable's span?~~
~~2. How to find the node id of the upvar where the move occured?~~
Translate array drop glue using MIR
I was a bit lazy here and used a usize-based index instead of a pointer iteration. Do you think this is important @eddyb?
r? @eddyb
Use the trait-environment+type as the key. Note that these
are only invoked on types that live for the entire compilation
(no inference artifacts). We no longer need the various special-case
bits and caches that were in place before.
rustc: Add a new `-Z force-unstable-if-unmarked` flag
This commit adds a new `-Z` flag to the compiler for use when bootstrapping the
compiler itself. We want to be able to use crates.io crates, but we also want
the usage of such crates to be as ergonomic as possible! To that end compiler
crates are a little tricky in that the crates.io crates are not annotated as
unstable, nor do they expect to pull in unstable dependencies.
To cover all these situations it's intended that the compiler will forever now
bootstrap with `-Z force-unstable-if-unmarked`. This flags serves a dual purpose
of forcing crates.io crates to themselves be unstable while also allowing them
to use other "unstable" crates.io crates. This should mean that adding a
dependency to compiler no longer requires upstream modification with
unstable/staged_api attributes for inclusion!
Operand: 72 -> 24 B
Statement: 192 -> 96 B
Terminator: 256 -> 112 B
librustc translation memory usage: 1795 -> 1669 MB
next step would be interning lvalues, I suppose?
refactor NonZero, Shared, and Unique APIs
Major difference is that I removed Deref impls, as apparently LLVM has
trouble maintaining metadata with a `&ptr -> &ptr` API. This was cited
as a blocker for ever stabilizing this API. It wasn't that ergonomic
anyway.
* Added `get` to NonZero to replace Deref impl
* Added `ptr` getter to Shared/Unique to replace Deref impl
* Added Unique's `get` and `get_mut` conveniences to Shared
* Deprecated `as_mut_ptr` on Shared in favour of `ptr`
Note that Shared used to primarily expose only `*const` but there isn't
a good justification for that, so I made it `*mut`.
Consider changing to & for let bindings #40402
This is a fix for #40402
For the example
```
fn main() {
let v = vec![String::from("oh no")];
let e = v[0];
}
```
It gives
```
error[E0507]: cannot move out of indexed content
--> ex1.rs:4:13
|
4 | let e = v[0];
| ^^^^ cannot move out of indexed content
|
= help: consider changing to `&v[0]`
error: aborting due to previous error
```
Another alternative is
```
error[E0507]: cannot move out of indexed content
--> ex1.rs:4:13
|
4 | let e = v[0];
| ^^^^ consider changing to `&v[0]`
error: aborting due to previous error
```
Also refer to #41564 for more details.
r? @nikomatsakis
