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.
The SourceKit component requires libdispatch and BlocksRuntime to run.
We build the libraries as part of the build and use it via imported
targets. Ensure that the dependencies get installed for use at runtime.
The swift-lang swift module requires the standard library to be built and is
part of the standard library component. Ensure that this is taken into
consideration when we attempt to build it.
Also fix Edit::intersectsOrTouchesRange check only returning true when the
ranges overlapped, rather than when they overlapped or 'touched'.
Resolves rdar://problem/45108439
SourceKit's build is now ammenable to building for Windows. Generalize the path
to enable building it for Windows as well as Linux. The libdispatch build for
the compiler is needed for all non-Darwin targets currently.
In the case that a system update temporarily breaks the command, the output may
be empty, and this can cause CMake to fail in a weird manner. Quote the
variable to be more resilient to the transient failure.
Internal.h must be included before sourcekitd.h to ensure that we get the
correct definition for Windows targets. The inclusion of `sourcekitd.h` is not
needed after the inclusion of `Internal.h` so simply remove the inclusion.
On Darwin platforms, libdispatch and libBlocksRuntime are re-exported from
libSystem (via LC_REEXPORT_DYLIB). Other platforms do not have libdispatch and
libBlocksRuntime in their C runtime, so we need to explicitly link against them.
Now that we are building BlocksRuntime with hidden visibility, we do not
accidentally get the symbols from libdispatch.
sourcekitd_variant_t is only safe to use while the sourcekitd_response_t it was
retrieved from is still alive, so keep a strong reference to SourceKitdResponse
(the Swift wrapper of sourcekitd_response_t) in each Variant (the Swift wrapper
of sourcekitd_variant_t).
Fill in some of the Windows codepaths that were previously missing. This allows
us to at least compile the SourceKit sources. More changes are required to the
build system to use the correct compiler when cross-compiling to get the
dependencies correct.
Not all targets (CMAKE_SYSTEM_NAME) use `lib` and `.a` for the static library
name. Adjust the name properly for the host that we are building for. This
repairs the build when performing a cross-compile from Linux to Windows.
When building libdispatch for SourceKit, only enable the swift overlay
components if the swift standard library is being built. This allows building
just the compiler and SourceKit.
The decision to whether build InProc or as an XPC service is needed for the
test tools as well. Rather than recompute it for the tests as well, hoist it to
the top level for the SourceKit project. This repairs the build of the
SourceKit tests on non-Darwin hosts.
Module references get indexed as a 'module' symbol; they get USRs similar to how clang would assign a USR for a module reference.
JIRA: https://bugs.swift.org/browse/SR-8677
Addressing review feedback: this avoids calling shared_from_this() from
outside the implementation. Note: it is not possible to use private
inheritance of enable_shared_from_this to prevent this issue in general,
because enabled_shared_from_this relies on the shared_ptr constructor
being able to detect that the type has this inheritance, which means it
must be public.
While I'm not aware of this causing an issue in practice it was just
begging to trigger a use-after-free if we ever used this reference in a
new method since the editor document is accessed asynchronously.
While the SwiftLangSupport doesn't currently outlive the global context
it clarifies the ownership to just store the weak reference we care
about instead of referencing the owning context. In the future we may
want to ref-count the lang support, in which case we'd need to do this
to avoid a cycle anyway.
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.
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.
When triggering replaceText we were locking the EditorDocument then the
ASTProducer, but during AST building we do the reverse. This would cause
a deadlock if these two bits of code raced. Break the cycle by dropping
the editor lock when calling the ASTManager.
Thank you TSan!
This was causing local refactorings (which are line+column-based) to fail due to
the provided location being considered invalid, even though the available
refactorings request (which uses offset directly) reported them as available.
When a document is opened twice without closing it we re-initialize its
internal data. Make sure we don't race with code that accesses that data.
Found by TSan!
Package up the logic that generates a full Clang module name, so that
(a) we don't have to deal with clang::Module in quite as many places
in the /Swift/ compiler, and (b) we can avoid the cost of a temporary
string in a few places.
The main places where this is /not/ adopted is where we don't just
want to know the parent module name, but actually the module itself.
This is mostly indexing-related queries, which use the very similar
ModuleEntity class also defined in Module.h. I didn't quite see an
obvious way to unify these, but that might be where we want to go.
No functionality change.
If an imported Objective-C method had no owning clang module, passCursorInfoForDecl() would call clang::Module::getFullModuleName() on a null instance. The current implementation of this method happens to terminate its loop immediately and return an empty string, but it’s best not to depend on this. Fixes a UBSan error in SourceKit/Mixed/cursor_mixed_header.swift.
CompactArrayReader has a bad habit of doing type-punning in ways that could cause unaligned memory accesses. 21 tests trigger a UBSan assertion because of this. Use memcpy instead to avoid the issue.
The right way is findBufferContainingLoc. getBufferIdentifierForLoc is
both slower and wrong in the presence of #sourceLocation.
I couldn't come up with a test for the change in IDE/Utils.cpp because
refactoring still seems to be broken around #sourceLocation. I'll file
bugs for that.
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.
Most of this patch is just removing special cases for materializeForSet
or other fairly mechanical replacements. Unfortunately, the rest is
still a fairly big change, and not one that can be easily split apart
because of the quite reasonable reliance on metaprogramming throughout
the compiler. And, of course, there are a bunch of test updates that
have to be sync'ed with the actual change to code-generation.
This is SR-7134.
If we know the size of a type at compile time (like we do for all the
integer types), it is cheaper to assign the data buffer directly instead
of using a memcpy.
