Skip to content

Initial implementation of named Fn trait parameters - #158517

Merged
rust-bors[bot] merged 4 commits into
rust-lang:mainfrom
JonathanBrouwer:named_fn_trait_parameters
Aug 9, 2026
Merged

Initial implementation of named Fn trait parameters#158517
rust-bors[bot] merged 4 commits into
rust-lang:mainfrom
JonathanBrouwer:named_fn_trait_parameters

Conversation

@JonathanBrouwer

@JonathanBrouwer JonathanBrouwer commented Jun 28, 2026

Copy link
Copy Markdown
Contributor

This is an initial implementation of the feature named_fn_trait_parameters.
This implementation is incomplete (and also marked as such) , and needs significant further changes to be implemented correctly. To keep the size of this PR managable, I propose we do this in follow-up PRs.
I've added a test that shows the current behaviour, with FIXME comments where the test output is currently incorrect.

Tracking issue: #158499
Accepted RFC: rust-lang/rfcs#3955

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 28, 2026
@rust-bors

This comment has been minimized.

@JonathanBrouwer
JonathanBrouwer force-pushed the named_fn_trait_parameters branch from 4d2b638 to 858e064 Compare July 31, 2026 11:28
@JonathanBrouwer JonathanBrouwer changed the title Implement named Fn trait parameters Initial implementation of named Fn trait parameters Aug 2, 2026
@JonathanBrouwer
JonathanBrouwer marked this pull request as ready for review August 2, 2026 10:36
@rustbot

rustbot commented Aug 2, 2026

Copy link
Copy Markdown
Collaborator

The parser was modified, potentially altering the grammar of (stable) Rust
which would be a breaking change.

cc @fmease

@rustbot 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 Aug 2, 2026
@rustbot

rustbot commented Aug 2, 2026

Copy link
Copy Markdown
Collaborator

r? @JohnTitor

rustbot has assigned @JohnTitor.
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

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: compiler
  • compiler expanded to 75 candidates
  • Random selection from 17 candidates

@JohnTitor JohnTitor left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

@rust-bors

rust-bors Bot commented Aug 8, 2026

Copy link
Copy Markdown
Contributor

📌 Commit 6c901ce has been approved by JohnTitor

It is now in the queue for this repository.

@rust-bors 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-review Status: Awaiting review from the assignee but also interested parties. labels Aug 8, 2026
jhpratt added a commit to jhpratt/rust that referenced this pull request Aug 9, 2026
…ameters, r=JohnTitor

Initial implementation of named `Fn` trait parameters

This is an initial implementation of the feature `named_fn_trait_parameters`.
This implementation is incomplete (and also marked as such) , and needs significant further changes to be implemented correctly. To keep the size of this PR managable, I propose we do this in follow-up PRs.
I've added a test that shows the current behaviour, with `FIXME` comments where the test output is currently incorrect.

Tracking issue: rust-lang#158499
Accepted RFC: rust-lang/rfcs#3955
rust-bors Bot pushed a commit that referenced this pull request Aug 9, 2026
Rollup of 6 pull requests

Successful merges:

 - #160529 (Upgrade and deduplicate dependencies)
 - #158517 (Initial implementation of named `Fn` trait parameters)
 - #158587 (check if len of array const arg matches the expected len of the type when lowering to valtree)
 - #160748 (Add regression test for cross-crate assoc const private field leak in rustdoc)
 - #160708 (remove old update mechanism)
 - #160768 (Fix autodiff_illegal.rs test)
rust-bors Bot pushed a commit that referenced this pull request Aug 9, 2026
Rollup of 5 pull requests

Successful merges:

 - #158517 (Initial implementation of named `Fn` trait parameters)
 - #158587 (check if len of array const arg matches the expected len of the type when lowering to valtree)
 - #160748 (Add regression test for cross-crate assoc const private field leak in rustdoc)
 - #160708 (remove old update mechanism)
 - #160768 (Fix autodiff_illegal.rs test)
@rust-bors
rust-bors Bot merged commit 3820cc9 into rust-lang:main Aug 9, 2026
13 checks passed
rust-timer added a commit that referenced this pull request Aug 9, 2026
Rollup merge of #158517 - JonathanBrouwer:named_fn_trait_parameters, r=JohnTitor

Initial implementation of named `Fn` trait parameters

This is an initial implementation of the feature `named_fn_trait_parameters`.
This implementation is incomplete (and also marked as such) , and needs significant further changes to be implemented correctly. To keep the size of this PR managable, I propose we do this in follow-up PRs.
I've added a test that shows the current behaviour, with `FIXME` comments where the test output is currently incorrect.

Tracking issue: #158499
Accepted RFC: rust-lang/rfcs#3955
@rustbot rustbot added this to the 1.99.0 milestone Aug 9, 2026
@fmease

fmease commented Aug 9, 2026

Copy link
Copy Markdown
Member

Fun bit of trivia: #140671 (comment)

@fmease

fmease commented Aug 9, 2026

Copy link
Copy Markdown
Member

Not the right place to discuss this really but IMHO, self receivers shouldn't be syntactically forbidden in this position (only semantically) since that diverges from every other place that can contain "function parameters" IINM.

We intentionally allow self receivers in e.g., function pointer types (CC #68764, rust-lang/reference#2240 (comment)) and free function items. As it stands, it means we reject X(self), X(&self), X(&mut self) but allow X(&&self), X(&&mut self) for example (the latter are rightfully legal as they're interpreted as X(_: &&self) & X(_: &&mut self) essentially1).

Similarly, for C-variadics. They should be syntactically allowed, too, IMO.

...Actually, I think I'm going to open an issue. Unifying this would once again simplify the grammar; we shouldn't fight the fact that self-receivers & C-variadics are (meant to be) syntactically valid fn params always.

Footnotes

  1. They're however always semantically ill-formed as self is a module not a type.

@ytmimi

ytmimi commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

@JonathanBrouwer @JohnTitor These changes to the parser caused a bug on nightly rustfmt rust-lang/rustfmt#7021. Could you look into it?

@JonathanBrouwer

Copy link
Copy Markdown
Contributor Author

I'll take a look sometime in the next few days :)

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

Labels

S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants