Fix regionck failure when converting Index to IndexMut
Fixes#74933
Consider an overloaded index expression `base[index]`. Without knowing whether it will be mutated, this will initially be desugared into `<U as Index<T>>::index(&base, index)` for some `U` and `T`. Let `V` be the `expr_ty_adjusted` of `index`.
If this expression ends up being used in any mutable context (or used in a function call with `&mut self` receiver before #72280), we will need to fix it up. The current code will rewrite it to `<U as IndexMut<V>>::index_mut(&mut base, index)`. In most cases this is fine as `V` will be equal to `T`, however this is not always true when `V/T` are references, as they may have different region.
This issue is quite subtle before #72280 as this code path is only used to fixup function receivers, but after #72280 we've made this a common path.
The solution is basically just rewrite it to `<U as IndexMut<T>>::index_mut(&mut base, index)`. `T` can retrieved in the fixup path using `node_substs`.
older toolchains not valid anymore
with the change to llvm 10 the parameter
LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN do not do anything as min and soft error is the same.
see 86b120e6f3/llvm/cmake/modules/CheckCompilerVersion.cmake
Reland #74069
Investigation in #74716 has concluded that this PR is indeed not a regression (and in fact the rollup itself is not either).
This reverts the revert in #74611.
r? @nnethercote cc @eddyb
Rollup of 7 pull requests
Successful merges:
- #75036 (Prefer pattern matching over indexing)
- #75378 (Introduce `rustc_lexer::is_ident` and use it in couple of places)
- #75393 (Fully handle "?" shortcut)
- #75403 (Update comment for function)
- #75407 (Requested changes to [*mut T|*const T]::set_ptr_value)
- #75408 (Update MinGW comments in ci.yml)
- #75409 (Fix range term in alloc vec doc)
Failed merges:
r? @ghost
Requested changes to [*mut T|*const T]::set_ptr_value
This is a follow-up to PR #74774 (tracking issue #75091), acting on some change requests made after approval:
- adds `#[must_use]` attribute
- changes type of `val` pointer argument from `()` to `u8`
- adjusts documentation mentioning pointer provenance
move Deaggregate pass to post_borrowck_cleanup
Reopen of #71946
Only the second commit is from this PR, the other commit is a bugfix that's in the process of getting merged. I'll rebase once that's done
In #70073 MIR pass handling got reorganized, but with the goal of not changing behavior (except for disabling some optimizations on opt-level = 0). But there we realized that the Deaggregator pass, while conceptually more of a "cleanup" pass (and one that should be run before optimizations), was run in the middle of the optimization chain. Likely this is an accident of history, so I suggest we try and clean that up by making it a proper cleanup pass.
This does change mir-opt output, because deaggregation now runs before const-prop instead of after.
r? @wesleywiser @rust-lang/wg-mir-opt
cc @RalfJung
Add sample fix for E0749
Even though the description is clear but the solution may not be as straightforward.
Adding a suggested fix from documentation side.
r? @GuillaumeGomez
However, this suggestion should be shown in rustc itself for easy fix, the documentation should also reflect on the changes in rustc. Currently,
```
error[E0749]: negative impls cannot have any items
--> test.rs:6:5
|
6 | type Foo = i32; // error!
| ^^^^^^^^^^^^^^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0749`.
```
rustc should tell the user to remove it.
Tweak conditions for E0026 and E0769
When we have a tuple struct used with struct we don't want to suggest using the (valid) struct syntax with numeric field names. Instead we want to suggest the expected syntax.
Given
```rust
fn main() {
match MyOption::MySome(42) {
MyOption::MySome { x: 42 } => (),
_ => (),
}
}
```
We now emit E0769 "tuple variant `MyOption::MySome` written as struct variant" instead of E0026 "variant `MyOption::MySome` does not have a field named `x`".
move stack size check to const_eval machine
This is consistent with how we enforce the step limit. In particular, we do not want this limit checked for Miri-the-tool.
