Currently it just unconditionally allocates it in the arena.
For a "Clean Check" build of the the `packed-simd` benchmark, this
change reduces both the `max-rss` and `faults` counts by 59%; it
slightly (~3%) increases the instruction counts but the `wall-time` is
unchanged.
For the same builds of a few other benchmarks, `max-rss` and `faults`
drop by 1--5%, but instruction counts and `wall-time` changes are in the
noise.
Fixes#57432, fixes#57829.
[NLL] Clean up handling of type annotations
* Renames (Canonical)?UserTypeAnnotation -> (Canonical)?UserType so that the name CanonicalUserTypeAnnotation is free.
* Keep the inferred type associated to user type annotations in the MIR, so that it can be compared against the annotated type, even when the annotated expression gets removed from the MIR. (#54943)
* Use the inferred type to allow infallible handling of user type projections (#57531)
* Uses revisions for the tests in #56993
* Check the types of `Unevaluated` constants with no annotations (#46702)
* Some drive-by cleanup
Closes#46702Closes#54943Closes#57531Closes#57731
cc #56993 leaving this open to track the underlying issue: we are not running tests with full NLL enabled on CI at the moment
r? @nikomatsakis
NLL: Add union justifications to conflicting borrows.
Fixes#57100.
This PR adds justifications to error messages for conflicting borrows of union fields.
Where previously an error message would say ``cannot borrow `u.b` as mutable..``, it now says ``cannot borrow `u` (via `u.b`) as mutable..``.
r? @pnkfelix
This commit refactors `PlaceContext` to split it into four different
smaller enums based on if the context represents a mutating use,
non-mutating use, maybe-mutating use or a non-use (this is based on the
recommendation from @oli-obk on Zulip[1]).
This commit then introduces a `PlaceContext::AscribeUserTy` variant.
`StatementKind::AscribeUserTy` is now correctly mapped to
`PlaceContext::AscribeUserTy` instead of `PlaceContext::Validate`.
`PlaceContext::AscribeUserTy` can also now be correctly categorized as a
non-use which fixes an issue with constant promotion in statics after a
cast introduces a `AscribeUserTy` statement.
[1]: https://rust-lang.zulipchat.com/#narrow/stream/122657-wg-nll/subject/.2355288.20cast.20fails.20to.20promote.20to.20'static/near/136536949
I did not think I would need this in the MIR, but in general local
decls are going to need to support this. (That, or we need to be able
define a least-upper-bound for a collection of types encountered via
the pattern compilation.)
This gives at least some explanation for why a borrow is expected to
last for a certain free region. Also:
* Reports E0373: "closure may outlive the current function" with NLL.
* Special cases the case of returning a reference to (or value
referencing) a local variable or temporary (E0515).
* Special case assigning a reference to a local variable in a closure
to a captured variable.
Prefer unwrap_or_else to unwrap_or in case of function calls/allocations
The contents of `unwrap_or` are evaluated eagerly, so it's not a good pick in case of function calls and allocations. This PR also changes a few `unwrap_or`s with `unwrap_or_default`.
An added bonus is that in some cases this change also reveals if the object it's called on is an `Option` or a `Result` (based on whether the closure takes an argument).
This commit extends existing special-casing of closures to highlight the
use of variables within generators that are causing the generator to
borrow them.
Report when borrow could cause `&mut` aliasing during Drop
We were already issuing an error for the cases where this cropped up, so this is not fixing any soundness holes. The previous diagnostic just wasn't accurately describing the problem in the user's code.
Fix#52059
In particular:
1. Extend `WriteKind::StorageDeadOrDrop` with state to track whether
we are running a destructor or just freeing backing storage. (As
part of this, when we drop a Box<..<Box<T>..> where `T` does not
need drop, we now signal that the drop of `T` is a kind of storage
dead rather than a drop.)
2. When reporting that a value does not live long enough, check if
we're doing an "interesting" drop, i.e. we aren't just trivally
freeing the borrowed state, but rather a user-defined dtor will
run and potentially require exclusive aces to the borrowed state.
3. Added a new diagnosic to describe the scenario here.
Currently we have two files implementing bitsets (and 2D bit matrices).
This commit combines them into one, taking the best features from each.
This involves renaming a lot of things. The high level changes are as
follows.
- bitvec.rs --> bit_set.rs
- indexed_set.rs --> (removed)
- BitArray + IdxSet --> BitSet (merged, see below)
- BitVector --> GrowableBitSet
- {,Sparse,Hybrid}IdxSet --> {,Sparse,Hybrid}BitSet
- BitMatrix --> BitMatrix
- SparseBitMatrix --> SparseBitMatrix
The changes within the bitset types themselves are as follows.
```
OLD OLD NEW
BitArray<C> IdxSet<T> BitSet<T>
-------- ------ ------
grow - grow
new - (remove)
new_empty new_empty new_empty
new_filled new_filled new_filled
- to_hybrid to_hybrid
clear clear clear
set_up_to set_up_to set_up_to
clear_above - clear_above
count - count
contains(T) contains(&T) contains(T)
contains_all - superset
is_empty - is_empty
insert(T) add(&T) insert(T)
insert_all - insert_all()
remove(T) remove(&T) remove(T)
words words words
words_mut words_mut words_mut
- overwrite overwrite
merge union union
- subtract subtract
- intersect intersect
iter iter iter
```
In general, when choosing names I went with:
- names that are more obvious (e.g. `BitSet` over `IdxSet`).
- names that are more like the Rust libraries (e.g. `T` over `C`,
`insert` over `add`);
- names that are more set-like (e.g. `union` over `merge`, `superset`
over `contains_all`, `domain_size` over `num_bits`).
Also, using `T` for index arguments seems more sensible than `&T` --
even though the latter is standard in Rust collection types -- because
indices are always copyable. It also results in fewer `&` and `*`
sigils in practice.
