[Macro] Omnibus pull request with macro improvements #62768
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
DougGregor
requested review from
CodaFi,
ahoppen,
bnbarham and
rintaro
as code owners
Member
Author
|
@swift-ci please build toolchain |
Member
Author
Member
Author
|
@swift-ci please smoke test |
3 similar comments
Member
Author
|
@swift-ci please smoke test |
Member
Author
|
@swift-ci please smoke test |
Member
Author
|
@swift-ci please smoke test |
DougGregor
changed the title
Member
Author
|
@swift-ci please test |
Member
Author
|
@swift-ci please built toolchain |
Member
Author
|
@swift-ci please build toolchain |
Member
Author
|
@swift-ci please smoke test |
Member
Author
|
@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!
DougGregor
force-pushed
the
macro-omnibus
branch
from
271921f to
5936b7b
Compare
Member
Author
|
@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
1 participant
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#externalMacrospecified in SE-0382 to describe external macro definitions. This adds the first macro definition to the standard library.enum/class/actor(in addition tostruct).