```rust
fn main() {
fn reuse<X>(_: &mut X) {}
let mut t = 2f64;
match t {
ref mut _b if { false } => { reuse(_b); }
_ => {}
}
}
```
Note: The way this is currently written is confusing; when `autoref`
is off, then the arm body bindings (introduced by
`bind_matched_candidate_for_arm_body`) are *also* used for the guard.
(Any attempt to fix this needs to still ensure that the bindings used
by the guard are introduced before the guard is evaluated.)
(Once we turn NLL on by default, we can presumably simplify all of
that.)
For some reason, allowing restricted mutation in match arms exposed an
obvious case where a unique borrow can indeed fail, namely something
like:
```rust
match b {
...
ref mut r if { (|| { let bar = &mut *r; **bar = false; })(); false } => { &mut *r }
// ~~~~~~~
// |
// This ends up holding a `&unique` borrow of `r`, but there ends up being an
// implicit shared borrow in the guard thanks to rust-lang/rust#49870
...
}
```
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.
(This is just the data structure changes and some boilerplate match
code that followed from it; the actual emission of these statements
comes in a follow-up commit.)
Now, if you pass `-Z disable-ast-check-for-mutation-in-guard`, then we
will just allow you to mutably-borrow and assign in guards of `match`
arms.
This is wildly unsound with AST-borrowck. It is also unsound with
MIR-borrowck without further adjustments, which come in later in the
commit series on this Pull Request.
See also rust-lang/rust#24535 and rust-lang/rfcs#1006.
As discussed in
https://github.com/rust-lang/rust/issues/49668#issuecomment-384893456
and subsequent, there are use-cases where the OOM handler needs to know
the size of the allocation that failed. The alignment might also be a
cause for allocation failure, so providing it as well can be useful.
extend from_raw_parts docs for slices and strs to mention alignment requirement
The documentation for `str::from_raw_parts_mut` seems to not be visible because that method is private, bit I figured it could still be fixed. I also removed the reference to the no-longer-existing `str::from_raw_parts` while I was at it.
Alternatively, should I remove `str::from_raw_parts_mut` completely? it is only used in `str::split_at_mut`, where it might as well be inlined.
Add missing Wrapping methods, use doc_comment!
Re-opened version of #49393 . Finishing touches for #32463.
Note that this adds `Shl` and `Shr` implementations for `Wrapping<i128>` and `Wrapping<u128>`, which were previously missed. This is technically insta-stable, but I don't know why this would be a problem.
str::from_raw_parts has been removed long ago because it can be obtained via
str::from_utf8_unchecked and slice::from_raw_parts. The same goes for
str::from_raw_parts_mut.
operate on `HirId` instead of `NodeId` in `hir::Pat::each_binding`, and consequences of that
See #50928 for motivation.
Questions—
* Is #50928 actually a good idea as a plan of record, or is there some reason to keep `NodeId`s?
* Are the uses of `find_node_for_hir_id` in this initial submission OK (see the FIXME comments)?
* Can we bikeshed a better method names `struct_span_lint_hir` _&c._? (Coined in analogy to the `struct_span_lint_node` and `NodeId`, but it feels kind of semantically clunky.)
r? @michaelwoerister
