This is a test-only change except for the introduction of a new request
that is only used by tests.
Our notifications are dispatched in the XPC event handler, which is not
synchronized with replies to explicit XPC send_message_with_reply calls.
This is fine for most users of sourcekitd, since the notifications are
already enqueued on the client side, but for testing we need a way to
guarantee that all notifications are passed to the client-side handler
before we exit. This commit introduces a new request for testing that
triggers a notification, allowing the client to wait on that
notification to ensure all previously posted notifications have been
handled.
Note: the non-deterministic test failures can be triggered by adding a
sleep of ~100 ms in the event handler before the notification is
dispatched to the main queue.
rdar://40311995
LLVM r334399 (and related Clang changes) moved clang::VersionTuple to
llvm::VersionTuple. Update Swift to match.
Patch by Jason Molenda.
rdar://problem/41025046
Calling '@objc optional func' requires '?' or '!' after its name. When
completing method calls for them, 'key.sourcetext' should have '?'
whereas 'key.name' shouldn't.
Note that we deliberately do not use optional type name for
'key.typename'. This is consistent with optional chain '?.<propertyName>'
behavior.
rdar://problem/37904574
Refactors the diagnostic code to be run whenever a compilation
notification has been started and there are diagnostics available in the
consumer. This allows us to capture diagnostics on all exit paths, and
specifically when code-completion fails because of invalid arguments.
Note: the editor.open code path still doesn't report invalid arguments
because it fails before even trying to create an AST.
... instead of overriding it after the driver is done. This improves
the fidelity of anything that looks at the resource directory inside the
driver or frontend argument parsing. In particular, it fixes an issue
where sourcekit requests would fail if they included the -sanitize=
option because the driver would fail to find the runtime libraries.
Even though this should be *more correct* for all uses, in the
interests of understanding all possible immediate effects of this
change, I manually audited all the code that looks at the resource
directory in between when it is parsed as and argument and when
createCompilerInvocation returns. I claim that the only changes are:
1. The sanitizer library check that we wanted to change
2. The DWARFDebugFlags, which are for IRGen so don't affect SourceKit
3. The Migrator data paths, which also don't affect SourceKit
For now, I put the -resource-dir option at the end of the arguments so
that it overrides any existing option, which mimics how it behaved
before. We might want to move it to the beginning so that we honour a
user-provided resource directory, but that should be a separate change.
rdar://40147839
This can't arise from a clean build, but it can happen if you have
products lingering in a search path and then either rebuild one of
the modules in the cycle, or change the search paths.
The way this is implemented is for each module to track whether its
imports have all been resolved. If, when loading a module, one of its
dependencies hasn't resolved all of its imports yet, then we know
there's a cycle.
This doesn't produce the best diagnostics, but it's hard to get into
this state in the first place, so that's probably okay.
https://bugs.swift.org/browse/SR-7483
... instead of an array of compiler arguments. This is good enough
for seeing what's going on, and it saves significant time for long
argument strings, because it doesn't create and destroy so many
xpc strings, and more of the string copying that happens is on a large
contiguous string instead of many small strings.
rdar://39538847
This code was an experiment in how to collect information after a crash,
that did not end up being used. It's unclear how much it has bitrotted
at this point, since it has no tests and was not designed with automated
testing in mind. Parts of it interfere with some changes I want to make
to the underlying tracing mechanism, so I am finally removing it. This
also lets us remove the buffer copying in the parts of tracing used by
the compile notifications, improving performance.
For rdar://39538847
This provides a very rudimentary way to check the end-to-end performance
of simple sourcekitd requests. A sample invocation might be
```
sourcekitd-test -time-request -repeat-request=10 -dont-print-response -req= ...
```
This is useful because the embedded platforms may have the same toolchain version but they contain
different stdlibs. We need to make sure the XPC service name is unique between them, otherwise we may load
and use the incorrect toolchain service.
rdar://39077520
Stop filtering out diagnostics with invalid locations in the editor
diagnostic consumer, and instead capture them separately so that we can
include them in did-compile notifications.
rdar://39225000
The only interesting change here is that I stopped filtering out
non-note diagnostics from outside the "inputs". This matches better how
code-completion gets inputs, and shouldn't hurt anything else since only
the tracing code will look at diagnostics that aren't in specific
buffers anyway.
rdar://38438512
Notifications that we want to print for testing (e.g. with FileCheck)
are now buffered and drained explicitly from the queue that performs
requests. This should prevent output intervleaving and ensure that we
actually print all the notifications that have been posted before
exiting (observed as rare test failures).
rdar://39048773
When enabled, send a notification before/after every "compilation",
which for now means `performSema`. This piggy-backs and modifies some
existing code that we had for "tracing" operations in sourcekitd that
unfortunately was untested. At least now some of the basic parts are
tested via the new notifications.
Part of rdar://38438512
This is how it was used in all but one place anyway, and makes it easier
to understand. It also aligns better with some further refactoring I
want to do...
