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
Instead of emitting an warning to the diagnostic engine, return the
plugin loading error as the result of the request. So that the user
can decide to emit it as a warning or an error.
* BridgedString for ASTGen -> C++ string returnings
* Null terminated C-strings for C++ -> ASTGen string arguments
* UnsafeMutableRawPointer for C++ -> ASTGen diagnostic engine arguments
For whatever reason, using standard headers in modules imported from
Swift code (i.e. depending on Darwin overlay) is no longer an issue.
rdar://115438609
