Skip to content

subtree-push nightly-2026-06-10#6939

Open
ytmimi wants to merge 31 commits into
rust-lang:mainfrom
ytmimi:subtree-push-nightly-2026-06-10
Open

subtree-push nightly-2026-06-10#6939
ytmimi wants to merge 31 commits into
rust-lang:mainfrom
ytmimi:subtree-push-nightly-2026-06-10

Conversation

@ytmimi

@ytmimi ytmimi commented Jun 11, 2026

Copy link
Copy Markdown
Contributor

Bumping the toolchain version as part of a git subtree push

current toolchain (nightly-2026-02-19):

  • 1.95.0-nightly (c04308580 2026-02-18)

latest toolchain (nightly-2026-06-10):

  • 1.98.0-nightly (beae78130 2026-06-09)

Note

This PR also reverts #6839 because it was leading to test failures in CI. It's unclear to me right now why thats the case, but we need to reopen #5364 once this is merged.

JonathanBrouwer and others added 30 commits February 11, 2026 17:52
…zelmann

Remove the translation `-Z` options and the `Translator` type.

This PR implements MCP rust-lang/compiler-team#967

It is split up into individually reviewable commits, each commit passes tests:

* rust-lang/rust@6782119 Removes the translation compiler options from the session
* rust-lang/rust@8f300d0 Removes the now empty `Translator` type
* rust-lang/rust@ab715c5 Renames `translate_message` to `format_diag_message`, as the function no longer does any translation
* rust-lang/rust@8bcbc3f Removes a section describing the removed compiler options from the rustc dev guide
…oli-obk

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
This adds a variant `NoneWithError` to AST and HIR representations of
the “rest” or “tail”, which is currently always treated identically to
the `None` variant.
Don’t report missing fields in struct exprs with syntax errors.

@Noratrieb [told me](https://internals.rust-lang.org/t/custom-cargo-command-to-show-only-errors-avoid-setting-rustflags-every-time/24032/7?u=kpreid) that “it is a bug if this recovery causes follow-up errors that would not be there if the user fixed the first error.” So, here’s a contribution to hide a follow-up error that annoyed me recently.

Specifically, if the user writes a struct literal with a syntax error, such as

```rust
StructName { foo: 1 bar: 2 }
```

the compiler will no longer report that the field `bar` is missing in addition to the syntax error.

This is my first time attempting any change to the parser or AST; please let me know if there is a better way to do what I’ve done here. ~~The part I’m least happy with is the blast radius of adding another field to `hir::ExprKind::Struct`, but this seems to be in line with the style of the rest of the code. (If this were my own code, I would consider changing `hir::ExprKind::Struct` to a nested struct, the same way it is in `ast::ExprKind`.)~~ The additional information is now stored as an additional variant of `ast::StructRest` / `hir::StructTailExpr`.

**Note to reviewers:** I recommend reviewing each commit separately, and in the case of the first one with indentation changes ignored.
…gau,jhpratt

Parse `impl` restrictions

This PR implements the parsing logic for `impl` restrictions (e.g., `pub impl(crate) trait Foo {}`) as proposed in [RFC 3323](https://rust-lang.github.io/rfcs/3323-restrictions.html).
As the first step of the RFC implementation, this PR focuses strictly on the parsing phase. The new syntax is guarded by the `#![feature(impl_restriction)]` feature gate.
This implementation basically follows the pattern used in rust-lang/rust#141754.

r? @jhpratt
It's defined in `rustc_span::source_map` which doesn't make any sense
because it has nothing to do with source maps. This commit moves it to
the crate root, a more sensible spot for something this basic.
Add macro matcher for `guard` fragment specifier

Tracking issue #153104

This PR implements a new `guard` macro matcher to match `if-let` guards (specifically [`MatchArmGuard`](https://github.com/rust-lang/reference/blob/50a1075e879be75aeec436252c84eef0fad489f4/src/expressions/match-expr.md#match-guards)). In the upcoming PR, we can use this new matcher in the `matches!` and `assert_matches!` macros to support their use with `if-let` guards. (see #152313)

The original `Expr` used to represent a guard has been wrapped in a new `Guard` type, allowing us to carry the span information of the leading `if` keyword. However, it might be even better to include the `if` keyword in the `Guard` type as well? I've left a FIXME comment in the code.
Fixes a rustfmt bug for `#![feature(fn_delegation)]`
replace TODO with FIXME
…au,jhpratt

Parse `mut` restrictions

This PR is part of the progress implementing `mut` restrictions proposed in [RFC 3323](https://rust-lang.github.io/rfcs/3323-restrictions.html), and linked to a [GSoC proposal](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Implementing.20impl.20and.20mut.20restrictions/with/592352432).
This PR focuses solely on the parsing of `mut` restrictions.
The keyword order is `pub(...) mut(...) unsafe field`.
The new syntax is guared by `#[feature(mut_restriction)]` feature gate.
Tracking Issue: rust-lang/rust#105077

r? @Urgau
cc @jhpratt
Replace rustfmt code of conduct with link

In rust-lang/rust#65141 we replaced the CoC file and linked the "authoritative source" on the website. I noticed that the rustfmt directory still has the CoC original file.

I *think* for consistency it makes sense to have all of them linked but I'd like to hear from @calebcartwright first :-)

r? @Mark-Simulacrum
This reverts commit 5e73127.

This commit was causing local tests and CI to fail when trying to perform the
subtree-push so I'm reverting this for now. It's not clear to me why this became
an issue when trying to do the subtree-push, but the easiest solution right now
is to simply revert the change.
@rustbot rustbot added the S-waiting-on-review Status: awaiting review from the assignee but also interested parties. label Jun 11, 2026
@ytmimi

ytmimi commented Jun 11, 2026

Copy link
Copy Markdown
Contributor Author

Diff-Check --edition=2021 --style-edition=2021 Failed ❌: All diffs tie back to r-l/r changes

Diff Explanation

Change due to 61b29c1 (rust-lang/rust#156815)

2026-06-11T12:54:22.294630Z ERROR check_diff: Diff found in 'rust' when formatting rust/library/coretests/tests/hint.rs
--- original
+++ modified
@@ -5,7 +5,7 @@
     use core::cell::Cell;
     struct X<'a>(&'a Cell<bool>);
-    impl const Drop for X<'_> {
+    const impl Drop for X<'_> {
         fn drop(&mut self) {
             self.0.set(true);
         }

Change due to ebebf24 (rust-lang/rust#153445)

2026-06-11T12:54:22.295093Z ERROR check_diff: Diff found in 'miri' when formatting miri/src/shims/time.rs
--- original
+++ modified
@@ -472,19 +472,17 @@
         let nsec_field = this.project_field_named(tp, "tv_nsec")?;
         let nsec = this.read_scalar(&nsec_field)?.to_int(nsec_field.layout.size)?;
-        interp_ok(
-            try {
-                // tv_sec must be non-negative.
-                let seconds: u64 = sec.try_into().ok()?;
-                // tv_nsec must be non-negative.
-                let nanoseconds: u32 = nsec.try_into().ok()?;
-                if nanoseconds >= 1_000_000_000 {
-                    // tv_nsec must not be greater than 999,999,999.
-                    None?
-                }
-                Duration::new(seconds, nanoseconds)
-            },
-        )
+        interp_ok(try {
+            // tv_sec must be non-negative.
+            let seconds: u64 = sec.try_into().ok()?;
+            // tv_nsec must be non-negative.
+            let nanoseconds: u32 = nsec.try_into().ok()?;
+            if nanoseconds >= 1_000_000_000 {
+                // tv_nsec must not be greater than 999,999,999.
+                None?
+            }
+            Duration::new(seconds, nanoseconds)
+        })
     }

@ytmimi

ytmimi commented Jun 11, 2026

Copy link
Copy Markdown
Contributor Author

Diff-Check --edition=2021 --style-edition=2024 Failed ❌: All diffs tie back to r-l/r changes. Same diff as above

@ytmimi

ytmimi commented Jun 11, 2026

Copy link
Copy Markdown
Contributor Author

Diff-Check --edition=2024 --style-edition=2021 Failed ❌: All diffs tie back to r-l/r changes. Same diff as above

@ytmimi

ytmimi commented Jun 11, 2026

Copy link
Copy Markdown
Contributor Author

Diff-Check --edition=2024 --style-edition=2024 Failed ❌: All diffs tie back to r-l/r changes. Same diff as above

@ytmimi

ytmimi commented Jun 11, 2026

Copy link
Copy Markdown
Contributor Author

Although the diff check failed, it was due to merging r-l/r changes back into rustfmt. All of these changes have been available on nightly for a while and only impact unstable features #![feature(try_blocks)] #![feature(try_blocks_heterogeneous)], and #![feature(const_trait_impl)]. I'm Pretty confident we can merge these changes without introducing breaking formatting changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: awaiting review from the assignee but also interested parties.

Projects

None yet

Development

Successfully merging this pull request may close these issues.