[ASTGen] Generate PatternBindingDecl at top level #79355
Conversation
rintaro
requested review from
ahoppen,
bnbarham,
CodaFi,
hamishknight,
hborla,
slavapestov,
xedin and
DougGregor
as code owners
rintaro
changed the title
|
@swift-ci Please smoke test |
* Instead of hoisting VarDecl in the bridging functions, do it in ASTGen. * Introduce `Decl::forEachDeclToHoist` to handle VarDecls in PatternBindingDecl, and EnumElementDecl in EnumCaseDecl. * Intorduce `withBridgedSwiftClosure(closure:call:)` as a callback mechanism between Swift and C++ * In `generate(sourceFile:)`, instead of using `generate(codeBlockItem:)` handle `CodeBlockItemSyntax.Item` manually to handle `TLCD` wrapping and `VarDecl` hoisting. * Make `generate(variableDecl:)` handle TLCD correctly.
rintaro
force-pushed
the
astgen-toplevelvardecl
branch
from
a70914f to
6ea6a31
Compare
|
@swift-ci Please smoke test |
| // MARK: BridgedSoureFile | ||
| //===----------------------------------------------------------------------===// | ||
|
|
||
| BRIDGED_INLINE bool BridgedSourceFile_isScriptMode(BridgedSourceFile sf) { |
There was a problem hiding this comment.
Nit: BRIDGED_INLINE isn't needed here
There was a problem hiding this comment.
Copy paste error... let me fix it later along with another BRIDGED_INLINE in this file.
| func withBridgedSwiftClosure(closure: (UnsafeRawPointer?) -> Void, call: (BridgedSwiftClosure) -> Void) { | ||
| withoutActuallyEscaping(closure) { escapingClosure in | ||
| withUnsafePointer(to: escapingClosure) { ptr in | ||
| call(BridgedSwiftClosure(closure: ptr)) | ||
| } | ||
| } | ||
| } | ||
|
|
||
| @_cdecl("swift_ASTGen_bridgedSwiftClosureCall_1") | ||
| func bridgedSwiftClosureCall_1(_ bridged: BridgedSwiftClosure, _ arg: UnsafeRawPointer?) { | ||
| bridged.closure.assumingMemoryBound(to: ((UnsafeRawPointer?) -> Void).self).pointee(arg) | ||
| } |
There was a problem hiding this comment.
Can't say I love this, I guess the alternative would be having the bridging API take a C function pointer along with an opaque void * context which the caller would then load as the right type. Not sure that would be much of an improvement though :(
There was a problem hiding this comment.
I don't love either, this was the best I came up with 😓
| @@ -253,6 +263,23 @@ extension ASTGenVisitor { | |||
| return generateSourceRange(node) | |||
| } | |||
|
|
|||
| /// Obtains bridged token source range for a syntax node. | |||
| /// Unlike `generateSourceRange(_:)`, this correctly emulates the string/regex literal token SourceLoc in AST. | |||
There was a problem hiding this comment.
Is there any reason to not have generateSourceRange handle this case?
There was a problem hiding this comment.
Performance concern, I believe endTok.parent?.kind still implies retain/release. Also, after fully migrating to SwiftParser/ASTGen, I believe generateSourceRange() is more correct. So I hesitate to use this function extensively.
VarDeclinASTGen, instead of do it in the bridging functions.Decl::forEachDeclToHoistto handle VarDecls in PatternBindingDecl, and EnumElementDecl in EnumCaseDecl.withBridgedSwiftClosure(closure:call:)as a callback mechanism between Swift and C++generate(sourceFile:), instead of usinggenerate(codeBlockItem:), handleCodeBlockItemSyntax.Itemmanually to performTLCDwrapping andVarDeclhoisting.generate(variableDecl:)handle TLCD correctly.