Pass '-fbuild-session-timestamp' and '-fmodules-validate-once-per-build-sessio'
to ClangImporter so that module validation happens only once for the
SourceKit lifetime.
rdar://problem/59567281
When a “separately imported overlay” is added to a SourceFile, two things happen:
1. The direct import of the underlying module is removed from getImports*() by default. It is only visible if the caller passes ImportFilterKind:: ShadowedBySeparateOverlay. This means that non-module-scoped lookups will search _OverlayModule before searching its re-export UnderlyingModule, allowing it to shadow underlying declarations.
2. When you ask for lookupInModule() to look in the underlying module in that source file, it looks in the overlays instead. This means that UnderlyingModule.foo() can find declarations in _OverlayModule.
in all SourceKit requests.
This validation may call many stat(2). Since we don't expect system files
are edited. Disable it for SourceKit requests. Even if they are edited,
manual builds can validates and updates them.
rdar://problem/58550697
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).
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.
The clang importer has to deal with two virtual file systems, one coming
from clang, and one coming from swift. Currently, if both are set, we
emit a diagnostic that we'll pick the swift one.
This commit changes that, by merging the two virtual file systems. The
motivation for this change is the reproducer infrastructure in LLDB,
which adds a third virtual file system to the mix.
(cherry picked from commit 94ef5431ff)
The invocation options are not an appropriate place to put this state,
since it can change between requests. This moves it to the editor
document, allowing us to change the specific VFS instance without
causing a rebuild (unless the contents/timestamps for a dependency
change).
Since Dispatch threads have a 64k stack size, tests were failing due to
blowing the stack on Windows. This runs the tests in thread with a
larger stack size. This fixes some 90ish sourcekit tests on Windows.
This is an attribute that gets put on an import in library FooKit to
keep it from being a requirement to import FooKit. It's not checked at
all, meaning that in this form it is up to the author of FooKit to
make sure nothing in its API or ABI depends on the implementation-only
dependency. There's also no debugging support here (debugging FooKit
/should/ import the implementation-only dependency if it's present).
The goal is to get to a point where it /can/ be checked, i.e. FooKit
developers are prevented from writing code that would rely on FooKit's
implementation-only dependency being present when compiling clients of
FooKit. But right now it's not.
rdar://problem/48985979
...in preparation for me adding a third kind of import, making the
existing "All" kind a problem. NFC, except that I did rewrite the
ClangModuleUnit implementation of getImportedModules to be simpler!
With this change, you will no longer receive
"error when parsing the compiler arguments". Instead, you will
receive the underlying error, like
"error: unable to load output file map 'output_file_map.json': No such file or directory"
It is possible for the SIL optimizers, IRGen, etc. to request information
from the AST that only the type checker can provide, but the type checker
is typically torn down after the “type checking” phase. This can lead to
various crashes late in the compilation cycle.
Keep the type checker instance around as long as the ASTContext is alive
or until someone asks for it to be destroyed.
Fixes SR-285 / rdar://problem/23677338.
When the server shuts down we may still have outstanding async work to
build an AST, so use a shared_ptr + weak_ptr instead of unique_ptr +
unowned references.
But not even that much uglier; at all three call sites this will save
an allocation, and for the most important one (SourceKit) we can now
avoid creating a temporary CompilerInvocation just to copy into a
longer-lived one.
With this change, Driver no longer depends on Frontend, which means...
well, slightly faster builds of the compiler itself, but not much
else.
Disable the sanitizers and code coverage when building a swift
invocation for the purpose of collecting diagnostics.
This should speed up diagnostic generation and reduce exposure to
compiler bugs.
rdar://40955900
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
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
... 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
