Skip to content

[Syntax] return-statement, integer-literal-expression, child caching #7706

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 4 commits into from
Feb 23, 2017
Merged

[Syntax] return-statement, integer-literal-expression, child caching #7706

merged 4 commits into from
Feb 23, 2017

Conversation

bitjammer
Copy link
Contributor

@bitjammer bitjammer commented Feb 23, 2017

Resolves #46595, resolves #46625

A return statement needs something to return, so implement
integer-literal-expression too. This necessarily also forced
UnknownExprSyntax, UnknownStmtSyntax, and UnknownDeclSyntax,
which are stand-in token buckets for when we don't know
how to transform/migrate an AST.

This commit also contains the core function for caching
SyntaxData children. This is highly tricky code, with some
detailed comments in SyntaxData.{h,cpp}. The gist is that
we have to atomically swap in a SyntaxData pointer into the
child field, so we can maintain pointer identity of SyntaxData
nodes, while still being able to cache them internally.

To prove that this works, there is a multithreaded test that
checks that two threads can ask for a child that hasn't been
cached yet without crashing or violating pointer identity.

https://bugs.swift.org/browse/SR-4010
@bitjammer
Copy link
Contributor Author

@swift-ci Please smoke test

@bitjammer bitjammer merged commit fa50dc5 into swiftlang:master Feb 23, 2017
@bitjammer bitjammer deleted the sr-4010-return-statement-syntax branch February 23, 2017 03:32
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.

1 participant