Skip to content

Conversation

joshtriplett
Copy link
Member

Initial support for macro fragment fields (marked as incomplete).

This adds the :fn and :adt fragment types, and adds a name field
supported by those types. This provides an initial demonstration and minimal
initial infrastructure for macro fragment fields.

A macro fragment field operation takes a ParseNtResult (e.g.
ParseNtResult::Fn) and returns a new ParseNtResult (e.g.
ParseNtResult::Ident).

@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 Sep 25, 2025
@joshtriplett
Copy link
Member Author

Not yet ready to consider merge, but seeking initial review on the approach.

r? @petrochenkov

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Collaborator

bors commented Sep 27, 2025

☔ The latest upstream changes (presumably #146636) made this pull request unmergeable. Please resolve the merge conflicts.

@joshtriplett
Copy link
Member Author

joshtriplett commented Sep 29, 2025

In the course of testing this, I discovered an issue that may require some additional design to solve: matchers like :fn and :adt (and hypothetical future matchers like :struct and :enum) work fine in isolation, but they can't be used as alternatives to each other in a macro, since each one starts out trying to parse an item. A macro that tries to have a ($f:fn) rule and a ($s:adt) rule will not work as expected, because it'll try whichever rule comes first and error on an unexpected item type.

By contrast, proc macros get passed the entire set of tokens, so they can do more sophisticated parsing.

That will require some additional design and thought to come up with a solution for making macro_rules! comparably capable.

(This doesn't prevent presenting this as an unstable-and-incomplete feature, but it's absolutely a blocker for any kind of stabilization.)

This only supports a `name` field of `fn` and `adt` fragments, for now,
but it adds the infrastructure for adding more fields.
…oken collection

Add support for getting a `.vis` field from a `fn` type. This requires
adding support for collecting tokens when parsing the visibility of a
function. Add a new `ForceCollect::Recursive`, and plumb that through
the item parser enough to support visibility. Only use that when a macro
uses macro metavariable expressions, as we don't need the tokens
otherwise.

`ForceCollect::Recursive` will need further handling later, to capture
the tokens of any other fields needed, but that can be added alongside
any fields it supports.
@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Collaborator

bors commented Sep 29, 2025

☔ The latest upstream changes (presumably #147151) made this pull request unmergeable. Please resolve the merge conflicts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants