Sized Hierarchy: Part I
This patch implements the non-const parts of rust-lang/rfcs#3729. It introduces two new traits to the standard library, `MetaSized` and `PointeeSized`. See the RFC for the rationale behind these traits and to discuss whether this change makes sense in the abstract.
These traits are unstable (as is their constness), so users cannot refer to them without opting-in to `feature(sized_hierarchy)`. These traits are not behind `cfg`s as this would make implementation unfeasible, there would simply be too many `cfg`s required to add the necessary bounds everywhere. So, like `Sized`, these traits are automatically implemented by the compiler.
RFC 3729 describes changes which are necessary to preserve backwards compatibility given the introduction of these traits, which are implemented and as follows:
- `?Sized` is rewritten as `MetaSized`
- `MetaSized` is added as a default supertrait for all traits w/out an explicit sizedness supertrait already.
There are no edition migrations implemented in this, as these are primarily required for the constness parts of the RFC and prior to stabilisation of this (and so will come in follow-up PRs alongside the const parts). All diagnostic output should remain the same (showing `?Sized` even if the compiler sees `MetaSized`) unless the `sized_hierarchy` feature is enabled.
Due to the use of unstable extern types in the standard library and rustc, some bounds in both projects have had to be relaxed already - this is unfortunate but unavoidable so that these extern types can continue to be used where they were before. Performing these relaxations in the standard library and rustc are desirable longer-term anyway, but some bounds are not as relaxed as they ideally would be due to the inability to relax `Deref::Target` (this will be investigated separately).
It is hoped that this is implemented such that it could be merged and these traits could exist "under the hood" without that being observable to the user (other than in any performance impact this has on the compiler, etc). Some details might leak through due to the standard library relaxations, but this has not been observed in test output.
**Notes:**
- Any commits starting with "upstream:" can be ignored, as these correspond to other upstream PRs that this is based on which have yet to be merged.
- This best reviewed commit-by-commit. I've attempted to make the implementation easy to follow and keep similar changes and test output updates together.
- Each commit has a short description describing its purpose.
- This patch is large but it's primarily in the test suite.
- I've worked on the performance of this patch and a few optimisations are implemented so that the performance impact is neutral-to-minor.
- `PointeeSized` is a different name from the RFC just to make it more obvious that it is different from `std::ptr::Pointee` but all the names are yet to be bikeshed anyway.
- `@nikomatsakis` has confirmed [that this can proceed as an experiment from the t-lang side](https://rust-lang.zulipchat.com/#narrow/channel/435869-project-goals/topic/SVE.20and.20SME.20on.20AArch64.20.28goals.23270.29/near/506196491)
- FCP in https://github.com/rust-lang/rust/pull/137944#issuecomment-2912207485Fixesrust-lang/rust#79409.
r? `@ghost` (I'll discuss this with relevant teams to find a reviewer)
`nominal_obligations` calls `predicates_of` on a `Sized` obligation,
effectively elaborating the trait and making the well-formedness checking
machinery do a bunch of extra work checking a `MetaSized` obligation is
well-formed, but given that both `Sized` and `MetaSized` are built-ins,
if `Sized` is otherwise well-formed, so `MetaSized` will be.
As a performance optimization, skip elaborating the supertraits of
`Sized`, and if a `MetaSized` obligation is being checked, then look for
a `Sized` predicate in the parameter environment. This makes the
`ParamEnv` smaller which should improve compiler performance as it avoids
all the iteration over the larger `ParamEnv`.
These tests just need blessing, they don't have any interesting behaviour
changes.
Some of these tests have new errors because `LegacyReceiver` cannot be
proven to be implemented now that it is also testing for `MetaSized` -
but this is just a consequence of the other errors in the test.
This test case is a reduction from the `hwc` crate on GitHub, following a
crater run. It passes with the next solver but fails on the current
solver due to a known limitation of the current solver. It starts fails
on the current solver with the `sized_hierarchy` changes because `?Sized`
is now a proper bound.
It seems like generics from `non_lifetime_binders` don't have any default
bounds like normal generics, so all of the `?Sized` relaxations need
to be further relaxed with `PointeeSized` for this test to be the
equivalent of before.
These tests necessarily need to change now that `?Sized` is not
sufficient to accept extern types and `PointeeSized` is now necessary. In
addition, the `size_of_val`/`align_of_val` test can now be changed to
expect an error.
When printing impl headers in a diagnostic, the compiler has to account
for `?Sized` implying `MetaSized` and new `MetaSized` and `PointeeSized`
bounds.
With `MetaSized` bounds replacing `?Sized` and being added as a
supertrait, the same relaxations applied to the standard library must be
applied to minicore.
Opting-out of `Sized` with `?Sized` is now equivalent to adding a
`MetaSized` bound, and adding a `MetaSized` or `PointeeSized` bound
is equivalent to removing the default `Sized` bound - this commit
implements this change in `rustc_hir_analysis::hir_ty_lowering`.
`MetaSized` is also added as a supertrait of all traits, as this is
necessary to preserve backwards compatibility.
Unfortunately, non-global where clauses being preferred over item bounds
(where `PointeeSized` bounds would be proven) - which can result in
errors when a `PointeeSized` supertrait/bound/predicate is added to some
items. Rather than `PointeeSized` being a bound on everything, it can
be the absence of a bound on everything, as `?Sized` was.
ignore `run-make` tests that need `std` on targets without `std`
In particular, anything that includes `none` in the target triple, and `nvptx64-nvidia-cuda`. Right now we don't cross-compile the `run-make` tests, but we want to in the future.
This uses `//@ needs-target-std` introduced in https://github.com/rust-lang/rust/pull/142297.
Useful for https://github.com/rust-lang/rust/pull/139244 and https://github.com/rust-lang/rust/pull/141856.
The modified files are based on running https://github.com/rust-lang/rust/pull/141856 locally. It might be that https://github.com/rust-lang/rust/pull/139244 uncovers some additional files, but that PR needs to be rebased (though actually I'd advice to rebase the non-test changes onto this PR, probably faster that way).
r? ``@jieyouxu``
<details>
<summary>vim notes for future me</summary>
Make a file with lines like this
```
/home/folkertdev/rust/rust/tests/run-make/export/disambiguator/rmake.rs:1:1
/home/folkertdev/rust/rust/tests/run-make/invalid-so/rmake.rs:1:1
/home/folkertdev/rust/rust/tests/run-make/no-builtins-attribute/rmake.rs:1:1
/home/folkertdev/rust/rust/tests/run-make/export/extern-opt/rmake.rs:1:1
/home/folkertdev/rust/rust/tests/run-make/link-dedup/rmake.rs:1:1
```
then
```
:set errorformat=%f:%l:%c
:cfile /tmp/files-to-fix.txt
```
```
:copen
:cnext
:cprev
```
are your friends
</details>
Fix RISC-V C function ABI when passing/returning structs containing floats
RISC-V passes structs containing only one or two floats (or a float and integer pair) in registers, as long as the individual floats/integers fit in a single corresponding register (see [the ABI specification](https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/download/v1.0/riscv-abi.pdf) for details). Before this PR, Rust would not check what offset the second float/integer was at, instead assuming that it was at the standard offset for its default alignment. However, as the offset can be affected by `#[repr(align(N))]` and `#[repr(packed)]`, this caused miscompilations (see #115609). To fix this, this PR introduces a `rest_offset` field to `CastTarget` that can be used to explicitly specify at what offset the `rest` part of the cast is located at.
While fixing this, I discovered another bug: the size of the cast target was being used as the size of the MIR return place (when the function was using a `PassMode::Cast` return type). However, the cast target is allowed to be smaller than the size of the actual type, causing a miscompilation. This PR fixes this issue by using the largest of the size of the type and the size of the cast target as the size of the MIR return place, ensuring all reads/writes will be inbounds.
Fixes the RISC-V part of #115609.
cc target maintainers of `riscv64gc-unknown-linux-gnu`: `@kito-cheng` `@michaelmaitland` `@robin-randhawa-sifive` `@topperc`
r? `@workingjubilee`
Expand the automatic implementation of `MetaSized` and `PointeeSized` so
that it is also implemented on non-`Sized` types, just not `ty::Foreign`
(extern type).
Introduce the `MetaSized` and `PointeeSized` traits as supertraits of
`Sized` and initially implement it on everything that currently
implements `Sized` to isolate any changes that simply adding the
traits introduces.
Suggest adding semicolon in user code rather than macro impl details
This PR tries to find the right span (by peeling expansion) so that the suggestion for adding a semicolon is suggested in user code rather than in the expanded code (in the example a macro impl).
Fixesrust-lang/rust#139049
r? `@fmease`
Apply ABI attributes on return types in `rustc_codegen_cranelift`
- The [x86-64 System V ABI standard](https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/master/raw/x86-64-ABI/abi.pdf?job=build) doesn't sign/zero-extend integer arguments or return types.
- But the de-facto standard as implemented by Clang and GCC is to sign/zero-extend arguments to 32 bits (but not return types).
- Additionally, Apple targets [sign/zero-extend both arguments and return values to 32 bits](https://developer.apple.com/documentation/xcode/writing-64-bit-intel-code-for-apple-platforms#Pass-arguments-to-functions-correctly).
- However, the `rustc_target` ABI adjustment code currently [unconditionally extends both arguments and return values to 32 bits](https://github.com/rust-lang/rust/blame/e703dff8fe220b78195c53478e83fb2f68d8499c/compiler/rustc_target/src/callconv/x86_64.rs#L240) on all targets.
- This doesn't cause a miscompilation when compiling with LLVM as LLVM will ignore the `signext`/`zeroext` attribute when applied to return types on non-Apple x86-64 targets.
- Cranelift, however, does not have a similar special case, requiring `rustc` to set the argument extension attribute correctly.
- However, `rustc_codegen_cranelift` doesn't currently apply ABI attributes to return types at all, meaning `rustc_codegen_cranelift` will currently miscompile `i8`/`u8`/`i16`/`u16` returns on x86-64 Apple targets as those targets require sign/zero-extension of return types.
This PR fixes the bug(s) by making the `rustc_target` x86-64 System V ABI only mark return types as sign/zero-extended on Apple platforms, while also making `rustc_codegen_cranelift` apply ABI attributes to return types. The RISC-V and s390x C ABIs also require sign/zero extension of return types, so this will fix those targets when building with `rustc_codegen_cranelift` too.
r? `````@bjorn3`````
Report never type lints in dependencies
This PR marks never type lints (`never_type_fallback_flowing_into_unsafe` & `dependency_on_unit_never_type_fallback`) to be included in cargo's reports / to be emitted when they happen in dependencies.
This PR is based on rust-lang/rust#141936
r? oli-obk
Move metadata object generation for dylibs to the linker code
This deduplicates some code between codegen backends and may in the future allow adding extra metadata that is only known at link time.
Prerequisite of https://github.com/rust-lang/rust/issues/96708.
Reduce precedence of expressions that have an outer attr
Previously, `-Zunpretty=expanded` would expand this program as follows:
```rust
#![feature(stmt_expr_attributes)]
macro_rules! repro {
($e:expr) => {
#[allow(deprecated)] $e
};
}
#[derive(Default)]
struct Thing {
#[deprecated]
field: i32,
}
fn main() {
let thing = Thing::default();
let _ = repro!(thing).field;
}
```
```rs
#![feature(prelude_import)]
#![feature(stmt_expr_attributes)]
#[prelude_import]
use std::prelude::rust_2021::*;
#[macro_use]
extern crate std;
struct Thing {
#[deprecated]
field: i32,
}
#[automatically_derived]
impl ::core::default::Default for Thing {
#[inline]
fn default() -> Thing {
Thing { field: ::core::default::Default::default() }
}
}
fn main() {
let thing = Thing::default();
let _ = #[allow(deprecated)] thing.field;
}
```
This is not the correct expansion. The correct output would have `(#[allow(deprecated)] thing).field` with the attribute applying only to `thing`, not to `thing.field`.
Fix incorrect suggestion when calling an associated type with a type anchor
`sugg_span` here is the span of the call expression.
That span here is the `<Self>::Assoc`, which is exactly what we need here (even though I would expect it to include the arguments, but I guess it doesn't)
r? ``@WaffleLapkin``
One commit with failing tests and one that fixes it for reviewability
closesrust-lang/rust#142473
variadic functions: remove list of supported ABIs from error
I think this list is problematic for multiple reasons:
- It is bound to go out-of-date as it is in a very different place from where we actually define which functions support varagrs (`fn supports_varargs`).
- Many of the ABIs we list only work on some targets; it makes no sense to mention "aapcs" as a possible ABI when building for x86_64. (This led to a lot of confusion in https://github.com/rust-lang/rust/issues/110505 where the author thought they should use "cdecl" and then were promptly told that "cdecl" is not a legal ABI on their target.)
- Typically, when the programmer wrote `extern "foobar"`, it is because they need the "foobar" ABI. It is of little use to tell them that there are other ABIs with which varargs would work.
Cc ``@workingjubilee``
Unimplement unsized_locals
Implements https://github.com/rust-lang/compiler-team/issues/630
Tracking issue here: https://github.com/rust-lang/rust/issues/111942
Note that this just removes the feature, not the implementation, and does not touch `unsized_fn_params`. This is because it is required to support `Box<dyn FnOnce()>: FnOnce()`.
There may be more that should be removed (possibly in follow up prs)
- the `forget_unsized` function and `forget` intrinsic.
- the `unsized_locals` test directory; I've just fixed up the tests for now
- various codegen support for unsized values and allocas
cc ``@JakobDegen`` ``@oli-obk`` ``@Noratrieb`` ``@programmerjake`` ``@bjorn3``
``@rustbot`` label F-unsized_locals
Fixesrust-lang/rust#79409
[rustdoc] Give more information into extracted doctest information
Follow-up of https://github.com/rust-lang/rust/pull/134531.
This update fragment the doctest code into its sub-parts to give more control to the end users on how they want to use it.
The new JSON looks like this:
```json
{
"format_version":2,
"doctests":[
{
"file":"$DIR/extract-doctests-result.rs",
"line":8,
"doctest_attributes":{
"original":"",
"should_panic":false,
"no_run":false,
"ignore":"None",
"rust":true,
"test_harness":false,
"compile_fail":false,
"standalone_crate":false,
"error_codes":[],
"edition":null,
"added_css_classes":[],
"unknown":[]
},
"original_code":"let x = 12;\nOk(())",
"doctest_code":{
"crate_level":"#![allow(unused)]\n",
"code":"let x = 12;\nOk(())",
"wrapper":{
"before":"fn main() { fn _inner() -> core::result::Result<(), impl core::fmt::Debug> {\n",
"after":"\n} _inner().unwrap() }",
"returns_result":true
}
},
"name":"$DIR/extract-doctests-result.rs - (line 8)"
}
]
}
```
for this doctest:
```rust
let x = 12;
Ok(())
```
With this, I think it matches what you need ``@ojeda?`` If so, once merged I'll update the patch I sent to RfL.
r? ``@aDotInTheVoid``
Temporary lifetime extension through tuple struct and tuple variant constructors
This makes temporary lifetime extension work for tuple struct and tuple variant constructors, such as `Some()`.
Before:
```rust
let a = &temp(); // Extended
let a = Some(&temp()); // Not extended :(
let a = Some { 0: &temp() }; // Extended
```
After:
```rust
let a = &temp(); // Extended
let a = Some(&temp()); // Extended
let a = Some { 0: &temp() }; // Extended
```
So, with this change, this works:
```rust
let a = Some(&String::from("hello")); // New: String lifetime now extended!
println!("{a:?}");
```
Until now, we did not extend through tuple struct/variant constructors (like `Some`), because they are function calls syntactically, and we do not want to extend the String lifetime in:
```rust
let a = some_function(&String::from("hello")); // String not extended!
```
However, it turns out to be very easy to distinguish between regular functions and constructors at the point where we do lifetime extension.
In practice, constructors nearly always use UpperCamelCase while regular functions use lower_snake_case, so it should still be easy to for a human programmer at the call site to see whether something qualifies for lifetime extension or not.
This needs a lang fcp.
---
More examples of what will work after this change:
```rust
let x = Person {
name: "Ferris",
job: Some(&Job { // `Job` now extended!
title: "Chief Rustacean",
organisation: "Acme Ltd.",
}),
};
dbg!(x);
```
```rust
let file = if use_stdout {
None
} else {
Some(&File::create("asdf")?) // `File` now extended!
};
set_logger(file);
```
```rust
use std::path::Component;
let c = Component::Normal(&OsString::from(format!("test-{num}"))); // OsString now extended!
assert_eq!(path.components.first().unwrap(), c);
```
Rework how the disallowed qualifier in function type diagnostics are generated
This pull request fixes two independent issues:
1. When qualifiers of a function type ptr are in the wrong order and one of them is async/const (not permitted on function types), the diagnostic suggests removing the incorrect qualifier. Fixes https://github.com/rust-lang/rust/issues/142268, which is an issue created by https://github.com/rust-lang/rust/pull/133151. This is fixed by moving the check into `parse_fn_front_matter`, where better span information is available to generate the right suggestions.
2. When qualifiers of a function type ptr are in the wrong order and one of them is async/const (not permitted on function types), `cargo fix` crashes because "cannot replace slice of data that was already replaced". This is fixed by not generating a suggestion for the "wrong order" diagnostic if the "disallowed qualifier" diagnostic is triggered.
There is a commit with failing tests so the test diff is clearer
r? `@jdonszelmann`
tests: Minicore `extern "gpu-kernel"` feature test
Explicitly cross-build it for GPU targets and check it errors on hosts. A relatively minor cleanup from my other ABI-related PRs that I got tired of rebasing.
bors