syntax: unify all MacResult's into a single trait. #13527
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
src/libsyntax/ext/base.rs
Outdated
There was a problem hiding this comment.
The : shouldn't be necessary anymore now that there are no default bounds.
There was a problem hiding this comment.
Oh, right. I was just copying of the surrounding code.
|
Any reason to keep the explicit empty bounds? Otherwise, r=me. |
There's now one unified way to return things from a macro, instead of being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr` variants of the `MacResult` enum. This does simplify the logic handling the expansions, but the biggest value of this is it makes macros in (for example) type position easier to implement, as there's this single thing to modify. By my measurements (using `-Z time-passes` on libstd and librustc etc.), this appears to have little-to-no impact on expansion speed. There are presumably larger costs than the small number of extra allocations and virtual calls this adds (notably, all `macro_rules!`-defined macros have not changed in behaviour, since they had to use the `AnyMacro` trait anyway).
bors
added a commit
that referenced
this pull request
Apr 16, 2014
There's now one unified way to return things from a macro, instead of being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr` variants of the `MacResult` enum. This does simplify the logic handling the expansions, but the biggest value of this is it makes macros in (for example) type position easier to implement, as there's this single thing to modify. By my measurements (using `-Z time-passes` on libstd and librustc etc.), this appears to have little-to-no impact on expansion speed. There are presumably larger costs than the small number of extra allocations and virtual calls this adds (notably, all `macro_rules!`-defined macros have not changed in behaviour, since they had to use the `AnyMacro` trait anyway). --- Summary of changes for dynamic syntax extension maintainers: - `MacResult` is now a trait, and is returned as `~MacResult` - `MRExpr` & `MRItem` are now `MacExpr::new` and `MacItem:new` respectively (which return `~MacResult`s) - `MacResult::dummy_...` is `DummyResult::any` or `DummyResult::expr`
notriddle
pushed a commit
to notriddle/rust
that referenced
this pull request
Nov 10, 2022
…o-guarded-return-assist, r=jonas-schievink Use let-else statements in `Convert to guarded return` assist Follow up for rust-lang/rust-analyzer#13516, addresses remaining part of rust-lang/rust-analyzer#13254 (comment)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There's now one unified way to return things from a macro, instead of
being able to choose the
AnyMacrotrait or theMRItem/MRExprvariants of the
MacResultenum. This does simplify the logic handlingthe expansions, but the biggest value of this is it makes macros in (for
example) type position easier to implement, as there's this single thing
to modify.
By my measurements (using
-Z time-passeson libstd and librustc etc.),this appears to have little-to-no impact on expansion speed. There are
presumably larger costs than the small number of extra allocations and
virtual calls this adds (notably, all
macro_rules!-defined macros havenot changed in behaviour, since they had to use the
AnyMacrotraitanyway).
Summary of changes for dynamic syntax extension maintainers:
MacResultis now a trait, and is returned as~MacResultMRExpr&MRItemare nowMacExpr::newandMacItem:newrespectively (which return~MacResults)MacResult::dummy_...isDummyResult::anyorDummyResult::expr