[libSyntax] Incremental syntax colouring #18016
Conversation
|
@swift-ci Please smoke test |
| @@ -353,13 +358,19 @@ class Output { | |||
| bool PrettyPrint; | |||
| bool NeedBitValueComma; | |||
| bool EnumerationMatchFound; | |||
| UserInfoMap UserInfo; | |||
There was a problem hiding this comment.
UserInterprettedConfiguration Config; or something similar seems to be better naming. It's good to document that this field is not used in a generic way.
There was a problem hiding this comment.
I was leaning on the Cocoa paradigm of calling a map of arbitrary values user info where it is well established. Should I still change it? In swiftSyntax I'm also planning to call it user info and I feel on that side the name fits nicely because swiftSyntax will likely often be used in conjunction with Cocoa/CocoaTouch.
| if (EditorDoc->getSyntaxTree().hasValue()) { | ||
| SyntaxCache.emplace(EditorDoc->getSyntaxTree().getValue()); | ||
| SyntaxCache->addEdit(Offset, Offset + Length, Buf->getBufferSize()); | ||
| SyntaxCache->setRecordReuseInformation(); |
There was a problem hiding this comment.
Can SyntaxCache hold a SourceFile* instead of an old syntax tree? Then we don't need these lines, and we won't worry pulling syntax trees from a wrong source file.
|
|
||
| bool syntaxReuseInfoEnabled() override { return Opts.EnableSyntaxReuseInfo; } | ||
| bool handleSyntaxReuseRegions( | ||
| std::vector<std::pair<unsigned, unsigned>> ReuseRegions) override; |
There was a problem hiding this comment.
Define a struct instead of using std::pair<unsigned, unsigned>. In general, avoid using std::pair in a non-local context since we don't get any interesting information from it. For instance, are these unsigned offset, line-column, or something else?
There was a problem hiding this comment.
I wanted to do that, but the data is generated in swiftParse and used in SourceKit. Neither one imports the other (which I believe is a good thing), so the question comes up where this new type should be defined or if we want to convert between two different types in soucekitd. I decided that using std::pair is the lesser of three evils but am open to better suggestions.
ahoppen
force-pushed
the
003-incremental-syntax-coloring
branch
from
ab4fc62 to
e88cae0
Compare
|
@swift-ci Please smoke test |
ahoppen
force-pushed
the
003-incremental-syntax-coloring
branch
from
e88cae0 to
65e2238
Compare
|
@swift-ci Please smoke test |
Since we are reusing syntax nodes as part of incremental parsing, we cannot rely on the buffer always outliving the syntax nodes.
This will allow us to customize the serialization of a syntax tree like not serializing the node's IDs.
If enabled using the environment variable SOURCEKIT_INCREMENTAL_PARSE_VALIDATION, the incrementally parsed syntax tree will be compared to the from-scratch parsing syntax tree. If they differ a warning is emitted and log files showing the difference written to a temporary directory.
ahoppen
force-pushed
the
003-incremental-syntax-coloring
branch
from
65e2238 to
21dc447
Compare
|
@swift-ci Please test |
|
Build failed |
|
Build failed |
This PR enables incremental syntax parsing from the SourceKit API.
This can be used in two scenarios:
key.forcelibsyntaxbasedprocessingis specified (and thus the syntax map generated from the syntax tree), the syntax tree will also be parsed incrementally.Also, this PR adds an option to pass the regions that were reused as part of incremental parsing back to the caller via SourceKit, which enabled the editor to visualise the reused regions for e.g. debugging purposes.