Make `#[fundamental]` only apply to the first argument of `Box` by nia-e · Pull Request #160162 · rust-lang/rust

nia-e · 2026-07-29T15:48:33Z

Per a discussion with lang, it was decided that we want Box<T, A> to only be fundamental in T. ~~Given that Box is the only fundamental type with two generic params, simply make it so only the first param is considered for fundamentalness.~~ ~~Tuple is also fundamental, but has its own path in coherence checking and so isn't impacted by this; Box is the only thing that is.~~

Since this is just an internal detail and #[fundamental] is not in a rush to get stabilised, lang's opinion was that t-compiler has free rein on how to implement this so I figured I'd go with the most straightforward implementation for now. The main alternative I see would be supporting param-position #[fundamental] & have the semantics that:

#[fundamental]
struct Foo<T, U>(T, U);

is equivalent to

struct Foo<#[fundamental] T, #[fundamental] U>(T, U);

though given that there's no usecase for this right now, it seemed somewhat unnecessary.

r? compiler

nia-e · 2026-07-29T17:43:41Z

that's a problem ^^ ill check it out, ty.

also realised there's another potential issue here wrt tuples since we definitely want those to be fundamental in all prams - oops. I'll just special case box i think instead.

@rustbot author

nia-e · 2026-07-29T19:20:21Z

seems like the tuple thing was a false flag, this should be okay after all (tuples get their own path in coherence checking). and the error there was bc [foreign-local] was being parsed as a regex :D

@rustbot ready

programmerjake · 2026-07-29T19:41:43Z

AFAICT tuples aren't supposed to be fundamental: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=5a585806691e3be45b6be4e3d540089f
I looked through all mentions of fundamental in this repo's code and didn't see anything about tuples.

mejrs · 2026-07-29T19:51:08Z

Tuples are not listed here. https://doc.rust-lang.org/reference/glossary.html#fundamental-type-constructors

jackh726 · 2026-07-29T23:53:45Z

#[fundamental] is under T-types r? types

JorgeCepeda · 2026-07-30T01:29:24Z

There is a PR (#160181) about making Tuple fundamental.

programmerjake · 2026-07-30T01:33:24Z

There is a PR (#160181) about making Tuple fundamental.

That's the tuple trait, the tuple types are what would cause issues here

jackh726 · 2026-07-30T01:39:29Z

                    ControlFlow::Break(OrphanCheckEarlyExit::LocalTy(ty))
                } else if def.is_fundamental() {
-                    args.visit_with(self)
+                    args.type_at(0).visit_with(self)


This is a pretty suble, easy-to-miss thing. Although it's a much bigger change, I would expect that we would do one of:

Get rid of #[fundamental] entirely and instead just match on the DefId (since all uses are lang items)

Mark args as fundamental and track those somewhere

View changes since the review

would an acceptable intermediary be special-casing Box in particular here & matching on the AdtLangItem?

I'm also willing to go ahead and do a per-arg implementation, but that would be more involved as you say & I'm not sure if it will be much help given that there are no users of that anywhere on the horizon

A per arg impl implies attribute on the generic, like struct Box<#[fundamental] T, A> { .. }, right?

Get rid of #[fundamental] entirely and instead just match on the DefId (since all uses are lang items)

I don't think this is a good idea, it would remove our ability to integration test this stuff.

We've also pointed the rust for linux folks at this (#136979 (comment)) for a potential solution to their orphan rule problems. And while we can of course change this thing however we want, I'd feel bad about removing the ability to unstably use it or even experiment with it, at least without discussing it first.

I'd be okay to match on Box specifically (and/or the couple other known lang items, if we want to limit the fundamental there too), but just fall back to the current behavior for all other uses of #[fundamental]. That seems like the smallest and easiest solution here that is also clear.

(i.e. within the def.is_fundamental() arm, do an additional match on lang items)

latest commit should address this ^^

nia-e · 2026-07-30T01:46:58Z

AFAICT tuples aren't supposed to be fundamental: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=5a585806691e3be45b6be4e3d540089f
I looked through all mentions of fundamental in this repo's code and didn't see anything about tuples.

this is why i shouldn't submit PRs on zero sleep :D

theemathas · 2026-07-30T13:10:23Z

Is it backwards-compatible to later make Box be fundamental on both its type parameters?

nia-e · 2026-07-30T13:53:09Z

Yes, though I strongly doubt that will be the case. The opinions in the lang meeting were unanimously in favour of making fundamentalness only apply to the T param, an opinion with which I entirely concur ^^

jackh726

minor nit, but r=me after squashing commits

View changes since this review

jackh726 · 2026-07-31T14:59:02Z

@@ -0,0 +1,24 @@
+//@ compile-flags:--crate-name=test
+//@ aux-build:coherence_lib.rs
+


This test should likely be named for box, and there should be a comment.

jackh726 · 2026-07-31T15:01:36Z

cc @rust-lang/types

We're reducing the scope of #[fundamental] for Box here. Given that #[fundamental] is unstable with no current path to stabilization, this seems okay to me. (If we thought there was a path to stabilization, something more principled like applying this to args might make more sense.)

nia-e · 2026-07-31T15:31:23Z

@bors squash

* fundamental only on first arg * woo this made error messages nicer * oh the test was misnamed lol * special case only box * rename tests Co-authored-by: Nia Deckers <nia-e@haecceity.cc>

rust-bors · 2026-07-31T15:31:45Z

🔨 5 commits were squashed into 4af1e41.

nia-e · 2026-07-31T16:43:36Z

@bors r=jackh726

rust-bors · 2026-07-31T16:43:38Z

📌 Commit 4af1e41 has been approved by jackh726

It is now in the queue for this repository.

lcnr · 2026-07-31T18:31:46Z

Yes, though I strongly doubt that will be the case. The opinions in the lang meeting were unanimously in favour of making fundamentalness only apply to the T param, an opinion with which I entirely concur ^^

Is this the case? I vaguely remember that adding and removing fundamental was a breaking change. I think with this PR impl<A> Trait<LocalTy> for Box<u32, A> is allowed while if Box is fundamental over A it is not (because now another crate could write impl<T> Trait<T> for Box<u32, MyAllocator>)

nia-e · 2026-07-31T19:06:42Z

We'll need lang signoff to stabilise that field in the first place, so I'll note that point when I ask for FCP on that - I doubt it's something they'd want to go back on, but ty for raising it ^^

jackh726 · 2026-07-31T19:12:15Z

@nia-e can you ensure that question makes its way to the tracking issue for later consideration?

Make `#[fundamental]` only apply to the first argument of `Box` Per a [discussion with lang](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/.60.23.5Bfundamental.5D.60.20and.20.60Box.3CT.2C.20A.3E.60/with/613236766), it was decided that we want `Box<T, A>` to only be fundamental in `T`. ~~Given that `Box` is the only fundamental type with two generic params, simply make it so only the first param is considered for fundamentalness.~~ ~~`Tuple` is also fundamental, but has its own path in coherence checking and so isn't impacted by this; `Box` is the only thing that is.~~ Since this is just an internal detail and `#[fundamental]` is not in a rush to get stabilised, lang's opinion was that t-compiler has free rein on how to implement this so I figured I'd go with the most straightforward implementation for now. The main alternative I see would be supporting param-position `#[fundamental]` & have the semantics that: ```rust #[fundamental] struct Foo<T, U>(T, U); ``` is equivalent to ```rust struct Foo<#[fundamental] T, #[fundamental] U>(T, U); ``` though given that there's no usecase for this right now, it seemed somewhat unnecessary. r? compiler

Rollup of 14 pull requests Successful merges: - #159245 (Emit retags in codegen to support BorrowSanitizer (part 5)) - #159864 (Report "capacity overflow" for oversized Rc<[T]>/Arc<[T]>) - #160079 (make atomic operations const) - #160124 (Structurally prevent zero-count `BackendRepr::SimdVector`s) - #160162 (Make `#[fundamental]` only apply to the first argument of `Box`) - #160210 (Remove an outdated FIXME) - #160282 (Improve diagnostic for patterns in function pointer types) - #157928 (Eagerly fetch typeck results when linting) - #159672 (Improve suggestions when multiples tuples implement the same trait) - #159861 (Add documentation for the `non_exhaustive` attribute) - #159907 (Fix `hidden_glob_reexports` in `rustc_ast`) - #159998 (Align expect messages with guidance) - #160145 (Expand checks for register_tool) - #160307 (Update `minifier` version to `0.4.0`)

Rollup merge of #160162 - nia-e:per-arg-fundamental, r=jackh726 Make `#[fundamental]` only apply to the first argument of `Box` Per a [discussion with lang](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/.60.23.5Bfundamental.5D.60.20and.20.60Box.3CT.2C.20A.3E.60/with/613236766), it was decided that we want `Box<T, A>` to only be fundamental in `T`. ~~Given that `Box` is the only fundamental type with two generic params, simply make it so only the first param is considered for fundamentalness.~~ ~~`Tuple` is also fundamental, but has its own path in coherence checking and so isn't impacted by this; `Box` is the only thing that is.~~ Since this is just an internal detail and `#[fundamental]` is not in a rush to get stabilised, lang's opinion was that t-compiler has free rein on how to implement this so I figured I'd go with the most straightforward implementation for now. The main alternative I see would be supporting param-position `#[fundamental]` & have the semantics that: ```rust #[fundamental] struct Foo<T, U>(T, U); ``` is equivalent to ```rust struct Foo<#[fundamental] T, #[fundamental] U>(T, U); ``` though given that there's no usecase for this right now, it seemed somewhat unnecessary. r? compiler

nia-e added T-lang Relevant to the language team T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue. F-fundamental `#![feature(fundamental)]` labels Jul 29, 2026

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 29, 2026

rustbot assigned folkertdev Jul 29, 2026

rustbot added the WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) label Jul 29, 2026

This comment has been minimized.

Sign in to view

This comment was marked as resolved.

Sign in to view

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 29, 2026

nia-e changed the title ~~Make #[fundamental] only apply to the first argument~~ Make #[fundamental] only apply to the first argument of Box Jul 29, 2026

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 29, 2026

This comment has been minimized.

Sign in to view

rustbot assigned jackh726 and unassigned folkertdev Jul 29, 2026

jackh726 reviewed Jul 30, 2026

View reviewed changes

jackh726 approved these changes Jul 31, 2026

View reviewed changes

jackh726 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 31, 2026

This comment was marked as off-topic.

Sign in to view

This comment has been minimized.

Sign in to view

Make #[fundamental] only apply to the first argument of Box

4af1e41

* fundamental only on first arg * woo this made error messages nicer * oh the test was misnamed lol * special case only box * rename tests Co-authored-by: Nia Deckers <nia-e@haecceity.cc>

rust-bors Bot force-pushed the per-arg-fundamental branch from bab642f to 4af1e41 Compare July 31, 2026 15:31

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 31, 2026

jhpratt mentioned this pull request Aug 1, 2026

Rollup of 16 pull requests #160308

Closed

This was referenced Aug 1, 2026

Rollup of 15 pull requests #160309

Closed

Rollup of 14 pull requests #160310

Merged

rust-bors Bot merged commit bf97201 into rust-lang:main Aug 1, 2026
13 checks passed

rustbot added this to the 1.99.0 milestone Aug 1, 2026

		@@ -0,0 +1,24 @@
		//@ compile-flags:--crate-name=test
		//@ aux-build:coherence_lib.rs

Uh oh!

Uh oh!

Conversation

nia-e commented Jul 29, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

This comment was marked as resolved.

nia-e commented Jul 29, 2026

Uh oh!

nia-e commented Jul 29, 2026

Uh oh!

programmerjake commented Jul 29, 2026

Uh oh!

mejrs commented Jul 29, 2026

Uh oh!

This comment has been minimized.

jackh726 commented Jul 29, 2026

Uh oh!

JorgeCepeda commented Jul 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

programmerjake commented Jul 30, 2026

Uh oh!

jackh726 Jul 30, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nia-e Jul 30, 2026

Choose a reason for hiding this comment

Uh oh!

mejrs Jul 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mejrs Jul 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jackh726 Jul 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nia-e Jul 30, 2026

Choose a reason for hiding this comment

Uh oh!

nia-e commented Jul 30, 2026

Uh oh!

theemathas commented Jul 30, 2026

Uh oh!

nia-e commented Jul 30, 2026

Uh oh!

jackh726 left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jackh726 Jul 31, 2026

Choose a reason for hiding this comment

Uh oh!

jackh726 commented Jul 31, 2026

Uh oh!

This comment was marked as off-topic.

Uh oh!

nia-e commented Jul 31, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Jul 31, 2026

Uh oh!

nia-e commented Jul 31, 2026

Uh oh!

rust-bors Bot commented Jul 31, 2026

Uh oh!

lcnr commented Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nia-e commented Jul 31, 2026

Uh oh!

jackh726 commented Jul 31, 2026

Uh oh!

Uh oh!

nia-e commented Jul 29, 2026 •

edited by rustbot

Loading

JorgeCepeda commented Jul 30, 2026 •

edited

Loading

jackh726 Jul 30, 2026 •

edited by rustbot

Loading

mejrs Jul 30, 2026 •

edited

Loading

mejrs Jul 30, 2026 •

edited

Loading

jackh726 Jul 30, 2026 •

edited

Loading

jackh726 left a comment •

edited by rustbot

Loading

lcnr commented Jul 31, 2026 •

edited

Loading