Clang and GCC both return `i128` in xmm0 on windows-msvc and
windows-gnu. Currently, Rust returns the type on the stack. Add a
calling convention adjustment so we also return scalar `i128`s using the
vector ABI, which makes our `i128` compatible with C.
In the future, Clang may change to return `i128` on the stack for its
`-msvc` targets (more at [1]). If this happens, the change here will
need to be adjusted to only affect MinGW.
Link: https://github.com/rust-lang/rust/issues/134288
Treat safe target_feature functions as unsafe by default [less invasive variant]
This unblocks
* #134090
As I stated in https://github.com/rust-lang/rust/pull/134090#issuecomment-2541332415 I think the previous impl was too easy to get wrong, as by default it treated safe target feature functions as safe and had to add additional checks for when they weren't. Now the logic is inverted. By default they are unsafe and you have to explicitly handle safe target feature functions.
This is the less (imo) invasive variant of #134317, as it doesn't require changing the Safety enum, so it only affects FnDefs and nothing else, as it should.
Rollup of 7 pull requests
Successful merges:
- #132397 (Make missing_abi lint warn-by-default.)
- #133807 (ci: Enable opt-dist for dist-aarch64-linux builds)
- #134143 (Convert `struct FromBytesWithNulError` into enum)
- #134338 (Use a C-safe return type for `__rust_[ui]128_*` overflowing intrinsics)
- #134678 (Update `ReadDir::next` in `std::sys::pal::unix::fs` to use `&raw const (*p).field` instead of `p.byte_offset().cast()`)
- #135424 (Detect unstable lint docs that dont enable their feature)
- #135520 (Make sure we actually use the right trivial lifetime substs when eagerly monomorphizing drop for ADTs)
r? `@ghost`
`@rustbot` modify labels: rollup
Make sure we actually use the right trivial lifetime substs when eagerly monomorphizing drop for ADTs
Absolutely clueless mistake of mine. Whoops.
When eagerly collecting mono items, when we encounter an ADT, we try to monomorphize its drop glue. In #135313, I made it so that this acts more like eagerly monomorphizing functions, where we allow (in this case) ADTs with lifetimes, since those can be erased by codegen.
However, I did not account for the call to `instantiate_and_check_impossible_predicates`, which was still passing an empty set of args. This means that if the ADT in question had any predicates, we'd get an index out of bounds panic.
This PR creates the correct set of args for the ADT.
Fixes#135515. I assume that this manifests in that issue because of `-Clink-dead-code` or something.
Use a C-safe return type for `__rust_[ui]128_*` overflowing intrinsics
Combined with [1], this will change the overflowing multiplication operations to return an `extern "C"`-safe type.
Link: https://github.com/rust-lang/compiler-builtins/pull/735 [1]
Do not consider traits that have unsatisfied const conditions to be conditionally const
This will improve error messages as we continue to constify traits, since we don't want to start calling things "conditionally const" if they aren't implemented with a const impl anyways.
The only case that this affects today is `Deref` since that's one of the only constified traits in the standard library :)
r? RalfJung
Enforce syntactical stability of const traits in HIR
This PR enforces what I'm calling *syntactical* const stability of traits. In other words, it enforces the ability to name `~const`/`const` traits in trait bounds in various syntax positions in HIR (including in the trait of an impl header). This functionality is analogous to the *regular* item stability checker, which is concerned with making sure that you cannot refer to unstable items by name, and is implemented as an extension of that pass.
This is separate from enforcing the *recursive* const stability of const trait methods, which is implemented in MIR and runs on MIR bodies. That will require adding a new `NonConstOp` to the const checker and probably adjusting some logic to deduplicate redundant errors.
However, this check is separate and necessary for making sure that users don't add `~const`/`const` bounds to items when the trait is not const-stable in the first place. I chose to separate enforcing recursive const stability out of this PR to make it easier to review. I'll probably open a follow-up following this one, blocked on this PR.
r? `@RalfJung` cc `@rust-lang/project-const-traits`
Make sure we can produce `ConstArgHasWrongType` errors for valtree consts
I forgot about `ty::ConstKind::Value` in #134771.
The error message here could use some work -- both in the new trait solver and the old trait solver. But unrelated to the issue here.
Fixes https://github.com/rust-lang/rust/issues/135361 -- this was only ICEing in coherence because coherence uses the new trait solver, but I don't think the minimization is worth committing compared to the test I added.
r? ```@lcnr``` or ```@BoxyUwU```
Improve `DispatchFromDyn` and `CoerceUnsized` impl validation
* Disallow arbitrary 1-ZST fields in `DispatchFromDyn` -- only `PhantomData`, and 1-ZSTs that mention no params (which is needed to support, e.g., the `Global` alloctor in `Box<T, U = Global>`).
* Don't allow coercing between non-ZSTs to ZSTs (since the previous check wasn't actually checking the field tys were the same before checking the layout...)
* Normalize the field before checking it's `PhantomData`.
Fixes#135215Fixes#135214Fixes#135220
r? ```@BoxyUwU``` or reassign
Make sure to scrape region constraints from deeply normalizing type outlives assumptions in borrowck
Otherwise we're just randomly registering these region relations into the infcx which isn't good
r? lcnr
Rollup of 7 pull requests
Successful merges:
- #134216 (Enable "jump to def" feature on patterns)
- #134880 (Made `Path::name` only have item name rather than full name)
- #135466 (Leak check in `impossible_predicates` to avoid monomorphizing impossible instances)
- #135476 (Remove remnant of asmjs)
- #135479 (mir borrowck: cleanup late-bound region handling)
- #135493 (Fix legacy symbol mangling of closures)
- #135495 (Add missing closing backtick in commit hook message 🐸)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix legacy symbol mangling of closures
When this code was written, there was no `type_of` implementation for closures. That has long since been changed.
In the UI test:
```
trait A where
[(); (|| {}, 1).1]: Sized,
{
}
```
We tried to walk up the def path tree for the closure, from closure -> anon const -> trait. When we reached the trait, we tried to call `type_of` on it which obviously doesn't do the right thing and ICEs.
Fixes#135418
Eagerly mono drop for structs with lifetimes
That is, use `!generics.requires_monomorphization()` rather than `generics.is_empty()` like the rest of the mono collector code.
Exclude dependencies of `std` for diagnostics
Currently crates in the sysroot can show up in diagnostic suggestions, such as in https://github.com/rust-lang/rust/issues/135232. To prevent this, duplicate `all_traits` into `visible_traits` which only shows traits in non-private crates.
Setting `#![feature(rustc_private)]` overrides this and makes items in private crates visible as well, since `rustc_private` enables use of `std`'s private dependencies.
This may be reviewed per-commit.
Fixes: https://github.com/rust-lang/rust/issues/135232
In order to avoid diagnostics suggesting stdlib-private dependencies,
make everything that is a direct dependency of any `std` crates private
by default. Note that this will be overridden, if the same crate is
public elsewhere in the crate graph then that overrides the private
default.
It may also be feasible to do this in the library crate, marking `std`'s
dependencies private via Cargo. However, given that the feature is still
rather unstable, doing this within the compiler seems more
straightforward.
Fixes: https://github.com/rust-lang/rust/issues/135232 [1]
Add an alternative to `tcx.all_traits()` that only shows traits that the
user might be able to use, for diagnostic purposes. With this available,
make use of it for diagnostics including associated type errors, which
is part of the problem with [1].
Includes a few comment updates for related API.
[1]: https://github.com/rust-lang/rust/issues/135232
Really this is always-visible override only needs to happen when the
crate is a dependency of itself. However, this is a very internal
feature, so it doesn't seem worth doing any additional filtering here.
Currently `root` or `crate_root` is used to refer to an instance of
`CrateRoot` (representation of a crate's serialized metadata), but the
name `root` sometimes also refers to a `CratePath` representing a "root"
node in the dependency graph. In order to disambiguate, rename all
instances of the latter to `dep_root`.
fix ICE with references to infinite structs in consts
fixes https://github.com/rust-lang/rust/issues/114484
Normalizing `<Type as Pointee>::Metadata` may emit a (non-fatal) error during trait selection if finding the struct tail of `Type` hits the recursion limit. When this happens, prior this PR, we would treat the projection as rigid, i.e. don't normalize it further. This PR changes it so that we normalize to `ty::Error` instead.
This is important, because to compute the layout of `&Type` we need to compute the layout of `<Type as Pointee>::Metadata`
2ae9916816/compiler/rustc_ty_utils/src/layout.rs (L247-L273)
and computing the layout of a rigid alias will (correctly) fail and needs to report an error to the user. For example:
```rust
trait Project {
type Assoc;
}
fn foo<T: Project>() {
[(); {
let _: Option<T::Assoc> = None;
// ^^^^^^^^ this projection is rigid, so we can't know it's layout
0
}];
}
```
```
error: constant expression depends on a generic parameter
--> src/lib.rs:6:10
|
6 | [(); {
| __________^
7 | | let _: Option<T::Assoc> = None;
8 | | // ^^^^^^^^ this projection is rigid, so we can't know it's layout
9 | | 0
10 | | }];
| |_____^
|
= note: this may fail depending on what value the parameter takes
```
For non-generic rigid projections we will currently ICE, because we incorrectly assume that `LayoutError::Unknown` means that a const must be generic (https://github.com/rust-lang/rust/issues/135138). This is being fixed and turned into a proper error in https://github.com/rust-lang/rust/pull/135158.
```rust
#![feature(trivial_bounds)]
trait Project {
type Assoc;
}
fn foo()
where
u8: Project,
{
[(); {
let _: Option<<u8 as Project>::Assoc> = None; // ICEs currently, but will be an error
0
}];
}
```
However, if we hit the recursion limit when normalizing `<Type as Pointee>::Metadata` we don't want to report a layout error, because we already emitted the recursion error. So by normalizing to `ty::Error` here, we get a `LayoutError::ReferencesError` instead of a `LayoutError::Unknown` and don't report the layout error to the user.
Remove code duplication when hashing query result and interning node
Refactored the duplicated code into a function.
`with_feed_task` currently passes the query key to `debug_assert!`. I believe that's a mistake, since `with_task` prints the `DepNode` which is more sensible, so this commit changes that, so it debug prints the `DepNode`.
Fix emscripten-wasm-eh with unwind=abort
If we build the standard library with wasm-eh then we need to link with `-fwasm-exceptions` even if we compile with `panic=abort`.
Without this change, linking a `panic=abort` crate fails with: `undefined symbol: __cpp_exception`.
Followup to #131830.
r? workingjubilee
Make sure to mark `IMPL_TRAIT_REDUNDANT_CAPTURES` as `Allow` in edition 2024
I never got sign-off on #127672 for this lint being warn by default in edition 2024, so let's turn downgrade this lint to allow for now.
Should be backported so it ships with the edition.
```@rustbot``` label: +beta-nominated
