Function body macros allow one to introduce a function body for a
particular function, either providing a body for a function that
doesn't have one, or wholesale replacing the body of a function that
was written with a new one.
This was causing build issues on Linux with Swift 5.8. Instead, wrap the `std::vector` in a `BridgedResolvedLocVector` that has a pointer to a heap-allocated `std::vector`
ASTGen always builds with the host Swift compiler, without requiring
bootstrapping, and is enabled in more places. Move the regex literal
parsing logic there so it is enabled in more host environments, and
makes use of CMake's Swift support. Enable all of the regex literal
tests when ASTGen is built, to ensure everything is working.
Remove the "AST" and "Parse" Swift modules from SwiftCompilerSources,
because they are no longer needed.
Defining `generate(_: XXXSyntax?) -> BridgedXXX` for each node kind is too
much boilerplate.
self.generate(optional: optionalXXXNode).asNullable
is now:
self.map(optionalXXXNode, generate(xxx:))
Now that ASTNode is used only for codeBlockItem generation. That align
with C++ ASTNode where it represent code items.
Since TypeRepr is not an ASTGen in C++, remove it from ASTGen too.
Generating ConditionElement using generate(_:) wouldn't work when we
implemnt other condition kinds e.g. patterns because they are not
ASTNode kinds.
Remove generate(choices:) and generate(_:) as they weren't used anymore.
`generate(choices:)` is not good because it expects "ASTNode". Not all
`SyntaxChildChoices` can generate ASTNode.
* `generate(codeBlockItem:)` to manually switch over the cases
* switch on `IfExpr.ElseBody` insdie `makeIfStmt()`, now supports `else
if` case
Explicit argument labels are useful for "Open Quickly..." in Xcode,
reduce the fear of miss overload resolution, and better crash
backtrace as they might not show parameter types.
There's no reason to generate only TypeRepr using ASTGen anymore.
Use ParserASTGen feature to test test/ASTGen/types.swift because
ASTGen now can generate the whole test file for type checking.
* 'ASTGenVisitor' has a reference to a legacy C++ Parser configured for
ASTGen.
* If 'ASTGenVisitor' encounters a AST node that hasn't been migrated,
call parse(Decl|Stmt|Expr|Type) to parse the position using the legacy
parser.
* The legacy parser calls ASTGen's
'swift_ASTGen_build(Decl|Stmt|Expr|Type)' for each ASTNode "parsing"
(unless the call is not directly from the ASTGen.)
rdar://117151886
Remove the default constructor footgun present with
the struct implementations, and sprinkle some
`SWIFT_NAME` and bridging utilities to make them
nicer to work with.
Add a `Bridged` prefix to match the name being
exposed to Swift, and to match the other bridging
functions. Also while here, use `SWIFT_NAME` for
some bridging functions that were missing it.
Merge with BasicBridging and ASTBridging
respectively. The changes here should be pretty
uncontroversial, I tried to keep it to just moving
code about.
Introduce a macro that can stamp out wrapper
classes for underlying C++ pointers, and use
it to define BridgedDiagnosticEngine in
ASTBridging. Then, migrate users of
BridgedDiagEngine onto it.
For nullable nodes, introduce both a non-null and
nullable variant of the bridging wrapper. This
allows us to annotate the necessary parameters
as nullable, but keep the returns of the bridged
`createParsed` methods non-null.
Always null-terminate `BridgedString` by `allocateBridgedString()`.
It had `nullTerminated: Bool` option, but allocating one extra byte
doesn't harm anything. Always null-terminate the string just for
client's convenience.
rdar://117205829
