Skip to content

[ASTGen] Infrastructure for implementing ASTGen incrementally #69761

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 5 commits into from
Nov 13, 2023

Conversation

rintaro
Copy link
Member

@rintaro rintaro commented Nov 9, 2023

  • ASTGenVisitor has a reference to a legacy C++ Parser configured for ASTGen.
  • When ASTGenVisitor encounters a AST node that hasn't been migrated, call the C++ Parser::parse(Decl|Stmt|Expr|Type) to parse the position using the legacy parser.
  • If the legacy parser is configured for ASTGen, it 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

@rintaro rintaro force-pushed the astgen-incremental-develop branch 3 times, most recently from c15feed to b423363 Compare November 9, 2023 23:18
//===--------------------------------------------------------------------===//
// ASTGen support.

ParserResult<TypeRepr> parseTypeReprFromSyntaxTree();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just reading the function declaration, I’m thinking: Which syntax tree is this parsing from? I think a doc comment could help explain this (or a need a better name).

break
case // Known unimplemented kinds.
.arrayExpr, .arrowExpr, .asExpr, .assignmentExpr, .awaitExpr,
.binaryOperatorExpr, .booleanLiteralExpr, .borrowExpr, .canImportExpr,
Copy link
Member Author

@rintaro rintaro Nov 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Literals are already implemented. I didn't notice that they were in Literals.swift.

When 'wantOutermost' is true, traverse the parent as long as the
position is the same as the target position.
@rintaro rintaro force-pushed the astgen-incremental-develop branch from 0323409 to f333245 Compare November 10, 2023 21:17
@rintaro
Copy link
Member Author

rintaro commented Nov 10, 2023

@swift-ci Please smoke test

@rintaro rintaro force-pushed the astgen-incremental-develop branch from f333245 to 5f7c020 Compare November 10, 2023 23:22
@rintaro
Copy link
Member Author

rintaro commented Nov 10, 2023

@swift-ci Please smoke test

@rintaro
Copy link
Member Author

rintaro commented Nov 10, 2023

preset=asan
@swift-ci Please test with preset macOS platform

@rintaro rintaro force-pushed the astgen-incremental-develop branch from 5f7c020 to 253fbb9 Compare November 11, 2023 00:03
@rintaro
Copy link
Member Author

rintaro commented Nov 11, 2023

@swift-ci Please smoke test

@rintaro
Copy link
Member Author

rintaro commented Nov 11, 2023

preset=asan
@swift-ci Please test with preset macOS platform


/// Parse a TypeRepr from the syntax tree. i.e. SF->getExpxortedSourceFile()
ParserResult<TypeRepr> parseTypeReprFromSyntaxTree();
/// Parse a Stmt from the syntax tree. i.e. SF->getExpxortedSourceFile()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo "Expxorted" in all of these.

}
else {
// FIXME: Produce an error
return nil
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be worth putting in some stub error sooner rather than later, so this doesn't cause unwanted surprises.

Copy link
Member Author

@rintaro rintaro Nov 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently findSyntaxNodeInSourceFile() prints an error message to stdout, which is not great, but at least it prevents "unwanted surprises". But yeah, I think we should add a diagnostic on the diagnostic engine.
Though since this PR is getting big, and to unblock some follow-up patches I have, I'd like to do it in the followups.
Also, I'm thinking to change findSyntaxNodeInSourceFile() itself. #69724 (comment)

@DougGregor
Copy link
Member

I like this approach of bouncing between the two parsers as needed, so we can opt in to ASTGen production-by-production.

* '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
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.
Apparently C++ method bridging doesn't work in Linux?
@rintaro rintaro force-pushed the astgen-incremental-develop branch from fe4ba34 to d51058c Compare November 13, 2023 05:43
@rintaro
Copy link
Member Author

rintaro commented Nov 13, 2023

@swift-ci Please smoke test

@rintaro
Copy link
Member Author

rintaro commented Nov 13, 2023

preset=asan
@swift-ci Please test with preset macOS platform

@rintaro rintaro marked this pull request as ready for review November 13, 2023 05:51
@rintaro rintaro requested a review from tshortli as a code owner November 13, 2023 05:51
@rintaro rintaro requested review from DougGregor, ahoppen and hamishknight and removed request for xedin, slavapestov, CodaFi, hborla and tshortli November 13, 2023 05:51

// -enable-experimental-feature requires an asserts build
// REQUIRES: asserts
// REQUIRES: rdar116686158
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is really unfortunate that this test hits ASAN failure too. We're actively looking into this issue.
Anyway I confirmed these tests passes locally.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we mark it UNSUPPORTED: asan for now so we at least don't lose the test coverage?

@@ -113,6 +134,67 @@ struct SwiftParserExecutor {
}
};

static void appendToVector(void *declPtr, void *vecPtr) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this used? Only reference I see is in ParseDecl.cpp

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, it's a leftover. I'm removing it in a followup

Copy link
Contributor

@hamishknight hamishknight left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool!

) -> UnsafeMutableRawPointer? {
let sourceFile = sourceFilePtr.assumingMemoryBound(to: ExportedSourceFile.self)

// Find the type syntax node.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Not necessarily a type syntax any more, right?

drodriguez added a commit to drodriguez/swift that referenced this pull request Nov 14, 2023
The field `IsForASTGen` only exists when `SWIFT_BUILD_SWIFT_SYNTAX` is
defined, but the usage was unprotected. The whole function can be inside
the protected block because it only seems to be invoked from inside
blocks already protected by `SWIFT_BUILD_SWIFT_SYNTAX`.

Fix for swiftlang#69761
drodriguez added a commit that referenced this pull request Nov 14, 2023
…69858)

The field `IsForASTGen` only exists when `SWIFT_BUILD_SWIFT_SYNTAX` is
defined, but the usage was unprotected. The whole function can be inside
the protected block because it only seems to be invoked from inside
blocks already protected by `SWIFT_BUILD_SWIFT_SYNTAX`.

Fix for #69761
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants