Simplify slice indexing in next trait solver
Unless I'm missing something:
- no need to explicitly specify the end of the slice as the end of the index range
- the `assert` is redundant since the indexing will panic for the same condition
I think this change simplifies it a bit. Also replaced the `for` loop of `push`es with a call to `extend` with an iterator. Might improve performance since it knows how many elements will be added beforehand and can pre-reserve room?
r? `@compiler-errors` , I think
Rollup of 7 pull requests
Successful merges:
- #136073 (Always compute coroutine layout for eagerly emitting recursive layout errors)
- #136235 (Pretty print pattern type values with transmute if they don't satisfy their pattern)
- #136311 (Ensure that we never try to monomorphize the upcasting or vtable calls of impossible dyn types)
- #136315 (Use short ty string for binop and unop errors)
- #136393 (Fix accidentally not emitting overflowing literals lints anymore in patterns)
- #136435 (Simplify some code for lowering THIR patterns)
- #136630 (Change two std process tests to not output to std{out,err}, and fix test suite stat reset in bootstrap CI test rendering)
r? `@ghost`
`@rustbot` modify labels: rollup
try-job: aarch64-gnu-debug
Simplify some code for lowering THIR patterns
I've been playing around with some radically different ways of storing THIR patterns, and while those experiments haven't yet produced a clear win, I have noticed various smaller things in the existing code that can be made a bit nicer.
Some of the more significant changes:
- With a little bit of extra effort (and thoughtful use of Arc), we can completely remove an entire layer of `'pat` lifetimes from the intermediate data structures used for match lowering.
- In several places, lists of THIR patterns were being double-boxed for no apparent reason.
Fix accidentally not emitting overflowing literals lints anymore in patterns
This was regressed in https://github.com/rust-lang/rust/pull/134228 (not in beta yet).
The issue was that previously we nested `hir::Expr` inside `hir::PatKind::Lit`, so it was linted by the expression code.
So now I've set it up for visitors to be able to directly visit literals and get all literals
Use short ty string for binop and unop errors
```
error[E0369]: cannot add `(..., ..., ..., ...)` to `(..., ..., ..., ...)`
--> $DIR/binop.rs:10:7
|
LL | x + x;
| - ^ - (..., ..., ..., ...)
| |
| (..., ..., ..., ...)
|
= note: the full name for the type has been written to '$TEST_BUILD_DIR/$FILE.long-type-hash.txt'
= note: consider using `--verbose` to print the full type name to the console
```
```
error[E0600]: cannot apply unary operator `!` to type `(..., ..., ..., ...)`
--> $DIR/binop.rs:14:5
|
LL | !x;
| ^^ cannot apply unary operator `!`
|
= note: the full name for the type has been written to '$TEST_BUILD_DIR/$FILE.long-type-hash.txt'
= note: consider using `--verbose` to print the full type name to the console
```
CC #135919.
Ensure that we never try to monomorphize the upcasting or vtable calls of impossible dyn types
Check for impossible obligations in the `dyn Trait` type we're trying to compute its the vtable upcasting and method call slots.
r? lcnr
Pretty print pattern type values with transmute if they don't satisfy their pattern
Instead of printing `0_u32 is 1..`, we now print the default fallback rendering that we also use for invalid bools, chars, ...: `{transmute(0x00000000): (u32) is 1..=}`.
These cases can occur in mir dumps when const prop propagates a constant across a safety check that would prevent the actually UB value from existing. That's fine though, as it's dead code and we always need to allow UB in dead code.
follow-up to https://github.com/rust-lang/rust/pull/136176
cc ``@compiler-errors`` ``@scottmcm``
r? ``@RalfJung`` because of the interpreter changes
Always compute coroutine layout for eagerly emitting recursive layout errors
Detect recursive coroutine layouts even if we don't detect opaque type recursion in the new solver. This is for two reasons:
1. It helps us detect (bad) recursive async function calls in the new solver, which due to its approach to normalization causes us to not detect this via a recursive RPIT (since the opaques are more eagerly revealed in the opaque body).
* Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/137.
2. It helps us detect (bad) recursive async functions behind AFITs. See the AFIT test that changed for the old solver too.
3. It also greatly simplifies the recursive impl trait check, since I can remove some jankness around how it handles coroutines.
tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc`
tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc`
This is continuation of https://github.com/rust-lang/rust/pull/132282 .
I'm pretty sure I did everything right. In particular, I searched all occurrences of `Lrc` in submodules and made sure that they don't need replacement.
There are other possibilities, through.
We can define `enum Lrc<T> { Rc(Rc<T>), Arc(Arc<T>) }`. Or we can make `Lrc` a union and on every clone we can read from special thread-local variable. Or we can add a generic parameter to `Lrc` and, yes, this parameter will be everywhere across all codebase.
So, if you think we should take some alternative approach, then don't merge this PR. But if it is decided to stick with `Arc`, then, please, merge.
cc "Parallel Rustc Front-end" ( https://github.com/rust-lang/rust/issues/113349 )
r? SparrowLii
`@rustbot` label WG-compiler-parallel
cg_llvm: Remove the `mod llvm_` hack, which should no longer be necessary
This re-export was introduced in c76fc3d804, as a workaround for #53912.
In short, there was/is an assumption in some LLVM LTO code that symbol names would not contain `.llvm.`, but legacy symbol mangling would naturally produce that sequence for symbols in a module named `llvm`.
This was later “fixed” by adding a special case to the legacy symbol mangler in #61195, which detects the sequence `llvm` and emits the `m` in an escaped form. As a result, there should no longer be any need to avoid the module name `llvm` in the compiler itself.
(Symbol mangling v0 avoids this problem by not using `.` in the first place, outside of the “vendor-specific suffix”.)
Only highlight unmatchable parameters at the definition site
Followup to #136497
This generally results more focused messages in the same vein as #99635 (see `test/ui/argument-suggestions/complex.rs`). There are still some cases (e.g. `test/ui/argument-suggestions/permuted_arguments.rs`) where it might be worth highlighting the arguments. This is mitigated by the fact that a suggestion with a suggested rearrangement is given.
r? `@compiler-errors`
Document why some "type mismatches" exist
Just something I stumbled over and thought to save myself (and maybe others) the research time when encountering it again.
Pass spans around new solver
...so that when we instantiate canonical responses, we can actually have region obligations with the right span.
Within the solver itself, we still use dummy spans everywhere.
Avoid using make_direct_deprecated() in extern "ptx-kernel"
This method will be removed in the future as it produces a broken ABI that depends on cg_llvm implementation details. After this PR wasm32-unknown-unknown is the only remaining user of make_direct_deprecated().
Fixes https://github.com/rust-lang/rust/issues/117271
Blocks https://github.com/rust-lang/rust/issues/38788
We have four macros for generating trivial traversal (fold/visit) and
lift impls.
- `rustc_ir::TrivialTypeTraversalImpls`
- `rustc_middle::TrivialTypeTraversalImpls`
- `rustc_middle::TrivialLiftImpls`
- `rustc_middle::TrivialTypeTraversalAndLiftImpls`
The first two are very similar. The last one just combines the second
and third one.
The macros themselves are ok, but their use is a mess. This commit does
the following.
- Removes types that no longer need a lift and/or traversal impl from
the macro calls.
- Consolidates the macro calls into the smallest number of calls
possible, with each one mentioning as many types as possible.
- Orders the types within those macro calls alphabetically, and makes
the module qualification more consistent.
- Eliminates `rustc_middle::mir::type_foldable`, because the macro calls
were merged and the manual `TypeFoldable` impls are better placed in
`structural_impls.rs`, alongside all the other ones.
This makes the code more concise. Moving forward, it also makes it more
obvious where new types should be added.
Reject negative literals for unsigned or char types in pattern ranges and literals
It sucks a bit that we have to duplicate the work here (normal expressions just get this for free from the `ExprKind::UnOp(UnOp::Neg, ...)` typeck logic.
In https://github.com/rust-lang/rust/pull/134228 I caused
```rust
fn main() {
match 42_u8 {
-10..255 => {},
_ => {}
}
}
```
to just compile without even a lint.
I can't believe we didn't have tests for this
Amusingly https://github.com/rust-lang/rust/pull/136302 will also register a delayed bug in `lit_to_const` for this, so we'll have a redundancy if something like this fails again.
Upgrade elsa to the newest version.
This was locked to 1.7.1 because of an error in the elsa release process that has since been fixed. Upgrading has the advantage that the elsa code runs properly in miri, at least with tree borrows.
This was spawned from https://github.com/rust-lang/rust/issues/135870#issuecomment-2612470540
cg_llvm: Replace some DIBuilder wrappers with LLVM-C API bindings (part 1)
Part of #134001, follow-up to #136326, extracted from #134009.
This PR performs an arbitrary subset of the LLVM-C binding migrations from #134009, which should make it less tedious to review. The remaining migrations can occur in one or more subsequent PRs.
