-
Notifications
You must be signed in to change notification settings - Fork 314
Pull SwiftSyntax into SourceKit-LSP #651
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please update the CMake builds, the build-windows-toolchain.bat in apple/swift, and this will require coordination as https://GitHub.com/compnerd/swift-build will need updates to keep the official builds from breaking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few from my comments on #652 also apply here. I only saw this PR after adding my review comments to the other one.
08bf040
to
259bf64
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. I’ve got a few comments, mostly around naming.
Re-core the "lexical" token stream on top of SwiftSyntax and call into the parser to (re-)generate these "lexical tokens" when the document changes. Leave the semantic tokens alone since they take some non-zero amount of name lookup to fully resolve references to fully replicate.
@swift-ci test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks fantastic!
@compnerd and I worked out these issues on a separate channel. Patching Swift Syntax at swiftlang/swift-syntax#991 |
As of swiftlang/sourcekit-lsp#651 sourcekit-lsp now depends on SwiftSyntax for its internal representation of documents.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, the build side of things look good to me.
As of swiftlang/sourcekit-lsp#651 sourcekit-lsp now depends on SwiftSyntax for its internal representation of documents.
The general idea is to try to use the syntax tree to provide an in-process source of truth about syntactic and structural document requests. Having the syntax tree in process also enables syntactic transformations and analyses that can be used to provide code actions, programmatic language features like (keyword) hovering, etc. both natively in Swift and without having to incur a hop out to SourceKit.
To that end, re-core the "lexical" token stream on top of SwiftSyntax and call into the parser to (re-)generate these "lexical tokens" when the document changes. Leave the semantic tokens alone since they take some non-zero amount of name lookup to fully resolve references to fully replicate.
A follow-on will demonstrate what we can start to do with this infrastructure.