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