| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Provide a new function `listify`, meant to be used in cases similar to `pluralize!`. When you have a slice of arbitrary elements that need to be presented to the user, `listify` allows you to turn that into a list of comma separated strings.
This reduces a lot of redundant logic that happens often in diagnostics.
|
|
Compiler: Finalize dyn compatibility renaming
Update the Reference link to use the new URL fragment from https://github.com/rust-lang/reference/pull/1666 (this change has finally hit stable). Fixes a FIXME.
Follow-up to #130826.
Part of #130852.
~~Blocking it on #133372.~~ (merged)
r? ghost
|
|
Fix deduplication mismatches in vtables leading to upcasting unsoundness
We currently have two cases where subtleties in supertraits can trigger disagreements in the vtable layout, e.g. leading to a different vtable layout being accessed at a callsite compared to what was prepared during unsizing. Namely:
### #135315
In this example, we were not normalizing supertraits when preparing vtables. In the example,
```
trait Supertrait<T> {
fn _print_numbers(&self, mem: &[usize; 100]) {
println!("{mem:?}");
}
}
impl<T> Supertrait<T> for () {}
trait Identity {
type Selff;
}
impl<Selff> Identity for Selff {
type Selff = Selff;
}
trait Middle<T>: Supertrait<()> + Supertrait<T> {
fn say_hello(&self, _: &usize) {
println!("Hello!");
}
}
impl<T> Middle<T> for () {}
trait Trait: Middle<<() as Identity>::Selff> {}
impl Trait for () {}
fn main() {
(&() as &dyn Trait as &dyn Middle<()>).say_hello(&0);
}
```
When we prepare `dyn Trait`, we see a supertrait of `Middle<<() as Identity>::Selff>`, which itself has two supertraits `Supertrait<()>` and `Supertrait<<() as Identity>::Selff>`. These two supertraits are identical, but they are not duplicated because we were using structural equality and *not* considering normalization. This leads to a vtable layout with two trait pointers.
When we upcast to `dyn Middle<()>`, those two supertraits are now the same, leading to a vtable layout with only one trait pointer. This leads to an offset error, and we call the wrong method.
### #135316
This one is a bit more interesting, and is the bulk of the changes in this PR. It's a bit similar, except it uses binder equality instead of normalization to make the compiler get confused about two vtable layouts. In the example,
```
trait Supertrait<T> {
fn _print_numbers(&self, mem: &[usize; 100]) {
println!("{mem:?}");
}
}
impl<T> Supertrait<T> for () {}
trait Trait<T, U>: Supertrait<T> + Supertrait<U> {
fn say_hello(&self, _: &usize) {
println!("Hello!");
}
}
impl<T, U> Trait<T, U> for () {}
fn main() {
(&() as &'static dyn for<'a> Trait<&'static (), &'a ()>
as &'static dyn Trait<&'static (), &'static ()>)
.say_hello(&0);
}
```
When we prepare the vtable for `dyn for<'a> Trait<&'static (), &'a ()>`, we currently consider the PolyTraitRef of the vtable as the key for a supertrait. This leads two two supertraits -- `Supertrait<&'static ()>` and `for<'a> Supertrait<&'a ()>`.
However, we can upcast[^up] without offsetting the vtable from `dyn for<'a> Trait<&'static (), &'a ()>` to `dyn Trait<&'static (), &'static ()>`. This is just instantiating the principal trait ref for a specific `'a = 'static`. However, when considering those supertraits, we now have only one distinct supertrait -- `Supertrait<&'static ()>` (which is deduplicated since there are two supertraits with the same substitutions). This leads to similar offsetting issues, leading to the wrong method being called.
[^up]: I say upcast but this is a cast that is allowed on stable, since it's not changing the vtable at all, just instantiating the binder of the principal trait ref for some lifetime.
The solution here is to recognize that a vtable isn't really meaningfully higher ranked, and to just treat a vtable as corresponding to a `TraitRef` so we can do this deduplication more faithfully. That is to say, the vtable for `dyn for<'a> Tr<'a>` and `dyn Tr<'x>` are always identical, since they both would correspond to a set of free regions on an impl... Do note that `Tr<for<'a> fn(&'a ())>` and `Tr<fn(&'static ())>` are still distinct.
----
There's a bit more that can be cleaned up. In codegen, we can stop using `PolyExistentialTraitRef` basically everywhere. We can also fix SMIR to stop storing `PolyExistentialTraitRef` in its vtable allocations.
As for testing, it's difficult to actually turn this into something that can be tested with `rustc_dump_vtable`, since having multiple supertraits that are identical is a recipe for ambiguity errors. Maybe someone else is more creative with getting that attr to work, since the tests I added being run-pass tests is a bit unsatisfying. Miri also doesn't help here, since it doesn't really generate vtables that are offset by an index in the same way as codegen.
r? `@lcnr` for the vibe check? Or reassign, idk. Maybe let's talk about whether this makes sense.
<sup>(I guess an alternative would also be to not do any deduplication of vtable supertraits (or only a really conservative subset) rather than trying to normalize and deduplicate more faithfully here. Not sure if that works and is sufficient tho.)</sup>
cc `@steffahn` -- ty for the minimizations
cc `@WaffleLapkin` -- since you're overseeing the feature stabilization :3
Fixes #135315
Fixes #135316
|
|
Rollup of 9 pull requests
Successful merges:
- #135026 (Cast global variables to default address space)
- #135475 (uefi: Implement path)
- #135852 (Add `AsyncFn*` to `core` prelude)
- #136004 (tests: Skip const OOM tests on aarch64-unknown-linux-gnu)
- #136157 (override build profile for bootstrap tests)
- #136180 (Introduce a wrapper for "typed valtrees" and properly check the type before extracting the value)
- #136256 (Add release notes for 1.84.1)
- #136271 (Remove minor future footgun in `impl Debug for MaybeUninit`)
- #136288 (Improve documentation for file locking)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
and remove `ty::Const::try_to_scalar` because it becomes redundant
|
|
Co-authored-by: FedericoBruzzone <federico.bruzzone.i@gmail.com>
|
|
|
|
Allow transmuting generic pattern types to and from their base
Pattern types always have the same size as their base type, so we can just ignore the pattern and look at the base type for figuring out whether transmuting is possible.
|
|
miri: optimize zeroed alloc
When allocating zero-initialized memory in MIR interpretation, rustc allocates zeroed memory, marks it as initialized and then re-zeroes it. Remove the last step.
I don't expect this to have much of an effect on performance normally, but in my case in which I'm creating a large allocation via mmap it gets in the way.
|
|
Rollup of 9 pull requests
Successful merges:
- #136121 (Deduplicate operand creation between scalars, non-scalars and string patterns)
- #136134 (Fix SIMD codegen tests on LLVM 20)
- #136153 (Locate asan-odr-win with other sanitizer tests)
- #136161 (rustdoc: add nobuild typescript checking to our JS)
- #136166 (interpret: is_alloc_live: check global allocs last)
- #136168 (GCI: Don't try to eval / collect mono items inside overly generic free const items)
- #136170 (Reject unsound toggling of Arm atomics-32 target feature)
- #136176 (Render pattern types nicely in mir dumps)
- #136186 (uefi: process: Fix args)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Render pattern types nicely in mir dumps
avoid falling through to the fallback rendering that just does a hex dump
r? ``@scottmcm``
best reviewed commit by commit
|
|
|
|
|
|
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
|
|
Use identifiers more in diagnostics code
This should make the diagnostics code slightly more correct when rendering idents in mixed crate edition situations. Kinda a no-op, but a cleanup regardless.
r? oli-obk or reassign
|
|
Add a workaround for parallel rustc crashing when there are delayed bugs
This doesn't fix the root cause of this crash, but at least stops it from happening for the time being.
Workaround for https://github.com/rust-lang/rust/issues/135870
|
|
|
|
- `check-pass` test for a MRE of #135020
- fail test for #135138
- switch to `TooGeneric` for checking CMSE fn signatures
- switch to `TooGeneric` for compute `SizeSkeleton` (for transmute)
- fix broken tests
|
|
|
|
Get rid of `mir::Const::from_ty_const`
This function is strange, because it turns valtrees into `mir::Const::Value`, but the rest of the const variants stay as type system consts.
All of the callsites except for one in `instsimplify` (array length simplification of `ptr_metadata` call) just go through the valtree arm of the function, so it's easier to just create a `mir::Const` directly for those.
For the instsimplify case, if we have a type system const we should *keep* having a type system const, rather than turning it into a `mir::Const::Value`; it doesn't really matter in practice, though, bc `usize` has no padding, but it feels more principled.
|
|
formatting traits
|
|
This doesn't fix the root cause of this crash, but at least stops it
from happening for the time being.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add gpu-kernel calling convention
The amdgpu-kernel calling convention was reverted in commit f6b21e90d1ec01081bc2619efb68af6788a63d65 (#120495 and https://github.com/rust-lang/rust-analyzer/pull/16463) due to inactivity in the amdgpu target.
Introduce a `gpu-kernel` calling convention that translates to `ptx_kernel` or `amdgpu_kernel`, depending on the target that rust compiles for.
Tracking issue: #135467
amdgpu target tracking issue: #135024
|
|
Rollup of 7 pull requests
Successful merges:
- #134754 (Implement `use` associated items of traits)
- #135481 (coverage: Completely overhaul counter assignment, using node-flow graphs)
- #135504 (Allow coercing safe-to-call target_feature functions to safe fn pointers)
- #135561 (Update docs for `-Clink-dead-code` to discourage its use)
- #135574 (ci: mirror ubuntu:22.04 to ghcr.io)
- #135585 (resolve symlinks of LLVM tool binaries before copying them)
- #135588 (Add license-metadata.json to rustc-src tarball.)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Use trait definition cycle detection for trait alias definitions, too
fixes #133901
In general doing this for `All` is not right, but this code path is specifically for traits and trait aliases, and there we only ever use `All` for trait aliases.
|
|
|
|
The amdgpu-kernel calling convention was reverted in commit
f6b21e90d1ec01081bc2619efb68af6788a63d65 due to inactivity in the amdgpu
target.
Introduce a `gpu-kernel` calling convention that translates to
`ptx_kernel` or `amdgpu_kernel`, depending on the target that rust
compiles for.
|
|
r=wesleywiser
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.
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
De-abstract tagged ptr and make it covariant
In #135272 I needed to use a tagged ptr in `hir::TyKind` in order to not regress hir type sizes. Unfortunately the existing `CopyTaggedPtr` abstraction is insufficient as it makes the `'hir` lifetime invariant.
I spent some time trying to keep existing functionality while making it covariant but in the end I realised that actually we dont use *any* of this code *anywhere* in rustc, so I've just removed everything and replaced it with a much less general abstraction that is suitable for what I need in #135272.
Idk if anyone has a preference for just keeping all the abstractions here in case anyone needs them in the future :woman_shrugging:
|
|
|
|
Remove a bunch of diagnostic stashing that doesn't do anything
#121669 removed a bunch of conditional diagnostic stashing/canceling, but left around the `steal` calls which just emitted the error eagerly instead of canceling the diagnostic. I think that these no-op `steal` calls don't do much and are confusing to encounter, so let's remove them.
The net effect is:
1. We emit more duplicated errors, since stashing has the side effect of duplicating diagnostics. This is not a big deal, since outside of `-Zdeduplicate-diagnostics=no`, the errors are already being deduplicated by the compiler.
2. It changes the order of diagnostics, since we're no longer stashing and then later stealing the errors. I don't think this matters much for the changes that the UI test suite manifests, and it makes these errors less order dependent.
|
|
|
|
This should make it clearer that this bitset is dense, with the
advantages and disadvantages that it entails.
|
