Adds a new 'key.retrieve_symbol_graph' option to the request. When set to 1 it
includes the JSON for a SymbolGraph containing a single node for the symbol at
the requested position.
This also extends the SymbolGraph library with a new entry point to get a graph
for a single symbol, and to additionally support type substitution to match the
existing CursorInfo behavior (e.g. so that when invoked on `first` in
`Array<Int>().first`, the type is given as `Int?` rather than `Element?`).
Resolves rdar://problem/70551509
Adds a new frontend option
"-experimental-allow-module-with-compiler-errors". If any compilation
errors occur while generating the .swiftmodule, this mode will skip SIL
entirely and only serialize the (likey invalid) AST.
This existence of this option during generation is serialized into the
resulting .swiftmodule. Errors found in deserialization are only allowed
if it is set.
Primarily intended for IDE requests (eg. indexing and code completion)
to ensure robust cross-module results, despite possible errors.
Resolves rdar://69815975
Most of the changes fall into a few categories:
* Replace explicit "x86_64" with %target-cpu in lit tests
* Cope with architecture differences in IR/asm/etc. macOS-specific tests
getSingleFrontendInvocationFromDriverArguments is set up to never produce file
lists in the output frontend arguments, but since the driver accepts file lists
as input arguments, this should too.
When producing frontend arguments for sourcekitd, force the output mode
to -typecheck so that we do not create any temporary output files in the
driver. Previously, any sourcekitd operation that created a compiler
invocation would create 0-sized .o file inside $TMPDIR that would never
be cleaned up.
The new swift-driver project handles temporaries much better as
VirtualPath, and should not need this approach.
rdar://62366123
SwiftSourceInfo files provide source location information for decls coming from
loaded modules. For most IDE use cases it either has an undesirable impact on
performance with no benefit (code completion), results in stale locations being
used instead of more up-to-date indexer locations (cursor info), or has no
observable effect (live diagnostics, which are filtered to just those with a
location in the primary file).
For non-IDE clients of SourceKit though, cursor info providing declaration
locations for symbols from other modules is useful, so add a global
configuration option (and a new request to set it) to control whether
.swiftsourceinfo files are loaded or not based on use case (they are loaded by
default).
This defers diagnosis until a stage where #if conditions have definitely been evaluated, at the cost of a slightly more complex implementation. We’ll gain some of that complexity back in a subsequent refactoring. Fixes SR-9937.
This changes the Swift resource directory from looking like
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
x86_64/
Swift.swiftmodule
Swift.swiftdoc
Darwin.swiftmodule
Darwin.swiftdoc
to
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
Swift.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
Darwin.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
matching the layout we use for multi-architecture swiftmodules
everywhere else (particularly frameworks).
There's no change in this commit to how Linux swiftmodules are
packaged. There's been past interest in going the /opposite/ direction
for Linux, since there's not standard support for fat
(multi-architecture) .so libraries. Moving the .so search path /down/
to an architecture-specific directory on Linux would allow the same
resource directory to be used for both host-compiling and
cross-compiling.
rdar://problem/43545560
We already disabled one of these because it failed (extremely) rarely in
CI, but the assumption was that there was a bug. In reality, the
behaviour was correct, so remove the unreliable checks for good and
document why in the test.
rdar://36408114
Otherwise, hits assertion, or crashes in no-assertion build.
Added 'EditableTextBuffer::getSize()' for getting size after previous updates
without actually applying them.
rdar://problem/34206143
... 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 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= ...
```
When generating a compiler invocation in driver::createCompilerInvocation()
we end up using filelists if the number of inputs is > 128 (to work around
command line arg limits). We never actually write them out though, and so
fail when parsing the frontend arguments that reference them.
As this function is called frequently by SourceKit and command line limits
aren't a concern here, this patch makes the 128 threshold value configurable
via a new -driver-filelist-threshold option. This is set to its maximum value
in driver::createCompilerInvocation() to ensure filelists aren't used. This
new option makes the existing -driver-use-filelists (that forces filelists to
be used) redundant as it's now equivalent to -driver-filelist-threshold=0.
Resolves rdar://problem/38231888
This converts the instances of the pattern for which we have a proper
substitution in lit. This will make it easier to replace it
appropriately with Windows equivalents.
Stop parsing frontend arguments directly and use the driver instead. The
most intersting part of this change is that it forces us to consider
whether our compiler invocation will have inputs or not. We have
several kinds of requests that need to create a compiler instance, but
not parse any inputs (interface-generation, doc-info, and indexing when
operating on a module instead of source files).
Incidentally, add an error when trying to do doc-info on multiple source
files. This was already very broken (assertion failures and bogus source
locations), so add an error for it.
rdar://problem/17897287
... and add a few basic statistics about the number of requests, ASTs
built, etc. The Statistic type is loosely based on the one from LLVM,
but suitable for using without DEBUG macros and using SourceKit UIdents
to identify the statistic. The easiest way to add a new statistic is to
add it to SwiftStatistics.def in the SwiftLangSupport.
Added "-help" option to Options.td
Added also:
* Added "OPT_HELP" case in the main TestOptions.cpp switch. It uses the llvm options help functionality to provide up-to-date help
* Additional "Use -help for assistance" at the end of the error message that appears when calling an unknown option
Added their following tests, respectively::
* usage.swift, and
* wrong_arguments.swift
Extra: FIXME: in TestOptions::printHelp, suggesting a possible expansion for the printHelp option (details in file)
