-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Macro] Omnibus pull request with macro improvements #62768
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
Merged
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
@swift-ci please build toolchain |
@swift-ci please smoke test |
3 similar comments
@swift-ci please smoke test |
@swift-ci please smoke test |
@swift-ci please smoke test |
@swift-ci please test |
@swift-ci please built toolchain |
@swift-ci please build toolchain |
@swift-ci please smoke test |
@swift-ci please build toolchain |
Each macro expansion buffer was getting parsed twice: once by ParseSourceFileRequest (which is used by unqualified name lookup) and once to parse the expression when type-checking the expanded macro. This meant that the same code had two ASTs. Hilarity ensures. Stop directly invoking the parser on macro-expanded code. Instead, go through ParseSourceFileRequest *as is always the right way*, and dig out the expression we want.
This improves diagnostics for missing/extra/incorrectly-labeled arguments.
…callee kind Most of the diagnostics for extra/missing/mislabeled arguments refer to argument to a "call". Some (but not call) would substitute in "subscript". None would refer to an argument to a macro expansion properly. Rework all of these to refer to the argument in a call, subscript, or macro expansion as appropriate. Fix up lots of tests that now say "subscript" instead, and add tests for macro expansions.
Macros can use variadic generics, and don't need runtime support for variadic generics to do so. Add an example "print".
Unlike functions, you can't curry macros; diagnose when one omits the arguments in a macro expansion of a macro that has a parameter list.
Always parse macro expansions, regardless of language mode, and eliminate the fallback path for very, very, very old object literals like `#Color`. Instead, check for the feature flag for macro declaration and at macro expansion time, since this is a semantic restriction. While here, refactor things so the vast majority of the macro-handling logic still applies even if the Swift Swift parser is disabled. Only attempts to expand the macro will fail. This allows us to enable the macro-diagnostics test everywhere.
Align the grammar of macro declarations with SE-0382, so that macro definitions are parsed as an expression. External macro definitions are referenced via a referenced to the macro `#externalMacro`. Define that macro in the standard library, and recognize uses of it as the definition of other macros to use externally-defined macros. For example, this means that the "stringify" macro used in a lot of examples is now defined as something like this: @expression macro stringify<T>(_ value: T) -> (T, String) = #externalMacro(module: "MyMacros", type: "StringifyMacro") We still parse the old "A.B" syntax for two reasons. First, it's helpful to anyone who has existing code using the prior syntax, so they get a warning + Fix-It to rewrite to the new syntax. Second, we use it to define builtin macros like `externalMacro` itself, which looks like this: @expression public macro externalMacro<T>(module: String, type: String) -> T = Builtin.ExternalMacro This uses the same virtual `Builtin` module as other library builtins, and we can expand it to handle other builtin macro implementations (such as #line) over time.
…riminators. Thanks to Alex Hoppen for providing this test!
271921f
to
5936b7b
Compare
@swift-ci please smoke test |
ahoppen
added a commit
to ahoppen/swift-source-compat-suite
that referenced
this pull request
Jan 4, 2023
- swiftlang/swift#57494 and swiftlang/swift#58317 have been fixed (most likely by swiftlang/swift#62734) - swiftlang/swift#62840 is a new issue introduced by swiftlang/swift#62768 - swiftlang/swift#62848 is a new issue introduced by swiftlang/swift#62734
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This pull request brings together a number of fixes and changes for expression macros:
print
)= <expression>
, using the library-defined#externalMacro
specified in SE-0382 to describe external macro definitions. This adds the first macro definition to the standard library.enum
/class
/actor
(in addition tostruct
).