[EXPERIMENT] Rollup of 9 pull requests #152476
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: beetrees <[email protected]>
aliases may be rigid even if they don't reference params. If the alias isn't well-formed, trying to normalize it as part of the input should have already failed
This essentially folds the call to `region_from_element` into `RegionInferenceContext`, and simplifies the error variant for this case. It also clarifies the type information on the methods called to emphasise the fact that they only ever use placeholder regions in the diagnostics, and completely ignore any other element.
This also changes the signature of `call_query_method` to not return a value, because its only caller immediately discards the value anyway.
Add note when inherent impl for a alias type defined outside of the crate Fixes rust-lang#141679 r? compiler
… r=tgross35 Fix passing/returning structs with the 64-bit SPARC ABI Fixes the 64-bit SPARC part of rust-lang#115609 by replacing the current implementation with a new implementation modelled on the RISC-V calling convention code ([SPARC ABI reference](https://sparc.org/wp-content/uploads/2014/01/SCD.2.4.1.pdf.gz)). Pinging `sparcv9-sun-solaris` target maintainers: @psumbera @kulikjak Fixes rust-lang#115336 Fixes rust-lang#115399 Fixes rust-lang#122620 Fixes rust-lang#147883 r? @workingjubilee
…li-obk Add field representing types # Add Field Representing Types (FRTs) This PR implements the first step of the field projection lang experiment (Tracking Issue: rust-lang#145383). Field representing types (FRTs) are a new kind of type. They can be named through the use of the `field_of!` macro with the first argument being the type and the second the name of the field (or variant and field in the case of an enum). No nested fields are supported. FRTs natively implement the `Field` trait that's also added in this PR. It exposes information about the field such as the type of the field, the type of the base (i.e. the type that contains the field) and the offset within that base type. Only fields of non-packed structs are supported, fields of enums an unions have unique types for each field, but those do not implement the `Field` trait. This PR was created in collaboration with @dingxiangfei2009, it wouldn't have been possible without him, so huge thanks for mentoring me! I updated my library solution for field projections to use the FRTs from `core` instead of creating my own using the hash of the name of the field. See the [Rust-for-Linux/field-projection `lang-experiment` branch](https://github.com/Rust-for-Linux/field-projection/tree/lang-experiment). ## API added to `core::field` ```rust pub unsafe trait Field { type Base; type Type; const OFFSET: usize; } pub macro field_of($Container:ty, $($fields:expr)+ $(,)?); ``` ## Explanation of Field Representing Types (FRTs) FRTs are used for compile-time & trait-level reflection for fields of structs & tuples. Each struct & tuple has a unique compiler-generated type nameable through the `field_of!` macro. This type natively contains information about the field such as the outermost container, type of the field and its offset. Users may implement additional traits on these types in order to record custom information (for example a crate may define a [`PinnableField` trait](https://github.com/Rust-for-Linux/field-projection/blob/lang-experiment/src/marker.rs#L9-L23) that records whether the field is structurally pinned). They are the foundation of field projections, a general operation that's generic over the fields of a struct. This genericism needs to be expressible in the trait system. FRTs make this possible, since an operation generic over fields can just be a function with a generic parameter `F: Field`. > [!NOTE] > The approach of field projections has changed considerably since this PR was opened. In the end we might not need FRTs, so this API is highly experimental. FRTs should act as though they were defined as `struct MyStruct_my_field<StructGenerics>;` next to the struct. So it should be local to the crate defining the struct so that one can implement any trait for the FRT from that crate. The `Field` traits should be implemented by the compiler & populated with correct information (`unsafe` code needs to be able to rely on them being correct). ## Design Decisions During the development several desirable properties of FRTs were discovered. Either due to simplifying the implementation or because of language design reasons. These decisions are: * FRTs are inhabited ZSTs, they have the same layout as `()` * They only contain type information via the `Field` trait. Their only use of the values is a future ergonomics change that allows skipping turbofish syntax. * This simplifies const-eval. * They are thus also `Freeze` * The coherence check of FRTs amounts to checking coherence of the base type. So `field_of!(Foo, bar)` is local if `Foo` is local (`Bar` is allowed to be foreign). Fundamental types are **not** handled specially, so `field_of!(MaybeUninit<Struct>, value)` still is local to `core` (aside from the fact that non-visible fields cannot be accessed in the first place). * Traits may be implemented for FRTs in the usual way (so if the FRT or the trait is local). There is an exception: * `Drop`: It requires supporting non-ADTs and as such it simplified the implementation to not allow it. A future PR can add this if required. * The `Field` trait is not user-implementable * this also can be lifted in the future, but for now only FRTs will implement it. * FRTs implement all auto traits as well as `Copy` and `Clone`. ## TODOs There are several `FIXME(FRTs)` scattered around the code: - rustdoc doesn't yet support them, this can be implemented later - `src/librustdoc/json/conversions.rs` - Debuginfo and symbol mangling is not implemented, for this PR they aren't important, but later we should implement it - `compiler/rustc_codegen_ssa/src/debuginfo/type_names.rs` - `compiler/rustc_sanitizers/src/cfi/typeid/itanium_cxx_abi/encode.rs` - `compiler/rustc_symbol_mangling/src/v0.rs` - Diagnostics for `field_of!` can be improved - `tests/ui/field_representing_types/nonexistent.rs` - `tests/ui/field_representing_types/non-struct.rs` - `tests/ui/field_representing_types/offset.rs` - `tests/ui/field_representing_types/not-field-if-packed.rs` - `tests/ui/field_representing_types/invalid.rs` - Simple type alias already seem to work, but might need some extra work in `compiler/rustc_hir_analysis/src/hir_ty_lowering/mod.rs`
…=wesleywiser Don't compute FnAbi for LLVM intrinsics in backends ~~This removes support for `extern "unadjusted"` for anything other than LLVM intrinsics. It only makes sense in the context of calling LLVM intrinsics anyway as it exposes the way the LLVM backend internally represents types. Perhaps it should be renamed to `extern "llvm-intrinsic"`?~~ Follow up to rust-lang#148533
…=chenyukang
Add FCW for derive helper attributes that will conflict with built-in attributes
Adds a future-compatibility-warning deny-by-default lint that helps catch invalid derive helper attribute names early.
This issues the lint, saying that `ignore` helper will clash with the built-in `ignore` attribute.
```rust
#![crate_type = "proc-macro"]
#![deny(ambiguous_derive_helpers)]
use proc_macro::TokenStream;
#[proc_macro_derive(Trait, attributes(ignore))]
pub fn example(input: TokenStream) -> TokenStream {
TokenStream::new()
}
```
If you actually tried to use that `ignore` helper attribute, you won't be able to due to the ambiguity:
```rust
#[derive(Trait)]
struct Foo {
#[ignore]
field: (),
}
```
Produces:
```
error[E0659]: `ignore` is ambiguous
--> src/lib.rs:5:7
|
5 | #[ignore]
| ^^^^^^ ambiguous name
|
= note: ambiguous because of a name conflict with a builtin attribute
= note: `ignore` could refer to a built-in attribute
note: `ignore` could also refer to the derive helper attribute defined here
--> src/lib.rs:3:10
|
3 | #[derive(Trait)]
| ^^^^^
```
layout: handle rigid aliases without params fixes rust-lang#151791 r? types
…ror-handling, r=lcnr Borrowck: simplify diagnostics for placeholders This folds the call to `region_from_element` into `RegionInferenceContext`, and simplifies the error variant for this case to only talk about regions as opposed to elements. This is the only case where a `RegionElement` leaks out of region inference, so now they can be considered internal to region inference (though that currently isn't expressed). It also clarifies the type information on the methods called to emphasise the fact that they only ever use placeholder regions in the diagnostics completely ignore any other element. It also adds a bunch of FIXMEs to some fishy statements that conjure universes from what seems like arbitrary integers. This was lifted from rust-lang#142623. r? @lcnr
Add note for `?Sized` params in int-ptr casts diag Close rust-lang#74756
Clarify names of `QueryVTable` functions for "executing" a query In the query system, there are several layers of functions involved in “executing” a query, with very different responsibilities at each layer, making it important to be able to tell them apart. This PR renames two of the function pointers in `QueryVTable`, along with their associated helper functions, to hopefully do a better job of indicating what their actual responsibilities are. r? nnethercote
rustbot
added
A-attributes
rustbot
added
T-clippy
Member
Author
|
(Not a real rollup; just running some early try jobs on the approved PRs not in the main rollup.) @bors try jobs=x86_64-msvc-1,i686-msvc-1,x86_64-mingw-1,test-various,armhf-gnu,aarch64-apple |
This comment has been minimized.
This comment has been minimized.
rust-bors bot
pushed a commit
that referenced
this pull request
Feb 11, 2026
Rollup of 9 pull requests try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: x86_64-mingw-1 try-job: test-various try-job: armhf-gnu try-job: aarch64-apple
Zalathar
changed the title
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
rust-bors
bot
added
S-waiting-on-author
Contributor
|
💔 Test for 4f6a0db failed: CI. Failed job:
|
rustbot
removed
the
S-waiting-on-author
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
11 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
?Sizedparams in int-ptr casts diag #152159 (Add note for?Sizedparams in int-ptr casts diag)QueryVTablefunctions for "executing" a query #152434 (Clarify names ofQueryVTablefunctions for "executing" a query)r? @ghost
Create a similar rollup