compiler: fix duplicated "the" in two doc-comments
Two one-line typo fixes for duplicated "the" in compiler doc-comments:
- `compiler/rustc_type_ir/src/solve/mod.rs` — "only if any of the the opaques in the opaque type storage has a hidden type" → "...any of the opaques in..."
- `compiler/rustc_borrowck/src/diagnostics/var_name.rs` — "/// Find the the name and span of the variable corresponding to the given region." → "/// Find the name and span of the variable corresponding to the given region."
No code/behavior change.
Revert tearing changes to `dbg!`
Since the primary change to `dbg!` in rust-lang/rust#149869, we've been chasing a few regressions:
* rust-lang/rust#153850, fixed by rust-lang/rust#154074
* rust-lang/rust#154988, fixed by rust-lang/rust#154994
* rust-lang/rust#155902, proposed fix in rust-lang/rust#155915
We already reverted this once, on beta only to prevent these regressions from shipping in 1.95.
In that most recent PR, we decided that it would be better to revert `dbg!` to its original state everywhere (`main` and 1.96-`beta`), and then we can consider it from scratch later. So here I've reverted the change and its fixes, but kept the regression tests, including the pending one.
cc @joboet @dianne @rust-lang/libs
@rustbot label beta-nominated
[style] rustfmt `match`es with comments in or-patterns
Using https://github.com/rust-lang/rustfmt/pull/6893, I reformatted the whole codebase. The result is that `match`es that *should have* been formatted under normal circumstances but are getting skipped now got their expected format. These match expressions were being entirely skipped because they contain or-patterns with comments in between patterns, causing rustfmt to bail out entirely. The or-patterns with comments themselves remain untouched, but now the match arm bodies and other patterns without comments do get formatted under that PR.
Because the fix in rustfmt isn't landed yet, I reworked some of the or-patterns with comments so that formatting doesn't regress. Tried doing this only in larger blocks that are more likely to regress in the meantime.
(Introduced and) removed a bunch of stray backticks \` likely left after an editor autoclosed the intended closing \`, resulting in <code>\`name\`\`</code> in comments.
Hand-written Debug implementation for `TypeTest`
This adds a hand-written debug format for `TypeTest`s that at least was helpful for me when debugging because I always struggle to remember which component is which. It formats a type test using the Unicode turnstile symbol (for "computes") to illustrate that the test encodes a typing rule that, if it holds, produces a conclusion.
The format is: `TypeTest from {originating span} {bound} ⊢ T: 'lower_bound`, where `T` is the generic type being tested and `lower_bound` is the lower bound. Bounds are formatted as you would expect, but where the region for `'lower_bound` is included in the outlives constraints for context. I resisted the urge to turn `ALL [A, ..., Z]` into `[A ∧ ... ∧ Z]` etc.
## What it looks like
Here's an example of a simple type test from the test suite that says that some type `I/#0` will be lower-bounded (outlive) `?4` iff `'?1: '?4`:
Before:
```
$ RUSTC_LOG="rustc_borrowck::region_infer=debug" rustc +stage1 tests/ui/associated-types/associated-types-eq-3.rs
...
DEBUG rustc_borrowck::region_infer type tests: [
TypeTest {
generic_kind: I/#0,
lower_bound: '?4,
span: tests/ui/associated-types/associated-types-eq-3.rs:21:18: 21:25 (#0),
verify_bound: OutlivedBy(
'?1,
),
},
TypeTest {
generic_kind: I/#0,
lower_bound: '?4,
span: tests/ui/associated-types/associated-types-eq-3.rs:21:18: 21:25 (#0),
verify_bound: OutlivedBy(
'?1,
),
},
]
...
```
After:
```
$ RUSTC_LOG="rustc_borrowck::region_infer=debug" rustc +stage1 tests/ui/associated-types/associated-types-eq-3.rs
...
DEBUG rustc_borrowck::region_infer type tests: [
TypeTest from tests/ui/associated-types/associated-types-eq-3.rs:21:18: 21:25 (#0)['?1: '?4] ⊢ I/#0: '?4,
TypeTest from tests/ui/associated-types/associated-types-eq-3.rs:21:18: 21:25 (#0)['?1: '?4] ⊢ I/#0: '?4,
]
...
```
Using https://github.com/rust-lang/rustfmt/pull/6893, reformat the codebase. The result is that matches that *would have* been formatted under normal circumstances get their expected format. These match expressions were being entirely skipped because they contain or-patterns with comments in between patterns, causing rustfmt to bail out entirely. The or-patterns with comments themselves remain untouched, but now the match arm bodies and other patterns without comments do get formatted under that PR.
Because the fix in rustfmt isn't landed yet, I reworked some of the or-patterns with comments so that formatting doesn't regress. Tried doing this only in larger blocks that are more likely to regress in the meantime.
Unnormalized migration: assert_fully_normalized, struct_tail, and `field.ty`
tracking issue: https://github.com/rust-lang/rust/issues/155345 (first checkbox, and partial second checkbox, of that issue)
I'm going a bit slower than expected (less free time than I'd hope, lots of GCA work that I'm doing instead), and figured I'd just submit what I have now rather than building up a big batch of changes. Slow and steady!
r? @lcnr
Fix 'assign to data in an index of' collection suggestions
fixes https://github.com/rust-lang/rust/issues/150001
fixes https://github.com/rust-lang/rust-analyzer/issues/16076
fixes https://github.com/rust-lang/rust/issues/134917
The issues are threefold and linked:
1. Assigning data to a ~~collection~~BTreeMap/HashMap suggests 3 solutions all marked as `MachineApplicable`
2. The suggestions are slightly wrong with regards to their borrowing needs.
3. The suggestions are not guaranteed to produce code that is valid, and suggestion number two is equivalent to an update, not an insertion.
This PR:
- splits the large triple suggestion into three
- sets them to `MaybeIncorrect`
- automatically determines the required borrowing to use.
I think this solution may not be very elegant, expecially the key typechecking / borrowing part, but it works. I am however very open to any improvement/change :)
edit: edited to replace 'collection' with BTreeMap/HashMap'
Make retags an implicit part of typed copies
Ever since Stacked Borrows was first implemented in Miri, that was done with `Retag` statements: given a place (usually a local variable), those statements find all references stored inside the place and refresh their tags to ensure the aliasing requirements are upheld. However, this is a somewhat unsatisfying approach for multiple reasons:
- It leaves open the [question](https://github.com/rust-lang/unsafe-code-guidelines/issues/371) of where to even put `Retag` statements. Over time, the AddRetag pass settled on one possible answer to this, but it wasn't very canonical.
- For assignments of the form `*ptr = expr`, if the assignment involves copying a reference, we probably want to do a retag -- but if we do a `Retag(*ptr)` as the next instruction, it can be non-trivial to argue that this even retags the right value, so we refrained from doing retags in that case. This has [come up](https://github.com/llvm/llvm-project/pull/160913#issuecomment-3341908717) as a potential issue for Rust making better use of LLVM "captures" annotations. (That said, there might be [other ways](https://github.com/rust-lang/unsafe-code-guidelines/issues/593#issuecomment-4328112031) to obtain this desired optimization.)
- Normal compilation avoids generating retags, but we still generate LLVM IR with `noalias`. What does that even mean? How do MIR optimization passes interact with retags? These are questions we have to figure out to make better use of aliasing information, but currently we can't even really ask such questions.
I think we should resolve all that by making retags part of what happens during a typed copy (a concept and interpreter infrastructure that did not exist yet when retags were initially introduced). Under this proposal, when executing a MIR assignment statement, what conceptually happens is as follows:
- We evaluate the LHS to a place.
- We evaluate the RHS to a value. This does a typed load from memory if needed, raising UB if memory does not contain a valid representation of the assignment's type.
- We walk that value, identify all references inside of it, and retag them. If this happens as part of passing a function argument, this is a protecting retag.
- We store (a representation of) the value into the place.
However, this semantics doesn't fully work: there's a mandatory MIR pass that turns expressions like `&mut ***ptr` into intermediate deref's. Those must *not* do any retags. So far this happened because the AddRetag pass did not add retags for assignments to deref temporaries, but that information is not recorded in cross-crate MIR. Therefore I instead added a field to `Rvalue::Use` to indicate whether this value should be retagged or not. A non-retagging copy seems like a sufficiently canonical primitive that we should be able to express it. Dealing with the fallout from that is a large chunk of the overall diff. (I also considered adding this field to `StatementKind::Assign` instead, but decided against that as we only actually need it for `Rvalue::Use`. I am not sure if this was the right call...)
This neatly answers the question of when retags should occur, and handles cases like `*ptr = expr`. It avoids traversing values twice in Miri. It makes codegen's use of `noalias` sound wrt the actual MIR that it is working on. It also gives us a target semantics to evaluate MIR opts against. However, I did not carefully check all MIR opts -- in particular, GVN needs a thorough look under the new semantics; it currently can turn alias-correct code into alias-incorrect code. (But this PR doesn't make things any worse for normal compilation where the retag indicator is anyway ignored.)
Another side-effect of this PR is that `-Zmiri-disable-validation` now also disables alias checking. It'd be nicer to keep them orthogonal but I find this an acceptable price to pay.
- [rustc benchmark results](https://github.com/rust-lang/rust/pull/154341#issuecomment-4125313290)
- [miri benchmark results](https://github.com/rust-lang/rust/pull/154341#issuecomment-4129840926)
Do not depend on typeck to borrow-check inline consts.
Instead fetch the type from the inline-const's MIR, which comes from exactly the same typeck information.
Add extra symbol check for `.to_owned()`
Follow up of rust-lang/rust#154646
Previously when adding a suggestion for using `Cow::into_owned()` instead of `ToOwned::to_owned()`, the compiler would just convert the methods `Span` into a `String` and do checks on that `String`. This PR adds an extra guard to that suggestion by checking if the method is `sym::to_owned_method`.
r? @davidtwco since you added the review to the previous PR
Previously when adding a suggestion for using `Cow::into_owned()`
instead of `ToOwned::to_owned()`, the compiler would just convert the
methods `Span` into a `String` and do checks on that `String`. This PR
adds an extra guard to that suggestion by checking if the method is
`sym::to_owned_method`.
added a valid example that violated the assumption in the proposed
change: it is possible for a borrowee type to be a ref of it's borrowed
type.
removed the assumption, treated all cases appropriately.
Add a `Local::arg(i)` helper constructor
While reading through stuff I was noticing just how many `+1` fixes there were in various places (and comments explaining those fixups), so this adds a new inherent helper on `Local` for making an argument to help make this clearer.
r? mir
Clean up some traits
I was looking at various traits and found some unnecessary trait bounds, and some unnecessary traits. Details in individual commits.
r? @Nadrieril
While reading through stuff I was noticing just how many `+1` fixes there were in various places (and comments explaining that fixup), so this adds a new inherent helper on `Local` for making an argument to help make this clearer.
When you have `impl Foo for Bar` and `Bar` has no generics it's useless
(and odd) to have `where Self: Baz` bounds on methods when the trait
itself doesn't have those bounds. This commit removes a few.
Avoid misleading return-type note for foreign `Fn` callees
Fixesrust-lang/rust#155727.
The issue occurred because the code that emitted the `Fn`/`FnMut` suggestion only avoided the return-type fallback when it could point at a local callee argument. The local case from rust-lang/rust#125325 was fixed in rust-lang/rust#126226, but nested cross-crate cases could still suggest changing the enclosing function's return type even though the relevant `Fn` requirement came from the callee argument.
This is also the broader diagnostic shape discussed in rust-lang/rust#119985.
This PR checks the instantiated callee predicates for an exact `Fn` bound
on the closure argument, and extends `wrong-closure-arg-suggestion-125325` with cross-crate function and method cases for that path.
Remove duplicated `Flags` methods.
The `Flags` trait has two methods: `flags` and `outer_exclusive_binder`. Multiple types impl this trait and then also have duplicate inherent methods with the same names; these are all marked with "Think about removing this" comments. This is left over from things being moved into `rustc_type_ir`.
This commit removes those inherent methods. This requires adding `use Flags` to a number of files.
r? @lcnr
Jonathan Brouwer