Don't ICE if method receiver fails to unify with `arbitrary_self_types`
Consider:
```rust
struct Foo(u32);
impl Foo {
fn get<R: Deref<Target=Self>>(self: R) -> u32 {
self.0
}
}
fn main() {
let mut foo = Foo(1);
foo.get::<&Foo>();
}
```
The problem here is that with `arbitrary_self_types`, we're allowed to have a method receiver that mentions generics from the method itself (`fn get<R: Deref<Target=Self>>(self: R)`). Since we don't actually take into account the user-written turbofish generics when doing method lookup (nor do we check that method predicates hold), method probing will happily infer `R = Foo` during the probe. When we later confirm the method, we do use the turbofish'd subst and instead now have that `R = &Foo`. This doesn't unify with the self type we chose during the probe, causing an ICE.
Getting this to work correctly will be difficult. Specifically, we'll need to actually pass in the turbofish generics for the method being probed for and check that the self type unifies considering those generics. This seems like a lot of work, and I'm not actually familiar with the restrictions originally called out for `#![feature(arbitrary_self_types)]`, but I think we should probably instead just deny having receivers that mention (type/const) generics that come from the method itself.
But I mostly just want to turn this ICE into an error, so I'll leave that up for later PRs.
Fixes#111838
Check opaques for mismatch during writeback
Revive #111705.
I realized that we don't need to put any substs in the writeback results since all of the hidden types have already been remapped. See the comment in `compiler/rustc_middle/src/ty/typeck_results.rs`, which should make that clear for other explorers of the codebase.
Additionally, we need to do some diagnostic stashing because the diagnostics we produce during HIR typeck is very poor and we should prefer the diagnostic that comes from MIR, if we have one.
r? `@oli-obk`
Remove return type sized check hack from hir typeck
Remove a bunch of special-cased suggestions when someone returns `-> dyn Trait` that checks for type equality, etc.
This was a pretty complex piece of code that also relied on a hack in hir typeck (see changes to `compiler/rustc_hir_typeck/src/check.rs`), and I'm not convinced that it's necessary to maintain, when all we really need to tell the user is that they should return `-> impl Trait` or `-> Box<dyn Trait>`, depending on their specific use-case.
This is necessary because we may need to move the "return type is sized" check from hir typeck to wfcheck, which does not have access to typeck results. This is a prerequisite for that, and I'm fairly confident that the diagnostics "regressions" here are not a big deal.
[rustc_ty_utils] Treat `drop_in_place`'s *mut argument like &mut when adding LLVM attributes
This resurrects PR #103614, which has sat idle for a while.
This could probably use a new perf run, since we're on a new LLVM version now.
r? `@oli-obk`
cc `@RalfJung`
---
LLVM can make use of the `noalias` parameter attribute on the parameter to `drop_in_place` in areas like argument promotion. Because the Rust compiler fully controls the code for `drop_in_place`, it can soundly deduce parameter attributes on it.
In #103957, Miri was changed to retag `drop_in_place`'s argument as if it was `&mut`, matching this change.
Deal with unnormalized projections when structurally resolving types with new solver
1. Normalize types in `structurally_resolved_type` when the new solver is enabled
2. Normalize built-in autoderef targets in `Autoderef` when the new solver is enabled
3. Normalize-erasing-regions in `resolve_type` in writeback
This is motivated by the UI test provided, which currently fails with:
```
error[E0609]: no field `x` on type `<usize as SliceIndex<[Foo]>>::Output`
--> <source>:9:11
|
9 | xs[0].x = 1;
| ^
```
I'm pretty happy with the approach in (1.) and (2.) and think we'll inevitably need something like this in the long-term, but (3.) seems like a hack to me. It's a *lot* of work to add tons of new calls to every user of these typeck results though (mir build, late lints, etc). Happy to discuss further.
r? `@lcnr`
This was added to control percentage sizes, in
79956b96e8
Now, the only percentage size is [`border-radius`], which is
based on the size of the box itself, not its containing block.
This leaves the property unused.
[`border-radius`]: https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius
Give better error when collecting into `&[T]`
The detection of slice reference of `{integral}` in `rustc_on_unimplemented` is hacky, but a proper solution requires changing `FmtPrinter` to add a parameter to print integers as `{integral}` and I didn't want to change it just for `rustc_on_unimplemented`. I can do that if requested, though.
I'm open to better wording; this is the best I could come up with.
fix recursion depth handling after confirmation
fixes#111729
I think having to use `Obligation::with_depth` correctly everywhere is very hard because e.g. the nested obligations from `eq` currently do not have the correct obligation depth.
The new solver [completely removes `recursion_depth` from obligations](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/traits/solve/struct.Goal.html) and instead tracks the depth in the solver itself which is far easier to get right. Moving the old solver towards this shouldn't be that hard but is probably somewhat annoying.
r? `@matthewjasper`
Fix duplicate `arcinner_layout_for_value_layout` calls when using the uninit `Arc` constructors
What this fixes is the duplicate calls to `arcinner_layout_for_value_layout` seen here: https://godbolt.org/z/jr5Gxozhj
The issue was discovered alongside #111603 but is otherwise unrelated to the duplicate `alloca`s, which remain unsolved. Everything I tried to solve said main issue has failed.
As for the duplicate layout calculations, I also tried slapping `#[inline]` and `#[inline(always)]` on everything in sight but the only thing that worked in the end is to dedup the calls by hand.
Rather than returning an array of features from to_llvm_features, return a structure that contains
the dependencies. This also contains metadata on how the features depend on each other to allow for
the correct enabling and disabling.
Some features that are tied together only make sense to be folded
together when enabling the feature. For example on AArch64 sve and
neon are tied together, however it doesn't make sense to disable neon
when disabling sve.
rustdoc: include strikethrough in item summary
Fixes https://github.com/rust-lang/rust/issues/111822. Since **bold** and *italic* are included, I don't see why ~~strikethrough~~ shouldn't be.
Since this only affects `PreCodegen MIR, and it would be nice for that to be resilient to permutations of things that don't affect the actual semantic behaviours.
Rollup of 5 pull requests
Successful merges:
- #111745 (Fix overflow in error emitter)
- #111770 (Read beta version from the version file if building from a source tarball)
- #111797 (Migrate GUI colors test to original CSS color format)
- #111809 (Unset MIRI_BLESS for mir-opt-level 4 miri tests)
- #111817 (Migrate GUI colors test to original CSS color format)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix overflow in error emitter
Fix#109854Close#94171 (was already fixed before but missing test)
This bug happens when a multipart suggestion spans more than one line.
The fix is to update the `acc` variable, which didn't handle the case when the text to remove spans multiple lines but the text to add spans only one line.
Also, use `usize::try_from` instead of `as usize` to detect overflows earlier in the future, and point to the source of the overflow (the original issue points to a different place where this value is used, not where the overflow had happened).
And finally add an `if start != end` check to avoid doing any extra work in case of empty ranges.
Long explanation:
Given this test case:
```rust
fn generate_setter() {
String::with_capacity(
//~^ ERROR this function takes 1 argument but 3 arguments were supplied
generate_setter,
r#"
pub(crate) struct Person<T: Clone> {}
"#,
r#""#,
);
}
```
The compiler will try to convert that code into the following:
```rust
fn generate_setter() {
String::with_capacity(
//~^ ERROR this function takes 1 argument but 3 arguments were supplied
/* usize */,
);
}
```
So it creates a suggestion with 3 separate parts:
```
// Replace "generate_setter" with "/* usize */"
SubstitutionPart { span: fuzz_input.rs:4:5: 4:20 (#0), snippet: "/* usize */" }
// Remove second arg (multiline string)
SubstitutionPart { span: fuzz_input.rs:4:20: 7:3 (#0), snippet: "" }
// Remove third arg (r#""#)
SubstitutionPart { span: fuzz_input.rs:7:3: 8:11 (#0), snippet: "" }
```
Each of this parts gets a separate `SubstitutionHighlight` (this marks the relevant text green in a terminal, the values are 0-indexed so `start: 4` means column 5):
```
SubstitutionHighlight { start: 4, end: 15 }
SubstitutionHighlight { start: 15, end: 15 }
SubstitutionHighlight { start: 18446744073709551614, end: 18446744073709551614 }
```
The 2nd and 3rd suggestion are empty (start = end) because they only remove text, so there are no additions to highlight. But the 3rd span has overflowed because the compiler assumes that the 3rd suggestion is on the same line as the first suggestion. The 2nd span starts at column 20 and the highlight starts at column 16 (15+1), so that suggestion is good. But since the 3rd span starts at column 3, the result is `3 - 4`, or column -1, which turns into -2 with 0-indexed, and that's equivalent to `18446744073709551614 as isize`.
With this fix, the resulting `SubstitutionHighlight` are:
```
SubstitutionHighlight { start: 4, end: 15 }
SubstitutionHighlight { start: 15, end: 15 }
SubstitutionHighlight { start: 15, end: 15 }
```
As expected. I guess ideally we shouldn't emit empty highlights when removing text, but I am too scared to change that.
Don't inline functions with unsized args
Fixes#111355 .
I have some ideas for how we can get this back in the future, out of scope for this PR though.
r? `@cjgillot`
CFI: Fix encode_ty: unexpected Param(B/#1)
Fixes#111510 and complements #106547 by adding support for encoding type parameters and also by transforming trait objects' traits into their identities before emitting type checks.
don't skip inference for type in `offset_of!`
Fixes https://github.com/rust-lang/rust/issues/111678 by no longer skipping inference on the type in `offset_of!`. Simply erasing the regions the during writeback isn't enough and can cause ICEs. A test case for this is included.
This reverts https://github.com/rust-lang/rust/pull/111661, because it becomes redundant, since inference already erases the regions.
Fix local libs not included when printing native static libs
This PR fixes https://github.com/rust-lang/rust/issues/111643 by adding the local used libs to the printed `--print=native-static-libs` output.
It seems that `--print=native-static-libs` doesn't have any test, so I added one. It's very simple and doesn't even tries to compile the result to a binary as I don't know how to handle external library linking in CI. (Note that https://github.com/rust-lang/rust/blob/master/tests/run-make/staticlib-dylib-linkage/Makefile does compile to a binary)
r? `@bjorn3`
The CHECK, -NOT, -SAME pattern ensures that the `CHECK-NOT: noalias`
is limited to only one line, and won't match unrelated lines further
down in the file.
Explicit drop call added to preserve the `foo` argument name, since
names of unused arguments are not preserved.
We've done measurements with Miri and have determined that `noalias` shouldn't
break code. The requirements that allow us to add dereferenceable and align
have been long documented in the standard library documentation.
LLVM can make use of the `noalias` parameter attribute on the parameter to
`drop_in_place` in areas like argument promotion. Because the Rust compiler
fully controls the code for `drop_in_place`, it can soundly deduce parameter
attributes on it. In the case of a value that has a programmer-defined Drop
implementation, we know that the first thing `drop_in_place` will do is pass a
pointer to the object to `Drop::drop`. `Drop::drop` takes `&mut`, so it must be
guaranteed that there are no pointers to the object upon entering that
function. Therefore, it should be safe to mark `noalias` there.
With this patch, we mark `noalias` only when the type is a value with a
programmer-defined Drop implementation. This is possibly overly conservative,
but I thought that proceeding cautiously was best in this instance.
Add more tests for the offset_of macro
Implements what I [suggested in the tracking issue](https://github.com/rust-lang/rust/issues/106655#issuecomment-1535007205), plus some further improvements:
* ensuring that offset_of!(Self, ...) works iff inside an impl block
* ensuring that the output type is usize and doesn't coerce. this can be changed in the future, but if it is done, it should be a conscious decision
* improving the privacy checking test
* ensuring that generics don't let you escape the unsized check
r? `````@WaffleLapkin`````
Dont check `must_use` on nested `impl Future` from fn
Fixes (but does not close, per beta policy) #111484
Also fixes a `FIXME` left in the code about (presumably) false-positives on non-async `#[must_use] fn() -> impl Future` cases, though if that's not desirable to include in the beta backport then I can certainly revert it.
Beta nominating as it fixes a beta ICE.
Fix dependency tracking for debugger visualizers
This PR fixes dependency tracking for debugger visualizer files by changing the `debugger_visualizers` query to an `eval_always` query that scans the AST while it is still available. This way the set of visualizer files is already available when dep-info is emitted. Since the query is turned into an `eval_always` query, dependency tracking will now reliably detect changes to the visualizer script files themselves.
TODO:
- [x] perf.rlo
- [x] Needs a bit more documentation in some places
- [x] Needs regression test for the incr. comp. case
Fixes https://github.com/rust-lang/rust/issues/111226
Fixes https://github.com/rust-lang/rust/issues/111227
Fixes https://github.com/rust-lang/rust/issues/111295
r? `@wesleywiser`
cc `@gibbyfree`
Shorten even more panic temporary lifetimes
Followup to #104134. As pointed out by `@bjorn3` in https://github.com/rust-lang/rust/pull/104134#pullrequestreview-1425585948, there are other cases in the panic macros which would also benefit from dropping their non-Send temporaries as soon as possible, avoiding pointlessly holding them across an await point.
For the tests added in this PR, here are the failures you get today on master without the macro changes in this PR:
<details>
<summary>tests/ui/macros/panic-temporaries-2018.rs</summary>
```console
error: future cannot be sent between threads safely
--> tests/ui/macros/panic-temporaries-2018.rs:52:18
|
LL | require_send(panic_display());
| ^^^^^^^^^^^^^^^ future returned by `panic_display` is not `Send`
|
= help: within `impl Future<Output = ()>`, the trait `Send` is not implemented for `*const u8`
note: future is not `Send` as this value is used across an await
--> tests/ui/macros/panic-temporaries-2018.rs:35:31
|
LL | f(panic!("{}", NOT_SEND)).await;
| -------- ^^^^^- `NOT_SEND` is later dropped here
| | |
| | await occurs here, with `NOT_SEND` maybe used later
| has type `NotSend` which is not `Send`
note: required by a bound in `require_send`
--> tests/ui/macros/panic-temporaries-2018.rs:48:25
|
LL | fn require_send(_: impl Send) {}
| ^^^^ required by this bound in `require_send`
error: future cannot be sent between threads safely
--> tests/ui/macros/panic-temporaries-2018.rs:52:18
|
LL | require_send(panic_display());
| ^^^^^^^^^^^^^^^ future returned by `panic_display` is not `Send`
|
= help: within `NotSend`, the trait `Sync` is not implemented for `*const u8`
note: future is not `Send` as this value is used across an await
--> tests/ui/macros/panic-temporaries-2018.rs:35:31
|
LL | f(panic!("{}", NOT_SEND)).await;
| ---------------------- ^^^^^- the value is later dropped here
| | |
| | await occurs here, with the value maybe used later
| has type `&NotSend` which is not `Send`
note: required by a bound in `require_send`
--> tests/ui/macros/panic-temporaries-2018.rs:48:25
|
LL | fn require_send(_: impl Send) {}
| ^^^^ required by this bound in `require_send`
error: future cannot be sent between threads safely
--> tests/ui/macros/panic-temporaries-2018.rs:53:18
|
LL | require_send(panic_str());
| ^^^^^^^^^^^ future returned by `panic_str` is not `Send`
|
= help: within `impl Future<Output = ()>`, the trait `Send` is not implemented for `*const u8`
note: future is not `Send` as this value is used across an await
--> tests/ui/macros/panic-temporaries-2018.rs:40:36
|
LL | f(panic!((NOT_SEND, "...").1)).await;
| -------- ^^^^^- `NOT_SEND` is later dropped here
| | |
| | await occurs here, with `NOT_SEND` maybe used later
| has type `NotSend` which is not `Send`
note: required by a bound in `require_send`
--> tests/ui/macros/panic-temporaries-2018.rs:48:25
|
LL | fn require_send(_: impl Send) {}
| ^^^^ required by this bound in `require_send`
error: future cannot be sent between threads safely
--> tests/ui/macros/panic-temporaries-2018.rs:54:18
|
LL | require_send(unreachable_display());
| ^^^^^^^^^^^^^^^^^^^^^ future returned by `unreachable_display` is not `Send`
|
= help: within `impl Future<Output = ()>`, the trait `Send` is not implemented for `*const u8`
note: future is not `Send` as this value is used across an await
--> tests/ui/macros/panic-temporaries-2018.rs:45:31
|
LL | f(unreachable!(NOT_SEND)).await;
| -------- ^^^^^- `NOT_SEND` is later dropped here
| | |
| | await occurs here, with `NOT_SEND` maybe used later
| has type `NotSend` which is not `Send`
note: required by a bound in `require_send`
--> tests/ui/macros/panic-temporaries-2018.rs:48:25
|
LL | fn require_send(_: impl Send) {}
| ^^^^ required by this bound in `require_send`
error: future cannot be sent between threads safely
--> tests/ui/macros/panic-temporaries-2018.rs:54:18
|
LL | require_send(unreachable_display());
| ^^^^^^^^^^^^^^^^^^^^^ future returned by `unreachable_display` is not `Send`
|
= help: within `NotSend`, the trait `Sync` is not implemented for `*const u8`
note: future is not `Send` as this value is used across an await
--> tests/ui/macros/panic-temporaries-2018.rs:45:31
|
LL | f(unreachable!(NOT_SEND)).await;
| ---------------------- ^^^^^- the value is later dropped here
| | |
| | await occurs here, with the value maybe used later
| has type `&NotSend` which is not `Send`
note: required by a bound in `require_send`
--> tests/ui/macros/panic-temporaries-2018.rs:48:25
|
LL | fn require_send(_: impl Send) {}
| ^^^^ required by this bound in `require_send`
error: aborting due to 5 previous errors
```
</details>
<details>
<summary>tests/ui/macros/panic-temporaries.rs</summary>
```console
error: future cannot be sent between threads safely
--> tests/ui/macros/panic-temporaries.rs:42:18
|
LL | require_send(panic_display());
| ^^^^^^^^^^^^^^^ future returned by `panic_display` is not `Send`
|
= help: within `impl Future<Output = ()>`, the trait `Send` is not implemented for `*const u8`
note: future is not `Send` as this value is used across an await
--> tests/ui/macros/panic-temporaries.rs:35:31
|
LL | f(panic!("{}", NOT_SEND)).await;
| -------- ^^^^^- `NOT_SEND` is later dropped here
| | |
| | await occurs here, with `NOT_SEND` maybe used later
| has type `NotSend` which is not `Send`
note: required by a bound in `require_send`
--> tests/ui/macros/panic-temporaries.rs:38:25
|
LL | fn require_send(_: impl Send) {}
| ^^^^ required by this bound in `require_send`
error: future cannot be sent between threads safely
--> tests/ui/macros/panic-temporaries.rs:42:18
|
LL | require_send(panic_display());
| ^^^^^^^^^^^^^^^ future returned by `panic_display` is not `Send`
|
= help: within `NotSend`, the trait `Sync` is not implemented for `*const u8`
note: future is not `Send` as this value is used across an await
--> tests/ui/macros/panic-temporaries.rs:35:31
|
LL | f(panic!("{}", NOT_SEND)).await;
| ---------------------- ^^^^^- the value is later dropped here
| | |
| | await occurs here, with the value maybe used later
| has type `&NotSend` which is not `Send`
note: required by a bound in `require_send`
--> tests/ui/macros/panic-temporaries.rs:38:25
|
LL | fn require_send(_: impl Send) {}
| ^^^^ required by this bound in `require_send`
error: aborting due to 2 previous errors
```
</details>
r? bjorn3
do not allow inference in `predicate_must_hold` (alternative approach)
See the FCP description for more info, but tl;dr is that we should not return `EvaluatedToOkModuloRegions` if an obligation may hold only with some choice of inference vars being constrained.
Attempts to solve this in the approach laid out by lcnr here: https://github.com/rust-lang/rust/pull/109558#discussion_r1147318134, rather than by eagerly replacing infer vars with placeholders which is a bit too restrictive.
r? `@ghost`
fix(resolve): replace bindings to dummy for unresolved imports
close#109343
In #109343, `f` in `pub use f as g` points to:
|namespace| binding|
|-|-|
|type| `external crate f`|
|value| `None` |
|macro| `None` |
When resolve `value_ns` during `resolve_doc_links`, the value of the binding of single_import `pub use f as g` goes to `pub use inner::f`, and since it does not satisfy [!self.is_accessible_from(binding.vis, single_import.parent_scope.module)](https://github.com/rust-lang/rust/blob/master/compiler/rustc_resolve/src/ident.rs#L971) and returns `Err(Undetermined)`, which eventually goes to `PathResult::Indeterminate => unreachable!`.
This PR replace all namespace binding to `dummy_binding` for indeterminate import, so, the bindings of `pub use f as g` had been changed to followings after finalize:
|namespace| binding|
|-|-|
|type| `dummy`|
|value| `dummy` |
|macro| `dummy` |
r?`@petrochenkov`
Only depend on CFG_VERSION in rustc_interface
This avoids having to rebuild the whole compiler on each commit when `omit-git-hash = false`.
cc https://github.com/rust-lang/rust/issues/76720 - this won't fix it, and I'm not suggesting we turn this on by default, but it will make it less painful for people who do have `omit-git-hash` on as a workaround.
Merge query property modules into one
This merges all the query modules that defines types into a single module per query with a normal naming convention for type aliases.
r? ``@cjgillot``
Do not recover when parsing stmt in cfg-eval.
`parse_stmt` does recovery on its own. When parsing the statement fails, we always get `Ok(None)` instead of an `Err` variant with the diagnostic that we can emit.
To avoid this behaviour, we need to opt-out of recovery for cfg_eval.
Fixes https://github.com/rust-lang/rust/issues/105228
* ensuring that offset_of!(Self, ...) works iff inside an impl block
* ensuring that the output type is usize and doesn't coerce. this can be
changed in the future, but if it is done, it should be a conscious descision
* improving the privacy checking test
* ensuring that generics don't let you escape the unsized check
Fixes#111510 and complements #106547 by adding support for encoding
type parameters and also by transforming trait objects' traits into
their identities before emitting type checks.
Stop turning transmutes into discriminant reads in mir-opt
Partially reverts #109612, as after #109993 these aren't actually equivalent any more, and I'm no longer confident this was ever an improvement in the first place.
Having this "simplification" meant that similar-looking code actually did somewhat different things. For example,
```rust
pub unsafe fn demo1(x: std::cmp::Ordering) -> u8 {
std::mem::transmute(x)
}
pub unsafe fn demo2(x: std::cmp::Ordering) -> i8 {
std::mem::transmute(x)
}
```
in nightly today is generating <https://rust.godbolt.org/z/dPK58zW18>
```llvm
define noundef i8 `@_ZN7example5demo117h341ef313673d2ee6E(i8` noundef %x) unnamed_addr #0 {
%0 = icmp uge i8 %x, -1
%1 = icmp ule i8 %x, 1
%2 = or i1 %0, %1
call void `@llvm.assume(i1` %2)
ret i8 %x
}
define noundef i8 `@_ZN7example5demo217h5ad29f361a3f5700E(i8` noundef %0) unnamed_addr #0 {
%x = alloca i8, align 1
store i8 %0, ptr %x, align 1
%1 = load i8, ptr %x, align 1, !range !2, !noundef !3
ret i8 %1
}
```
Which feels too different when the original code is essentially identical.
---
Aside: that example is different *after* optimizations too:
```llvm
define noundef i8 `@_ZN7example5demo117h341ef313673d2ee6E(i8` noundef returned %x) unnamed_addr #0 {
%0 = add i8 %x, 1
%1 = icmp ult i8 %0, 3
tail call void `@llvm.assume(i1` %1)
ret i8 %x
}
define noundef i8 `@_ZN7example5demo217h5ad29f361a3f5700E(i8` noundef returned %0) unnamed_addr #1 {
ret i8 %0
}
```
so turning the `Transmute` into a `Discriminant` was arguably just making things worse, so leaving it alone instead -- and thus having less code in rustc -- seems clearly better.
debug format `Const`'s less verbosely
Not user visible change only visible to people debugging const generics.
Currently debug output for `ty::Const` is super verbose (even for `-Zverbose` lol), things like printing infer vars as `Infer(Var(?0c))` instead of just `?0c`, bound vars and placeholders not using `^0_1` or `!0_1` syntax respectively. With these changes its imo better but not perfect:
`Const { ty: usize, kind: ^0_1 }`
is still a lot for not much information. not entirely sure what to do about that so not dealing with it yet.
Need to do formatting for `ConstKind::Expr` at some point too since rn it sucks (doesn't even print anything with `Display`) not gonna do that in this PR either.
r? `@compiler-errors`
[rustdoc] Only keep impl blocks from bodies
Fixes https://github.com/rust-lang/rust/issues/111415.
The problem was that we kept everything inside bodies whereas only impl blocks are actually accessible from outside bodies.
r? `@notriddle`
fix(diagnostic): wrap parens for ref impl trait param
Fixes https://github.com/rust-lang/rust/issues/99597
When parameters are an `impl_trait` which it needed to add trait, and it is a reference, add parentheses to the type of the parameter in the suggestion
Erase `ReError` properly
Fixes#111341
Since we check whether a type has free regions before erasing (to short circuit unnecesary folding), we need to consider `ReError` as a free region, or else we'll skip it when erasing a type that only mentions `ReError`.
cc `@nnethercote`
Handle error body in generator layout
Fixes#111468
I feel like making this query return `Option<GeneratorLayout>` might be better but had some issues with that approach
Always fall back to PartialEq when a constant in a pattern is not recursively structural-eq
Right now we destructure the constant as far as we can, but with this PR we just don't take it apart anymore. This is preparatory work for moving to always using valtrees, as these will just do a single conversion of the constant to a valtree at the start, and if that fails, fall back to `PartialEq`.
This removes a few cases where we emitted the `unreachable pattern` lint, because we stop looking into the constant deeply enough to detect that a constant is already covered by another pattern.
Previous work: https://github.com/rust-lang/rust/pull/70743
This is groundwork towards fixing https://github.com/rust-lang/rust/issues/83085 and https://github.com/rust-lang/rust/issues/105047
Suppress "erroneous constant used" for constants tainted by errors
When constant evaluation fails because its MIR is tainted by errors,
suppress note indicating that erroneous constant was used, since those
errors have to be fixed regardless of the constant being used or not.
Fixes#110891.
Recover `impl<T ?Sized>` correctly
Fixes#111327
r? ````@Nilstrieb```` but you can re-roll
Alternatively, happy to close this if we're okay with just saying "sorry #111327 is just a poor side-effect of parser ambiguity" 🤷
Combine three generalizer implementations
Fixes#111092Fixes#109505
This code is a bit delicate and there were subtle changes between them, so I'll leave inline comments where further inspection is needed.
Regarding this comment from #109813 -- "add tests triggering all codepaths: at least the combine and the const generalizer", can't really do that now, and I don't really know how we'd get a higher-ranked const error since non-lifetime binders doesn't *really* support `for<const ..>` (it errors out when you try to use it).
r? `@lcnr`
Move expansion of query macros in rustc_middle to rustc_middle::query
This moves the expansion of `define_callbacks!` and `define_feedable!` from `rustc_middle::ty::query` to `rustc_middle::query`.
This means that types used in queries are both imported and used in `rustc_middle::query` instead of being split between these modules. It also decouples `rustc_middle::ty::query` further from `rustc_middle` which is helpful since we want to move `rustc_middle::ty::query` to the query system crates.
Stop checking for the absence of something that doesn't exist
A couple of codegen tests are doing
```
// CHECK-NOT: slice_index_len_fail
```
However, that function no longer exists: [the only places](https://github.com/search?q=repo%3Arust-lang%2Frust+slice_index_len_fail&type=code) it occurs in the repo are in those tests.
So this PR updates the tests to check for the absense of the functions that are actually used today to panic for out-of-bounds indexing.
When constant evaluation fails because its MIR is tainted by errors,
suppress note indicating that erroneous constant was used, since those
errors have to be fixed regardless of the constant being used or not.
Partially reverts 109612, as after 109993 these aren't actually equivalent any more, and I'm no longer confident this was ever an improvement in the first place.
allow mutating function args through `&raw const`
Fixes https://github.com/rust-lang/rust/issues/111502 by "turning off the sketchy optimization while we figure out if this is ok", like `@JakobDegen` said.
The first commit in this PR removes some suspicious looking logic from the same method, but should have no functional changes, since it doesn't modify the `context` outside of the method. Best reviewed commit by commit.
r? opsem
[rustdoc] Convert more GUI tests colors to their original format
Follow-up of https://github.com/rust-lang/rust/pull/111459.
The update for the `browser-ui-test` version is about improvements for color handling (alpha for hex format in particular).
r? `@notriddle`
Allow MIR debuginfo to point to a variable's address
MIR optimizations currently do not to operate on borrowed locals.
When enabling #106285, many borrows will be left as-is because they are used in debuginfo. This pass allows to replace this pattern directly in MIR debuginfo:
```rust
a => _1
_1 = &raw? mut? _2
```
becomes
```rust
a => &_2
// No statement to borrow _2.
```
This pass is implemented as a drive-by in ReferencePropagation MIR pass.
This transformation allows following following MIR opts to treat _2 as an unborrowed local, and optimize it as such, even in builds with debuginfo.
In codegen, when encountering `a => &..&_2`, we create a list of allocas:
```llvm
store ptr %_2.dbg.spill, ptr %a.ref0.dbg.spill
store ptr %a.ref0.dbg.spill, ptr %a.ref1.dbg.spill
...
call void `@llvm.dbg.declare(metadata` ptr %a.ref{n}.dbg.spill, /* ... */)
```
Caveat: this transformation looses the exact type, we do not differentiate `a` as a immutable, mutable reference or a raw pointer. Everything is declared to `*mut` to codegen. I'm not convinced this is a blocker.
Add a tidy check to find unexpected files in UI tests, and clean up the results
While looking at UI tests, I noticed several weird files that were not being tested, some from even pre-1.0. I added a tidy check that fails if any files not known to compiletest or not used in tests (via manual list) are present in the ui tests.
Unfortunately the root entry limit had to be raised by 1 to accommodate the stderr file for one of the tests.
r? `@fee1-dead`
Align unsized locals
Allocate an extra space for unsized locals and manually align the storage, since alloca doesn't support dynamic alignment.
Fixes#71416.
Fixes#71695.
Apply simulate-remapped-rust-src-base even if remap-debuginfo is set in config.toml
This is really a mess. Here is the situation before this change:
- UI tests depend on not having `rust-src` available. In particular, <3f374128ee/tests/ui/tuple/wrong_argument_ice.stderr (L7-L8)> is depending on the `note` being a single line and not showing the source code.
- When `download-rustc` is disabled, we pass `-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX` `-Ztranslate-remapped-path-to-local-path=no`, which changes the diagnostic to something like ` --> /rustc/FAKE_PREFIX/library/alloc/src/collections/vec_deque/mod.rs:1657:12`
- When `download-rustc` is enabled, we still pass those flags, but they no longer have an effect. Instead rustc emits diagnostic paths like this: ` --> /rustc/39c6804b92aa202369e402525cee329556bc1db0/library/alloc/src/collections/vec_deque/mod.rs:1657:12`. Notice how there's a real commit and not `FAKE_PREFIX`. This happens because we set `CFG_VIRTUAL_RUST_SOURCE_BASE_DIR` during bootstrapping for CI artifacts, and rustc previously didn't allow for `simulate-remapped` to affect paths that had already been remapped.
- Pietro noticed this and decided the right thing was to normalize `/rustc/<commit>` to `$SRC_DIR` in compiletest: 470423c3d2
- After my change to `x test core`, which rebuilds stage 2 std from source so `build/stage2-std` and `build/stage2` use the same `.rlib` metadata, the compiler suddenly notices it has sources for `std` available and prints those in the diagnostic, causing the test to fail.
This changes `simulate-remapped-rust-src-base` to support remapping paths that have already been remapped, unblocking download-rustc.
Unfortunately, although this fixes the specific problem for
download-rustc, it doesn't seem to affect all the compiler's
diagnostics. In particular, various `mir-opt` tests are failing to
respect `simulate-remapped-path-prefix` (I looked into fixing this but
it seems non-trivial). As a result, we can't remove the normalization in
compiletest that maps `/rustc/<commit>` to `$SRC_DIR`, so this change is
currently untested anywhere except locally.
You can test this locally yourself by setting `rust.remap-debuginfo = true`, running any UI test with `ERROR` annotations, then rerunning the test manually with a dev toolchain to verify it prints `/rustc/FAKE_PREFIX`, not `/rustc/1.71.0`.
Helps with https://github.com/rust-lang/rust/issues/110352.
Rollup of 6 pull requests
Successful merges:
- #110454 (Require impl Trait in associated types to appear in method signatures)
- #111096 (Add support for `cfg(overflow_checks)`)
- #111451 (Note user-facing types of coercion failure)
- #111469 (Fix data race in llvm source code coverage)
- #111494 (Encode `VariantIdx` so we can decode ADT variants in the right order)
- #111499 (asm: loongarch64: Drop efiapi)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Encode `VariantIdx` so we can decode ADT variants in the right order
As far as I can tell, we don't guarantee anything about the ordering of `DefId`s and module children...
The code that motivated this PR (#111483) looks something like:
```rust
#[derive(Protocol)]
pub enum Data {
#[protocol(discriminator(0x00))]
Disconnect(Disconnect),
EncryptionRequest,
/* more variants... */
}
```
The specific macro ([`protocol`](https://github.com/dylanmckay/protocol)) doesn't really matter, but as far as I can tell (from calls to `build_reduced_graph`), the presence of that `#[protocol(..)]` helper attribute causes the def-id of the `Disconnect` enum variant to be collected *after* its siblings, and it shows up after the other variants in `module_children`.
When we decode the variants for `Data` in a child crate (an example test, in this case), this means that the `Disconnect` variant is moved to the end of the variants list, and all of the other variants now have incorrect relative discriminant data, causing the ICE.
This PR fixes this by sorting manually by variant index after they are decoded. I guess there are alternative ways of fixing this, such as not reusing `module_children_non_reexports` to encode the order-sensitive ADT variants, or to do some sorting in `rustc_resolve`... but none of those seemed particularly satisfying either.
~I really struggled to create a reproduction here -- it required at least 3 crates, one of which is a proc macro, and then some code to actually compute discriminants in the child crate... Needless to say, I failed to repro this in a test, but I can confirm that it fixes the regression in #111483.~ Test exists now.
r? `@petrochenkov` but feel free to reassign. ~Again, sorry for no test, but I hope the explanation at least suggests why a fix like this is likely necessary.~ Feedback is welcome.
Fix data race in llvm source code coverage
Fixes#91092 .
Before this patch, increment of counters for code coverage looks like this:
```
movq .L__profc__RNvCsd6wgJFC5r19_3lib6bugaga+8(%rip), %rax
addq $1, %rax
movq %rax, .L__profc__RNvCsd6wgJFC5r19_3lib6bugaga+8(%rip)
```
after this patch:
```
lock incq .L__profc__RNvCs3JgIB2SjHh2_3lib6bugaga+8(%rip)
```
Note user-facing types of coercion failure
When coercing, for example, `Box<A>` into `Box<dyn B>`, make sure that any failure notes mention *those* specific types, rather than mentioning inner types, like "the cast from `A` to `dyn B`".
I expect end-users are often confused when we skip layers of types and only mention the "innermost" part of a coercion, especially when other notes point at HIR, e.g. #111406.
Add support for `cfg(overflow_checks)`
This PR adds support for detecting if overflow checks are enabled in similar fashion as `debug_assertions` are detected. Possible use-case of this, for example, if we want to use checked integer casts in builds with overflow checks, e.g.
```rust
pub fn cast(val: usize)->u16 {
if cfg!(overflow_checks) {
val.try_into().unwrap()
}
else{
vas as _
}
}
```
Resolves#91130.
Require impl Trait in associated types to appear in method signatures
This implements the limited version of TAIT that was proposed in https://github.com/rust-lang/rust/issues/107645#issuecomment-1477899536
Similar to `impl Trait` in return types, `impl Trait` in associated types may only be used within the impl block which it is a part of. To make everything simpler and forward compatible to getting desugared to a plain type alias impl trait in the future, we're requiring that any associated functions or constants that want to register hidden types must be using the associated type in their signature (type of the constant or argument/return type of the associated method. Where bounds mentioning the associated type are ignored).
We have preexisting tests checking that this works transitively across multiple associated types in situations like
```rust
impl Foo for Bar {
type A = impl Trait;
type B = impl Iterator<Item = Self::A>;
fn foo() -> Self::B { ...... }
}
```
A couple of codegen tests are doing
```
// CHECK-NOT: slice_index_len_fail
```
However, that function no longer exists: [the only places](https://github.com/search?q=repo%3Arust-lang%2Frust+slice_index_len_fail&type=code) it occurs in the repo are in those tests.
So this PR updates the tests to check for the absense of the functions that are actually used today to panic for out-of-bounds indexing.
PhantomData: fix documentation wrt interaction with dropck
As far as I could find out, the `PhantomData`-dropck interaction *only* affects code using `may_dangle`. The documentation in the standard library has not been updated for 8 years and thus stems from a time when Rust still used "parametric dropck", before [RFC 1238](https://rust-lang.github.io/rfcs/1238-nonparametric-dropck.html). Back then what the docs said was correct, but with `may_dangle` dropck it stopped being entirely accurate and these days, with NLL, it is actively misleading.
Fixes https://github.com/rust-lang/rust/issues/102810
Fixes https://github.com/rust-lang/rust/issues/70841
Cc `@nikomatsakis` I hope what I am saying here is right.^^
Uplift `clippy::{drop,forget}_{ref,copy}` lints
This PR aims at uplifting the `clippy::drop_ref`, `clippy::drop_copy`, `clippy::forget_ref` and `clippy::forget_copy` lints.
Those lints are/were declared in the correctness category of clippy because they lint on useless and most probably is not what the developer wanted.
## `drop_ref` and `forget_ref`
The `drop_ref` and `forget_ref` lint checks for calls to `std::mem::drop` or `std::mem::forget` with a reference instead of an owned value.
### Example
```rust
let mut lock_guard = mutex.lock();
std::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex
// still locked
operation_that_requires_mutex_to_be_unlocked();
```
### Explanation
Calling `drop` or `forget` on a reference will only drop the reference itself, which is a no-op. It will not call the `drop` or `forget` method on the underlying referenced value, which is likely what was intended.
## `drop_copy` and `forget_copy`
The `drop_copy` and `forget_copy` lint checks for calls to `std::mem::forget` or `std::mem::drop` with a value that derives the Copy trait.
### Example
```rust
let x: i32 = 42; // i32 implements Copy
std::mem::forget(x) // A copy of x is passed to the function, leaving the
// original unaffected
```
### Explanation
Calling `std::mem::forget` [does nothing for types that implement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the value will be copied and moved into the function on invocation.
-----
Followed the instructions for uplift a clippy describe here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
cc `@m-ou-se` (as T-libs-api leader because the uplifting was discussed in a recent meeting)
Don't ICE in layout computation for placeholder types
We use `layout_of` for the built-in `PointerLike` trait to check if a type can be coerced to a `dyn*`.
Since the new solver canonicalizes parameter types to placeholders, that code needs to be able to treat placeholders like params, and for the most part it does, **except** for a call to `is_trivially_sized`. This PR fixes that.
Verify copies of mutable pointers in 2 stages in ReferencePropagation
Fixes#111422
In the first stage, we mark the copies as reborrows, to be checked later.
In the second stage, we walk the reborrow chains to verify that all stages are fully replacable.
The replacement itself mirrors the check, and iterates through the reborrow chain.
r? ``````@RalfJung``````
cc ``````@JakobDegen``````
Fix instrument-coverage tests by using Python to sort instantiation groups
#110942 was intended to fix a set of `-Cinstrument-coverage` tests, but it ended up silently *breaking* those tests on Linux, for annoying reasons detailed at #111171.
Dealing with `diff --ignore-matching-lines` across multiple platforms has been such a hassle that I've instead written a simple Python script that can detect instantiation groups in the output of `llvm-cov show`, and sort them in a predictable order so that they can be used as snapshots for an ordinary invocation of `diff`.
This approach should be much less error-prone, because it can't accidentally ignore the wrong lines, and any unforeseen problems will tend to result in a Python exception or a failing diff.
Update browser-ui-test version to 0.16.0
This new version brings one major improvement: it allows to use the original color format in checks (I plan to slowly continue converting colors back to their "original" format, ie the one used in CSS).
It also provides some improvements in some commands API.
r? `````@notriddle`````
Fix backtrace normalization in ice-bug-report-url.rs
This test case currently fails on s390x, and probably other platforms where the last line of a backtrace does not contain and " at <source location>" specification.
The problem with the existing normalization lines
// normalize-stderr-test "\s*\d{1,}: .*\n" -> ""
// normalize-stderr-test "\s at .*\n" -> ""
is that \s matches all whitespace, including newlines, so the first (but not second) of these regexes may merge multiple lines. Thus the output differs depending on which of these matches on the last line of a backtrace.
As the whitespace used in backtraces is just normal space characters, change both regexes to just match at least one space character instead:
// normalize-stderr-test " +\d{1,}: .*\n" -> ""
// normalize-stderr-test " + at .*\n" -> ""
CFI: Fix SIGILL reached via trait objects
Fix#106547 by transforming the concrete self into a reference to a trait object before emitting type metadata identifiers for trait methods.
use implied bounds when checking opaque types
During opaque type inference, we check for the well-formedness of the hidden type in the opaque type's own environment, not the one of the defining site, which are different in the case of TAIT.
However in the case of associated-type-impl-trait, we don't use implied bounds from the impl header. This caused us to reject the following:
```rust
trait Service<Req> {
type Output;
fn call(req: Req) -> Self::Output;
}
impl<'a, Req> Service<&'a Req> for u8 {
type Output= impl Sized; // we can't prove WF of hidden type `WF(&'a Req)` although it's implied by the impl
//~^ ERROR type parameter Req doesn't live long enough
fn call(req: &'a Req) -> Self::Output {
req
}
}
```
although adding an explicit bound would make it pass:
```diff
- impl<'a, Req> Service<&'a Req> for u8 {
+ impl<'a, Req> Service<&'a Req> for u8 where Req: 'a, {
```
I believe it should pass as we already allow the concrete type to be used:
```diff
impl<'a, Req> Service<&'a Req> for u8 {
- type Output= impl Sized;
+ type Output= &'a Req;
```
Fixes#95922
Builds on #105982
cc ``@lcnr`` (because implied bounds)
r? ``@oli-obk``
You will need to add the following as replacement for the old __rust_*
definitions when not using the alloc shim.
#[no_mangle]
static __rust_no_alloc_shim_is_unstable: u8 = 0;
This PR adds support for detecting if overflow checks are enabled in similar fashion as debug_assertions are detected.
Possible use-case of this, for example, if we want to use checked integer casts in builds with overflow checks, e.g.
```rust
pub fn cast(val: usize)->u16 {
if cfg!(overflow_checks) {
val.try_into().unwrap()
}
else{
vas as _
}
}
```
Resolves#91130.
Tracking issue: #111466.
This test case currently fails on s390x, and probably other
platforms where the last line of a backtrace does not contain
and " at <source location>" specification.
The problem with the existing normalization lines
// normalize-stderr-test "\s*\d{1,}: .*\n" -> ""
// normalize-stderr-test "\s at .*\n" -> ""
is that \s matches all whitespace, including newlines, so the
first (but not second) of these regexes may merge multiple
lines. Thus the output differs depending on which of these
matches on the last line of a backtrace.
As the whitespace used in backtraces is just normal space
characters, change both regexes to just match at least one
space character instead:
// normalize-stderr-test " +\d{1,}: .*\n" -> ""
// normalize-stderr-test " + at .*\n" -> ""
Use proper impl self type for alias impl in rustdoc
We don't want to use `type_of(type_alias)`, we want to use `type_of(impl)` -- this will give us the self type of the impl *properly substituted* in the case that it's an alias.
Fixes#111420
vec-shrink-panik: update expectations to work on LLVM 17
For some reason, the called function is `cleanup` on LLVM 17 instead of `filter`.
r? `@Amanieu`
Fix mishandled `--check-cfg` arguments order
This PR fixes a bug in `--check-cfg` where the order of `--check-cfg=names(a)` and `--check-cfg=values(a,…)` would trip the compiler.
Fixes https://github.com/rust-lang/rust/issues/111291
cc `@taiki-e` `@petrochenkov`
Prevent ICE with broken borrow in closure
r? `@Nilstrieb`
Fixes#108683
This solution isn't ideal, I'm hoping to find a way to continue compilation without ICEing.
Encode types in SMIR
The first commit makes sure we can actually store a Ty<'tcx> (with the lifetime) in the thread local and get it back out. The second commit then introduces types.
r? `@spastorino`
Make alias bounds sound in the new solver (take 2)
Make alias bounds sound in the new solver (in a way that does not require coinduction) by only considering them for projection types whose corresponding trait refs come from a param-env candidate.
That is, given `<T as Trait>::Assoc: Bound`, we only *really* need to consider the alias bound if `T: Trait` is satisfied via a param-env candidate. If it's instead satisfied, e.g., via an user provided impl candidate or a , then that impl should have a concrete type to which we could otherwise normalize `<T as Trait>::Assoc`, and that concrete type is then responsible to prove the `Bound` on it.
Similar consideration is given to opaque types, since we only need to consider alias bounds if we're *not* in reveal-all mode, since similarly we'd be able to reveal the opaque types and prove any bounds that way.
This does not remove that hacky "eager projection replacement" logic from object bounds, which are somewhat like alias bounds. But removing this eager normalization behavior (added in #108333) would require full coinduction to be enabled. Compare to #110628, which does remove this object-bound custom logic but requires coinduction to be sound.
r? `@lcnr`
Support linking to rust dylib with --crate-type staticlib
This allows for example dynamically linking libstd, while statically linking the user crate into an executable or C dynamic library. For this two unstable flags (`-Z staticlib-allow-rdylib-deps` and `-Z staticlib-prefer-dynamic`) are introduced. Without the former you get an error. The latter is the equivalent to `-C prefer-dynamic` for the staticlib crate type to indicate that dynamically linking is preferred when both options are available, like for libstd. Care must be taken to ensure that no crate ends up being merged into two distinct staticlibs that are linked together. Doing so will cause a linker error at best and undefined behavior at worst. In addition two distinct staticlibs compiled by different rustc may not be combined under any circumstances due to some rustc private symbols not being mangled.
To successfully link a staticlib, `--print native-static-libs` can be used while compiling to ask rustc for the linker flags necessary when linking the staticlib. This is an existing flag which previously only listed native libraries. It has been extended to list rust dylibs too. Trying to locate libstd yourself to link against it is not supported and may break if for example the libstd of multiple rustc versions are put in the same directory.
For an example on how to use this see the `src/test/run-make-fulldeps/staticlib-dylib-linkage/` test.
Implement SSA-based reference propagation
Rust has a tendency to create a lot of short-lived borrows, in particular for method calls. This PR aims to remove those short-lived borrows with a const-propagation dedicated to pointers to local places.
This pass aims to transform the following pattern:
```
_1 = &raw? mut? PLACE;
_3 = *_1;
_4 = &raw? mut? *_1;
```
Into
```
_1 = &raw? mut? PLACE;
_3 = PLACE;
_4 = &raw? mut? PLACE;
```
where `PLACE` is a direct or an indirect place expression.
By removing indirection, this pass should help both dest-prop and const-prop to handle more cases.
This optimization is distinct from const-prop and dataflow const-prop since the borrow-reborrow patterns needs to preserve borrowck invariants, especially the uniqueness property of mutable references.
The pointed-to places are computed using a SSA analysis. We suppose that removable borrows are typically temporaries from autoref, so they are by construction assigned only once, and a SSA analysis is enough to catch them. For each local, we store both where and how it is used, in order to efficiently compute the all-or-nothing property. Thanks to `Derefer`, we only have to track locals, not places in general.
---
There are 3 properties that need to be upheld for this transformation to be legal:
- place constness: `PLACE` must refer to the same memory wherever it appears;
- pointer liveness: we must not introduce dereferences of dangling pointers;
- `&mut` borrow uniqueness.
## Constness
If `PLACE` is an indirect projection, if its of the form `(*LOCAL).PROJECTIONS` where:
- `LOCAL` is SSA;
- all projections in `PROJECTIONS` are constant (no dereference and no indexing).
If `PLACE` is a direct projection of a local, we consider it as constant if:
- the local is always live, or it has a single `StorageLive` that dominates all uses;
- all projections are constant.
# Liveness
When performing a substitution, we must take care not to introduce uses of dangling locals.
Using a dangling borrow is UB. Therefore, we assume that for any use of `*x`, where `x` is a borrow, the pointed-to memory is live.
Limitations:
- occurrences of `*x` in an `&raw mut? *x` are accepted;
- raw pointers are allowed to be dangling.
In those 2 case, we do not substitute anything, to be on the safe side.
**Open question:** we do not differentiate borrows of ZST and non-ZST. The UB rules may be
different depending on the layout. Having a different treatment would effectively prevent this
pass from running on polymorphic MIR, which defeats the purpose of MIR opts.
## Uniqueness
For `&mut` borrows, we also need to preserve the uniqueness property:
we must avoid creating a state where we interleave uses of `*_1` and `_2`.
To do it, we only perform full substitution of mutable borrows:
we replace either all or none of the occurrences of `*_1`.
Some care has to be taken when `_1` is copied in other locals.
```
_1 = &raw? mut? _2;
_3 = *_1;
_4 = _1
_5 = *_4
```
In such cases, fully substituting `_1` means fully substituting all of the copies.
For immutable borrows, we do not need to preserve such uniqueness property,
so we perform all the possible substitutions without removing the `_1 = &_2` statement.
