When performing an insertion (replacement length = 0) inside an existing
annotation, we were forming a closed range instead of a half-open range,
causing us to shift the effected token instead of throwing it out. There
were also no tests for this functionality, so add a bunch of annotations
tests.
One area thing that is not tested is what if there have been multiple
edits since the tokens were created. This is difficult to engineer,
because right now making an edit immediately removes the semantic tokens
and returns them. It could happen if the AST build takes longer than the
edits, but there is no way to guarantee that in the current API.
rdar://65748892
The VFS tests were using Unix absolute paths, which does not play well
when Windows see them as relative to the current drive letter.
By using the temporal directory, both Windows and Unix can use the same
paths and avoid the problem.
Additionally, a couple of inputs have to be transformed into the native
path format, because sourcekitd-test compares the inputs as strings, and
they need to match exactly. So the source file and the name of the VFS
entries are transformed into native using the helper from LLVM support.
We weren't accounting for the possibility that the AST would build
faster than we could return editorOpen. While that is very unlikely, we
hit a CI failure at least once.
rdar://52211324
Rather than using the `usleep` function which is both deprecated and
non-portable (does not exist on Windows), prefer using the C++11 chrono library
for the sleep. This also allows us to use the UDL to simplify the code rather
than relying on the comments. NFCI
These tests are occassionaly timing out in CI. I have been unable to
reproduce this even with TSan and varying the pauses between operations.
On the other hand, I can get this test to run slowly if the machine is
heavily loaded, so double the timeout to see if it resolves the CI
issues.
rdar://44842835
When the server shuts down we may still have outstanding async work that
can attempt to trigger a notification, so use a shared_ptr + weak_ptr
instead of unique_ptr + unowned references.
After fixing the lock inversion from the previous commit, this test
appears to be clean under TSan on Linux and macOS, so re-enable it and
hope for the best.
I haven't found any cases where this changes the visible behaviour of
the test, but having the file remain open across invocations was
certainly unexpected and affects how the first part of the test works at
runtime.
We were always returning true from those functions in SKEditorConsumer
and false in the test consumers. On the client side we would then ignore
the return value. So it's clearer to have the functions not return
anything.
The recommended way forward is to use the SyntaxClassifier on the Swift
side.
By removing the C++ SyntaxClassifier, we can also eliminate the
-force-libsyntax-based-processing option that was used to bootstrap
incremental parsing and would generate the syntax map from a syntax
tree.
With more options coming for incremental syntax parsing, the list of
arguments will grow way to large and unhandy, so just extract them into
one common struct.
When adding to the AST consumer queue, keep track of the snapshots
expected and only run such AST consumers when a new enough AST is built.
Progress is ensured because we always run the AST consumer that
triggered the build.
This prevents cases where enqueuing a consumer during an AST build has
different behaviour than enqueuing it after the AST has finished.
rdar://40340631
The enhanced SourceKitd requests are EditorOpen and EdtiorReplaceText. In these two requests, the clients can specify a flag "key. enablesyntaxtree = 1" to get a serialize libSyntax tree with the response.
To help this integration, we added a function in SyntaxParsingContext to explicitly finalize the creation of a SourceFileSyntax to incorporate the fact that SourceKit needs the tree before its destroying the parser instance.
To test this integration, we diff the syntax tree serialized from the frontend action and the tree serialized from a SourceKitd response. They should be identical.
The previous code actually had a "semantic" error as well as a parse
error, so depending on the timing we could get 2 diagnosticsl
rdar://problem/34373697
