Conversation
|
Not yet ready to consider merge, but seeking initial review on the approach. |
This comment has been minimized.
This comment has been minimized.
f9c13c1 to
58daeb5
Compare
|
☔ The latest upstream changes (presumably #146636) made this pull request unmergeable. Please resolve the merge conflicts. |
|
In the course of testing this, I discovered an issue that may require some additional design to solve: matchers like 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 (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.
ca75fe7 to
b3e8379
Compare
This comment has been minimized.
This comment has been minimized.
|
☔ The latest upstream changes (presumably #147151) made this pull request unmergeable. Please resolve the merge conflicts. |
Initial support for macro fragment fields (marked as incomplete).
This adds the
:fnand:adtfragment types, and adds anamefieldsupported 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 newParseNtResult(e.g.ParseNtResult::Ident).