vectorcall ABI: require SSE2
According to the official docs at https://learn.microsoft.com/en-us/cpp/cpp/vectorcall, SSE2 is required for this ABI. Add a check that enforces this.
I put this together with the other checks ensuring the target features required for a function are present... however, since the ABI is known pre-monomorphization, it would be possible to do this check earlier, which would have the advantage of checking even in `cargo check`. It would have the disadvantage of spreading this code in yet more places.
The first commit just does a little refactoring of the mono-time ABI check to make it easier to add the new check.
Cc `@workingjubilee`
try-job: dist-i586-gnu-i586-i686-musl
Fix "missing match arm body" suggestion involving `!`
Include the match arm guard in the gated span, so that the suggestion to add a body is correct instead of inserting the body before the guard.
Make the suggestion verbose.
```
error: `match` arm with no body
--> $DIR/feature-gate-never_patterns.rs:43:9
|
LL | Some(_) if false,
| ^^^^^^^^^^^^^^^^
|
help: add a body after the pattern
|
LL | Some(_) if false => { todo!() },
| ++++++++++++++
```
r? `@compiler-errors`
Improve a bit HIR pretty printer
This PR improve (a bit) the HIR pretty printer.
It does so by:
- Not printing elided lifetimes (those are not expressible in surface Rust anyway)
- And by rendering implicit self with the shorthand syntax
I also tried fixing some indentation and other things but gave up for now.
Best reviewed commit by commit.
[Debuginfo] Add MSVC Synthetic and Summary providers to LLDB
Adds handling for `tuple$<>`, `ref$<slice$2<>`, `ref$<str$>` and `enum2$<>`.
Also fixes a bug in MSVC vec/string handling where the script was unable to determine the element's type due to LLDB ignoring template arg debug information
<details>
<summary>Sample code</summary>
```rust
pub enum Number {
One = 57,
Two = 99,
}
#[repr(u8)]
pub enum Container {
First(u32),
Second { val: u64, val2: i8 },
Third,
}
...
let u8_val = b'a';
let float = 42.78000000000001;
let tuple = (u8_val, float);
let str_val = "eef";
let mut string = "freef".to_owned();
let mut_str = string.as_mut_str();
let array: [u8; 4] = [1, 2, 3, 4];
let ref_array = array.as_slice();
let mut array2: [u32; 4] = [1, 2, 3, 4];
let mut_array = array2.as_mut_slice();
let enum_val = Number::One;
let mut enum_val2 = Number::Two;
let sum_val = Container::First(15);
let sum_val_2 = Container::Second { val: 0, val2: 0 };
let sum_val_3 = Container::Third;
let non_zero = NonZeroU128::new(100).unwrap();
let large_discr = NonZeroU128::new(255);
```
</details>
Before:
After:
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: x86_64-mingw-1
try-job: i686-mingw
try-job: aarch64-gnu
Remove invalid suggestion of into_iter for extern macro
Fixes#137345#109082 is closed due to performance issue, do we have any other solution for this kind of issue?
Give `global_asm` a fake body to store typeck results, represent `sym fn` as a hir expr to fix `sym fn` operands with lifetimes
There are a few intertwined problems with `sym fn` operands in both inline and global asm macros.
Specifically, unlike other anon consts, they may evaluate to a type with free regions in them without actually having an item-level type annotation to give them a "proper" type. This is in contrast to named constants, which always have an item-level type annotation, or unnamed constants which are constrained by their position (e.g. a const arg in a turbofish, or a const array length).
Today, we infer the type of the operand by looking at the HIR typeck results; however, those results are region-erased, so during borrowck we ICE since we don't expect to encounter erased regions. We can't just fill this type with something like `'static`, since we may want to use real (free) regions:
```rust
fn foo<'a>() {
asm!("/* ... */", sym bar::<&'a ()>);
}
```
The first idea may be to represent `sym fn` operands using *inline* consts instead of anon consts. This makes sense, since inline consts can reference regions from the parent body (like the `'a` in the example above). However, this introduces a problem with `global_asm!`, which doesn't *have* a parent body; inline consts *must* be associated with a parent body since they are not a body owner of their own. In #116087, I attempted to fix this by using two separate `sym` operands for global and inline asm. However, this led to a lot of confusion and also some unattractive code duplication.
In this PR, I adjust the lowering of `global_asm!` so that it's lowered in a "fake" HIR body. This body contains a single expression which is `ExprKind::InlineAsm`; we don't *use* this HIR body, but it's used in typeck and borrowck so that we can properly infer and validate the the lifetimes of `sym fn` operands.
I then adjust the lowering of `sym fn` to instead be represented with a HIR expression. This is both because it's no longer necessary to represent this operand as an anon const, since it's *just* a path expression, and also more importantly to sidestep yet another ICE (https://github.com/rust-lang/rust/issues/137179), which has to do with the existing code breaking an invariant of def-id creation and anon consts. Specifically, we are not allowed to synthesize a def-id for an anon const when that anon const contains expressions with def-ids whose parent is *not* that anon const. This is somewhat related to https://github.com/rust-lang/rust/pull/130443#issuecomment-2445678945, which is also a place in the compiler where synthesizing anon consts leads to def-id parenting issue.
As a side-effect, this consolidates the type checking for inline and global asm, so it allows us to simplify `InlineAsmCtxt` a bit. It also allows us to delete a bit of hacky code from anon const `type_of` which was there to detect `sym fn` operands specifically. This also could be generalized to support `const` asm operands with types with lifetimes in them. Since we specifically reject these consts today, I'm not going to change the representation of those consts (but they'd just be turned into inline consts).
r? oli-obk -- mostly b/c you're patient and also understand the breadth of the code that this touches, please reassign if you don't want to review this.
Fixes#111709Fixes#96304Fixes#137179
Inject `compiler_builtins` during postprocessing and ensure it is made private
Follow up of https://github.com/rust-lang/rust/pull/135278
Do the following:
* Inject `compiler_builtins` during postprocessing, rather than injecting `extern crate compiler_builtins as _` into the AST
* Do not make dependencies of `std` private by default (this was added in #135278)
* Make sure sysroot crates correctly mark their dependencies private/public
* Ensure that marking a dependency private makes its dependents private by default as well, unless otherwise specified
* Do the `compiler_builtins` update that has been blocked on this
There is more detail in the commit messages. This includes the changes I was working on in https://github.com/rust-lang/rust/pull/136226.
try-job: test-various
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: i686-mingw-1
try-job: i686-mingw-2
In Rust 1.81, we added a FCW lint (including linting in dependencies)
against pointer casts that add an auto trait to dyn bounds. This was
part of work making casts of pointers involving trait objects stricter
which was needed to restabilize trait upcasting.
We considered just making this a hard error at the time, but opted
against it due to breakage found by crater. This breakage was mostly
due to the `anymap` crate which has been a persistent problem for us.
It's now a year later, and the fact that this is not yet a hard error
is giving us pause about stabilizing arbitrary self types and
`derive(CoercePointee)`. So let's now make a hard error of this.
Include the match arm guard in the gated span, so that the suggestion to add a body is correct instead of inserting the body before the guard.
Make the suggestion verbose.
```
error: `match` arm with no body
--> $DIR/feature-gate-never_patterns.rs:43:9
|
LL | Some(_) if false,
| ^^^^^^^^^^^^^^^^
|
help: add a body after the pattern
|
LL | Some(_) if false => { todo!() },
| ++++++++++++++
```
Ferris 🦀 Identifier naming conventions
You cannot use Ferris as an identifier in Rust, this code will suggest to correct the 🦀 to `ferris`:
```rs
fn main() {
let 🦀 = 4;
}
```
But it also suggests to correct to `ferris` in these cases, too:
```rs
struct 🦀 {}
fn main() {}
```
^ suggests: `ferris`
~ with this PR: `Ferris`
```rs
static 🦀: &str = "ferris!";
fn main() {}
```
^ suggests: `ferris`
~ with this PR: `FERRIS`
This is my first pull requests here!
test building enzyme in CI
1) This PR fixes a significant compile-time regression, by only running the expensive autodiff pipeline, if the users pass the newly introduced Enable value to the `-Zautodiff=` flag. It updates the test(s) accordingly. It gives a nice error if users forget that.
2) It fixes macos support by explicitly linking against the Enzyme build folder. This doesn't cover CI macos yet.
3) It fixes the issue that setting ENZYME_RUNPASS was ignored by enzyme and in fact did not schedule enzyme's opt pass.
4) It also re-enables support for various other values for the autodiff flag, which were ignored since the refactor.
5) I merged some improvements to Enzyme core, which means we do not longer depend on LLVM being build with the Plugin Interface enabled.
6) Unrelated to other fixes, this changes `rustc_autodiff` to `EncodeCrossCrate::Yes`. It is not enough on it's own to enable usage of Enzyme in libraries, but it is for sure a piece of the fixes needed to get this to work.
try-job: x86_64-gnu
r? `@oli-obk`
Tracking:
- https://github.com/rust-lang/rust/issues/124509
Remove `NtVis` and `NtTy`
The next part of #124141. The first actual remove of `Nonterminal` variants. `NtVis` is a simple case that doesn't get much use, but `NtTy` is more complex.
r? `@petrochenkov`
Rollup of 8 pull requests
Successful merges:
- #136458 (Do not deduplicate list of associated types provided by dyn principal)
- #136474 ([`compiletest`-related cleanups 3/7] Make the distinction between sources root vs test suite sources root in compiletest less confusing)
- #136592 (Make sure we don't overrun the stack in canonicalizer)
- #136787 (Remove `lifetime_capture_rules_2024` feature)
- #137207 (Add #[track_caller] to Duration Div impl)
- #137245 (Tweak E0277 when predicate comes indirectly from ?)
- #137257 (Ignore fake borrows for packed field check)
- #137399 (fix ICE in layout computation with unnormalizable const)
r? `@ghost`
`@rustbot` modify labels: rollup
fix ICE in layout computation with unnormalizable const
The first commit reverts half of 7a667d206c, where I removed a case from `layout_of` for handling non-generic unevaluated consts in array length, that I incorrectly assumed to be unreachable. This can actually happen with the combination of `feature(generic_const_exprs)` and `feature(trivial_bounds)`, because GCE makes anon consts inherit their parent's predicates and with an impossible predicate like `u8: A` it's possible to have an array whose length is an associated const like `<u8 as A>::B` that is not generic, but also can't be normalized:
```rust
#![feature(generic_const_exprs)]
#![feature(trivial_bounds)]
trait A {
const B: usize;
}
// With GCE + trivial bounds this definition is not a compile error.
// Computing the layout of this type shouldn't ICE.
struct S([u8; <u8 as A>::B])
where
u8: A;
```
---
The first commit also incidentally fixes https://github.com/rust-lang/rust/issues/137308, which also managed to get an unnormalizable assoc const into an array length:
```rust
trait A {
const B: usize;
}
impl<C: ?Sized> A for u8 { //~ ERROR: the type parameter `C` is not constrained
const B: usize = 42;
}
// Computing the layout of this type shouldn't ICE, even with the compile error above.
struct S([u8; <u8 as A>::B]);
```
This happens, because we bail out from `codegen_select_candidate` with an error if the selected impl has unconstrained params to avoid leaking infer vars out of a query. `Instance::try_resolve` will then return `Ok(None)`, which for assoc consts roughly means "this const can't be evaluated in a generic context" and is treated as such: 71e06b9c59/compiler/rustc_middle/src/mir/interpret/queries.rs (L84) (and this can ICE if the const isn't generic: https://github.com/rust-lang/rust/issues/135617).
However, here `<u8 as A>::B` is definitely not "too generic" and also not unresolvable due to an unsatisfiable `u8: A` bound, so I've included the second commit to change the result of `Instance::try_resolve` from `Ok(None)` to `Err(ErrorGuaranteed)` when resolving an assoc item to an impl with unconstrained generic params. This has the effect that `<u8 as A>::B` will now be normalized to `ConstKind::Error` in the example above.
This properly fixes https://github.com/rust-lang/rust/issues/137308, by no longer treating `<u8 as A>::B` as unresolvable even though it clearly has a unique impl that it resolves to. It also has the effect of changing the layout error from `Unknown` ("the type may be valid but has no sensible layout") to `ReferencesError` ("a non-layout error is reported elsewhere") which seems more appropriate.
r? ```@compiler-errors```
Ignore fake borrows for packed field check
We should not emit unaligned packed field reference errors for the fake borrows that we generate during match lowering.
These fake borrows are there to ensure in *borrow-checking* that we don't modify the value being matched (which is why this only occurs when there's a match guard, in this case `if true`), but they are removed after the MIR is processed by `CleanupPostBorrowck`, since they're really just there to cause borrowck errors if necessary.
I modified `PlaceContext::is_borrow` since that's used by the packed field check:
17c1c329a5/compiler/rustc_mir_transform/src/check_packed_ref.rs (L40)
It's only used in one other place, in the SROA optimization (by which fake borrows are removed, so it doesn't matter):
17c1c329a5/compiler/rustc_mir_dataflow/src/value_analysis.rs (L922)
Fixes https://github.com/rust-lang/rust/issues/137250
Tweak E0277 when predicate comes indirectly from ?
When a `?` operation requires an `Into` conversion with additional bounds (like having a concrete error but wanting to convert to a trait object), we handle it speficically and provide the same kind of information we give other `?` related errors.
```
error[E0277]: `?` couldn't convert the error: `E: std::error::Error` is not satisfied
--> $DIR/bad-question-mark-on-trait-object.rs:7:13
|
LL | fn foo() -> Result<(), Box<dyn std::error::Error>> {
| -------------------------------------- required `E: std::error::Error` because of this
LL | Ok(bar()?)
| -----^ the trait `std::error::Error` is not implemented for `E`
| |
| this has type `Result<_, E>`
|
note: `E` needs to implement `std::error::Error`
--> $DIR/bad-question-mark-on-trait-object.rs:1:1
|
LL | struct E;
| ^^^^^^^^
= note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
= note: required for `Box<dyn std::error::Error>` to implement `From<E>`
```
Avoid talking about `FromResidual` when other more relevant information is being given, particularly from `rust_on_unimplemented`.
Fix#137238.
-----
CC #137232, which was a smaller step related to this.
More sophisticated span trimming for suggestions
Previously #136958 only cared about prefixes or suffixes. Now it detects more cases where a suggestion is "sandwiched" by unchanged code on the left or the right. Would be cool if we could detect several insertions, like `ACE` going to `ABCDE`, extracting `B` and `D`, but that seems unwieldy.
r? `@estebank`
```
error[E0277]: `?` couldn't convert the error: `E: std::error::Error` is not satisfied
--> $DIR/bad-question-mark-on-trait-object.rs:7:13
|
LL | fn foo() -> Result<(), Box<dyn std::error::Error>> {
| -------------------------------------- required `E: std::error::Error` because of this
LL | Ok(bar()?)
| -----^ the trait `std::error::Error` is not implemented for `E`
| |
| this has type `Result<_, E>`
|
note: `E` needs to implement `std::error::Error`
--> $DIR/bad-question-mark-on-trait-object.rs:1:1
|
LL | struct E;
| ^^^^^^^^
= note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
= note: required for `Box<dyn std::error::Error>` to implement `From<E>`
error[E0277]: `?` couldn't convert the error to `X`
--> $DIR/bad-question-mark-on-trait-object.rs:18:13
|
LL | fn bat() -> Result<(), X> {
| ------------- expected `X` because of this
LL | Ok(bar()?)
| -----^ the trait `From<E>` is not implemented for `X`
| |
| this can't be annotated with `?` because it has type `Result<_, E>`
|
note: `X` needs to implement `From<E>`
--> $DIR/bad-question-mark-on-trait-object.rs:4:1
|
LL | struct X;
| ^^^^^^^^
note: alternatively, `E` needs to implement `Into<X>`
--> $DIR/bad-question-mark-on-trait-object.rs:1:1
|
LL | struct E;
| ^^^^^^^^
= note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
```
Currently, marking a dependency private does not automatically make all
its child dependencies private. Resolve this by making its children
private by default as well.
This also resolves some FIXMEs for tests that are intended to fail but
previously passed.
[1]: https://github.com/rust-lang/rust/pull/135501#issuecomment-2620242419
`compiler_builtins` is currently injected as `extern crate
compiler_builtins as _`. This has made gating via diagnostics difficult
because it appears in the crate graph as a non-private dependency, and
there isn't an easy way to differentiate between the injected AST and
user-specified `extern crate compiler_builtins`.
Resolve this by injecting `compiler_builtins` during postprocessing
rather than early in the AST. Most of the time this isn't even needed
because it shows up in `std` or `core`'s crate graph, but injection is
still needed to ensure `#![no_core]` works correctly.
A similar change was attempted at [1] but this encountered errors
building `proc_macro` and `rustc-std-workspace-std`. Similar failures
showed up while working on this patch, which were traced back to
`compiler_builtins` showing up in the graph twice (once via dependency
and once via injection). This is resolved by not injecting if a
`#![compiler_builtins]` crate already exists.
[1]: https://github.com/rust-lang/rust/pull/113634
Use a probe to avoid registering stray region obligations when re-checking drops in MIR typeck
Fixes#137288.
See the comment I left on the probe. I'm not totally sure why this depends on *both* an unconstrained type parameter in the impl and a type error for the self type, but I think the fix is at least theoretically well motivated.
r? ```@matthewjasper```
Reduce `Box::default` stack copies in debug mode
The `Box::new(T::default())` implementation of `Box::default` only
had two stack copies in debug mode, compared to the current version,
which has four. By avoiding creating any `MaybeUninit<T>`'s and just writing
`T` directly to the `Box` pointer, the stack usage in debug mode remains
the same as the old version.
Another option would be to mark `Box::write` as `#[inline(always)]`,
and change it's implementation to to avoid calling `MaybeUninit::write`
(which creates a `MaybeUninit<T>` on the stack) and to use `ptr::write` instead.
Fixes: #136043
