core: make atomic primitives type aliases of `Atomic<T>`
Tracking issue: https://github.com/rust-lang/rust/issues/130539
This makes `AtomicI32` and friends type aliases of `Atomic<T>` by encoding their alignment requirements via the use of an internal `Storage` associated type. This is also used to encode that `AtomicBool` store a `u8` internally.
Modulo the `Send`/`Sync` implementations, this PR does not move any trait implementations, methods or associated functions – I'll leave that for another PR.
Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`
It was discovered that the FileCheck tests when performing an `Option::or` operation on a slice was failing when tested on a big endian host.
The compiler explorer link is here outlining the codegen output differences - https://rust.godbolt.org/z/qdE7d3G4f
This MR relaxes the constraints for the `*slice_u8` variants of the test (by changing `CHECK-NEXT` to `CHECK-DAG`), whilst still maintaining the check for the necessary `or` logic.
Huge thanks to @Gelbpunkt for identifying this issue! It has been confirmed that this fix passes on a big endian target now as well.
Closesrust-lang/rust#151718
add tests for thumb interworking
fixes https://github.com/rust-lang/rust/issues/151946
thumb programs (using a 16-bit instruction encoding) can call arm (32-bit instruction encoding) code. Doing so requires switching from thumb mode to arm mode, executing, then switching back. Test that this happens correctly, in particular for naked functions.
cc @thejpster can you confirm the output looks good here and that we're testing all of the relevant things
r? jieyouxu because this is doing some interesting things testing-wise
I believe that we need run-make here because we need to look at the assembly after the linker has run. It will correct calls from thumb to arm: depending on the thumb version this either uses a special instruction or inserts a call to a thunk that handles switching between thumb and arm mode.
diags: Pass `DiagArgMap` instead of `FluentArgs` into `format_diag_message`
This PR no longer exposes `FluentArgs` outside of `translation.rs`, instead using the already existing `DiagArgMap`.
This is in preparation of a few upcoming PRs, as well as just making the code slightly nicer.
Will do a perf run because this technically calls `to_fluent_args` a few more times than previously, but not expecting this to be significant
Introduce --ci flag in tidy
## Context
Currently tidy doesn't have `--ci` flag. Even if bootstrap has --ci=true, it isn't passed to tidy. As a result, some parts of tidy where we need to turn on `ci mode` are never executed on our local.
## Change
This PR introduces --ci flag in tidy, and modify CiInfo and other parts of tidy where currently use `CiEnv::is_ci()` for checking if the running environment is ci or not.
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#146989 (Inhibit all-absent-variant optimization for all enum reprs that inhibit layout optimization, not just repr(C).)
- rust-lang/rust#151991 (std: sys: pal: uefi: os: Implement split_paths)
- rust-lang/rust#152794 (Fix ICE in `try_to_raw_bytes` when array elements have mismatched)
- rust-lang/rust#153052 (std random.rs: update link to RTEMS docs)
- rust-lang/rust#153054 (docs: note env var influence on `temp_dir` and `env_clear` on Windows)
- rust-lang/rust#153061 (cleanup `tests/ui/box`, part 2)
- rust-lang/rust#153197 (style: Update doctests for `TryFrom<integer> for bool` and `From<bool> for float`)
- rust-lang/rust#153210 (Fix ICE on empty file with -Zquery-dep-graph)
- rust-lang/rust#153228 (Remove `TranslationError`)
* add --ci flag in tidy
This commit introduces --ci flag in tidy because currently bootstrap can't pass its ci env information to tidy. It also modifies how CiInfo initialize its ci_env variable. tidy codes which uses CiEnv::is_ci for checking ci are now using ci_env in CiInfo.
* address review
- Fix comment
- Use Option for ci flag in order to have true/false explicitly or unspecified (implicit false)
* integrate CiInfo into TidyCtx
* remove CiInfo
* CiEnv::current() should be called when ci flag is not added
* extract base_commit() to a separate function
* use &TidyCtx instead of clone
refactor(mgca): Change `DefKind::Const` and `DefKind::AssocConst` to have a `is_type_const` flag
Addresses rust-lang/rust#152940
- Changed `DefKind::Const` and `DefKind::AssocConst` to have a `is_type_const` flag.
- changed `is_type_const` query to check for this flag
- removed `is_rhs_type_const` query
r? @BoxyUwU
* refactor: add `is_type_const` flag to `DefKind::Const` and `AssocConst`
* refactor(cleanup) remove the `rhs_is_type_const` query
* style: fix formatting
* refactor: refactor stuff in librustdoc for new Const and AssocConst
* refactor: refactor clippy for the changes
* chore: formatting
* fix: fix test
* fix: fix suggestions
* Update context.rs
Co-authored-by: Boxy <rust@boxyuwu.dev>
* changed AssocKind::Const to store data about being a type const
Correctly handle `#[doc(alias = "...")]` attribute on inlined reexports
Fixesrust-lang/rust#152939.
During the doc attributing migration to the new API, this information got lost. At least now we have a test for it. :)
r? @lolbinarycat
add field representing types
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/152730)*
> [!NOTE]
> This is a rewrite of #146307 by using a lang item instead of a custom `TyKind`. We still need a `hir::TyKind::FieldOf` variant, because resolving the field name cannot be done before HIR construction. The advantage of doing it this way is that we don't need to make any changes to types after HIR (including symbol mangling). At the very beginning of this feature implementation, I tried to do it using a lang item, but then quickly abandoned the approach, because at that time I was still intending to support nested fields.
Here is a [range-diff](https://triagebot.infra.rust-lang.org/gh-range-diff/rust-lang/rust/605f49b27444a738ea4032cb77e3bdc4eb811bab..d15f5052095b3549111854a2555dd7026b0a729e/605f49b27444a738ea4032cb77e3bdc4eb811bab..f5f42d1e03495dbaa23671c46b15fccddeb3492f) between the two PRs
---
# Add Field Representing Types (FRTs)
This PR implements the first step of the field projection lang experiment (Tracking Issue: rust-lang/rust#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)+ $(,)?);
```
Along with a perma-unstable type that the compiler uses in the expansion of the macro:
```rust
#[unstable(feature = "field_representing_type_raw", issue = "none")]
pub struct FieldRepresentingType<T: ?Sized, const VARIANT: u32, const FIELD: u32> {
_phantom: PhantomData<T>,
}
```
## 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).
## TODOs
There are some `FIXME(FRTs)` scattered around the code:
- 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`
r? @oli-obk
Remove mutation from macro path URL construction
Resolves the `FIXME` in `generate_macro_def_id_path`.
The old code mutated `path` to build the URL — popping the macro name, pushing an interned filename, then restoring the original at the end. None of that was necessary. A slice pattern gives us `module_path` and `last` without touching the original, and `push_fmt(format_args!(...))` writes the filename directly into the URL builder, same as `make_href` already does.
Also tightened the error guards: the original `path.len() < 2` is now two distinct checks with messages that describe the actual failure (empty path vs. single-element path missing the crate prefix).
r? @GuillaumeGomez
Update books
## rust-lang/reference
4 commits in 442cbef9105662887d5eae2882ca551f3726bf28..50a1075e879be75aeec436252c84eef0fad489f4
2026-02-25 00:55:28 UTC to 2026-02-24 17:09:35 UTC
- Fix formatting of markdown grammar with cut (rust-lang/reference#2183)
- Add support for named repeat ranges (rust-lang/reference#2181)
- paths: align singular/plural in `paths.canonical.intro` (rust-lang/reference#2142)
- `cfg_select!` macro (rust-lang/reference#2103)
Refactor url_parts to return is_absolute instead of out param
Follow-up from rust-lang/rust#152977.
Changes `url_parts` to return `Result<(UrlPartsBuilder, bool), HrefError>` instead of taking `is_absolute: &mut bool` as an out parameter. Also clarifies variable name in `generate_item_def_id_path` where the final URL string was called `url_parts`.
No behavior change, pure refactor.
r? @notriddle
Jonathan Brouwer