Skip to content

Extract TraitImplHeader in AST/HIR #144386

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

camsteffen
Copy link
Contributor

@camsteffen camsteffen commented Jul 24, 2025

Several fields of Impl are only applicable when it's a trait impl. This moves those fields into a new struct that is only present for trait impls.

@rustbot
Copy link
Collaborator

rustbot commented Jul 24, 2025

r? @SparrowLii

rustbot has assigned @SparrowLii.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-clippy Relevant to the Clippy team. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Jul 24, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jul 24, 2025

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

HIR ty lowering was modified

cc @fmease

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann

@rust-log-analyzer

This comment has been minimized.

@camsteffen
Copy link
Contributor Author

HIR ty lowering was modified

I don't think that's true fwiw.

@rust-log-analyzer

This comment has been minimized.

@xizheyin
Copy link
Contributor

HIR ty lowering was modified

This means this PR change the code in compiler/rustc_hir_analysis/src/hir_ty_lowering/, e.g. https://github.com/rust-lang/rust/pull/144386/files#diff-ce4273e1e949bf3052de7a08466c4dad785890b24091122954541b615b0ba199

@camsteffen
Copy link
Contributor Author

@rustbot author

@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 24, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jul 24, 2025

Reminder, once the PR becomes ready for a review, use @rustbot ready.

@rustbot rustbot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jul 24, 2025
@rust-log-analyzer

This comment has been minimized.

@fmease
Copy link
Member

fmease commented Jul 24, 2025

I'll perf this due to the added indirection for impl "modifiers" + extra alloc + size changes.

@bors try @rust-timer queue

@rust-timer

This comment has been minimized.

@rust-bors
Copy link

rust-bors bot commented Jul 24, 2025

⌛ Trying commit c0c102d with merge 513dd2b

To cancel the try build, run the command @bors try cancel.

rust-bors bot added a commit that referenced this pull request Jul 24, 2025
@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jul 24, 2025
@rust-log-analyzer

This comment has been minimized.

Copy link
Member

@fmease fmease left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately this PR can't proceed without T-lang involvement and crater. This restricts Rust's stable grammar which is a breaking change.

Moreover, speaking from my experience it's quite unlikely that T-lang will approve narrowing the grammar since the general tendency has been to relax the grammar.

Comment on lines 677 to 699
let self_ty = ty_first;
let error = |annotation_span, annotation, only_trait| errors::InherentImplCannot {
span: self_ty.span,
annotation_span,
annotation,
self_ty: self_ty.span,
only_trait,
};

if let Safety::Unsafe(span) = safety {
self.dcx().emit_err(errors::InherentImplCannotUnsafe {
span: self_ty.span,
annotation_span: span,
annotation: "unsafe",
self_ty: self_ty.span,
});
}
if let ImplPolarity::Negative(span) = polarity {
self.dcx().emit_err(error(span, "negative", false));
}
if let Defaultness::Default(def_span) = defaultness {
self.dcx().emit_err(error(def_span, "`default`", true));
}
if let Const::Yes(span) = constness {
self.dcx().emit_err(error(span, "`const`", true));
}
Copy link
Member

@fmease fmease Jul 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moving checks from AST validation (or later stages in general) into the parser is a breaking change! This will regress the following code:

#![feature(const_trait_impl)] // only necessary for the 2nd case

#[cfg(false)]
unsafe impl Local {}
#[cfg(false)]
impl const Local {}
#[cfg(false)]
impl !Local {}
#[cfg(false)]
default impl Local {}

struct Local;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh! Shucks. Well obviously I'll wait for T-lang but I feel like this is defensible.

If not, perhaps we could do the change in the HIR only.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As an example, this is accepted today https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=888b72972d52d0597edbf7e7f2bc7b2e

#[cfg(false)]
trait Foo {
    pub fn bar();
}

even though pub "isn't" accepted there.

I think really what you're finding here is that we should have had the type first (before the optional trait), because that would have been much nicer to deal with. Or it should have been something like impl<T> trait Clone for Foo<T> so there's a warning-of-front to make this LL(1).

I don't know what the rest of lang would say about this, whether we might take it under a "it's a bug that this was ever accepted" or say the parser should just support this under "well we should just item accept modifiers in the parser, even if they're rejected later as not being applicable".

Copy link
Member

@fmease fmease Jul 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah Scott, glad to have you here! I have a try-build ready, I could queue a crater run if you think that there's a non-zero chance of T-lang accepting this grammar change.

trait Foo { pub fn bar(); }

Also quite notable and quite related: Syntactically we permit top-level fns without bodies. This and Scott's example is of course thanks to / an instance of Centril's syntactic unification of "everything fn" and other grammar relaxations I was alluding to earlier. See e.g., RUST-70261, RUST-68788, RUST-69366, RUST-69361, RUST-69194, RUST-69023, RUST-68764, RUST-68728.

Side note for [@]camsteffen (unless you already know this), the #[cfg(false)] is only a representative of / a stand-in for macros in general, meaning this detail can be observed by decl & proc macros, not just #[cfg]. Pre-existing user-written macros can break due to this change (users may exploit this for their DSLs).

However, it's not as clear-cut. For example, T-lang recently restricted the stable grammar here: RUST-127054.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about buffer_lint? It's not a lint but it seems like that's basically what we want, if we want to avoid the breakage?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've now issued a crater run so we can get some data. So we can check the actual fallout. Let's wait for that.

Regarding buffering. I'm on my phone, so can't check. I only know early lint buffering for phases where we haven't resolved names yet. I'm not sure if you can buffer lints from within the parser (like if there's a buffer there already), I don't remember there being one but I might be mistaken.

@fmease
Copy link
Member

fmease commented Jul 24, 2025

@bors try cancel

@fmease fmease added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 29, 2025
@fmease
Copy link
Member

fmease commented Jul 29, 2025

Hello T-lang 👋,

this PR renders "trait impl modifiers" in inherent impls ungrammatical / syntactically invalid. Presently they're merely semantically malformed. Stable code like the following will now be rejected:

#[cfg(false)] unsafe impl Type {}
#[cfg(false)] impl !Type {}
#[cfg(false)] default impl Type {}

The #[cfg(false)] is just a stand-in for arbitrary decl macros and bang/attribute proc macros. It's conceivable that users might want to use this for their DSLs but realistically speaking it's relatively unlikely. We've cratered this and found no regressions (via).

The motivation for this change is the simplification of the compiler alongside small perf improvements likely due to the better data representation/layout this change enables (via).

@fmease fmease added I-lang-nominated Nominated for discussion during a lang team meeting. I-lang-easy-decision Issue: The decision needed by the team is conjectured to be easy; this does not imply nomination labels Jul 29, 2025
@traviscross traviscross added the P-lang-drag-1 Lang team prioritization drag level 1. https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang label Jul 29, 2025
@traviscross
Copy link
Contributor

traviscross commented Jul 30, 2025

Interestingly, if we decide to accept this PR, the Reference is already correct (here) (it does mean to specify what's accepted pre-expansion).

Based on that and on my general inclination to match parsing to our semantics where reasonable, I proposed to do this.

@rfcbot fcp merge

That said, though I appreciate the optimism, this is not the kind of thing that's an easy decision for us.

@rustbot labels -I-lang-easy-decision

@rfcbot
Copy link
Collaborator

rfcbot commented Jul 30, 2025

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Jul 30, 2025
@rustbot rustbot removed the I-lang-easy-decision Issue: The decision needed by the team is conjectured to be easy; this does not imply nomination label Jul 30, 2025
@rfcbot rfcbot added the disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. label Jul 30, 2025
@tmandry
Copy link
Member

tmandry commented Jul 30, 2025

@rfcbot reviewed

@rfcbot rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Jul 30, 2025
@rfcbot
Copy link
Collaborator

rfcbot commented Jul 30, 2025

🔔 This is now entering its final comment period, as per the review above. 🔔

@rustbot rustbot added the T-clippy Relevant to the Clippy team. label Jul 30, 2025
@camsteffen camsteffen changed the title Extract ImplOfTrait in AST/HIR Extract TraitImplHeader in AST/HIR Jul 30, 2025
@fmease fmease added S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. and removed S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Jul 31, 2025
@traviscross traviscross added I-lang-radar Items that are on lang's radar and will need eventual work or consideration. and removed I-lang-nominated Nominated for discussion during a lang team meeting. P-lang-drag-1 Lang team prioritization drag level 1. https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang labels Jul 31, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. I-lang-radar Items that are on lang's radar and will need eventual work or consideration. needs-fcp This change is insta-stable, or significant enough to need a team FCP to proceed. S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. T-clippy Relevant to the Clippy team. T-lang Relevant to the language team
Projects
None yet
Development

Successfully merging this pull request may close these issues.