SourceKit document structure request used to crash if if there's inititalizer
with single named parameter with `@IBAction` attribute.
This used to happen because
ConstructorDecl::isObjCZeroParameterWithLongSelector() requires
interface type of the parameter but the constructor doesn't have it at
this stage.
This change fixes that by not vending ObjC name for
constructor or destructors.
rdar://problem/47426948
This is a new SourceKit request which receives a position in the source
file, returns possible expected types and their members which can be
referenced by "implicit member expression" syntax.
Instead of creating syntax nodes directly, modify the parser to invoke an abstract interface 'SyntaxParseActions' while it is parsing the source code.
This decouples the act of parsing from the act of forming a syntax tree representation.
'SyntaxTreeCreator' is an implementation of SyntaxParseActions that handles the logic of creating a syntax tree.
To enforce the layering separation of parsing and syntax tree creation, a static library swiftSyntaxParse is introduced to compose the two.
This decoupling is important for introducing a syntax parser library for SwiftSyntax to directly access parsing.
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"
When debugging Objective-C or C++ code on Darwin, the debug info
collected by dsymutil in the .dSYM bundle is entirely
self-contained. It is possible to debug a program, set breakpoints and
print variables even without having the complete original source code
or a matching SDK available. With Swift, this is currently not the
case. Even though .dSYM bundles contain the binary .swiftmodule for
all Swift modules, any Clang modules that the Swift modules depend on,
still need to be imported from source to even get basic LLDB
functionality to work. If ClangImporter fails to import a Clang
module, effectively the entire Swift module depending on it gets
poisoned.
This patch is addressing this issue by introducing a ModuleLoader that
can ask queries about Clang Decls to LLDB, since LLDB knows how to
reconstruct Clang decls from DWARF and clang -gmodules producxes full
debug info for Clang modules that is embedded into the .dSYM budle.
This initial version does not contain any advanced functionality at
all, it merely produces an empty ModuleDecl. Intertestingly, even this
is a considerable improvement over the status quo. LLDB can now print
Swift-only variables in modules with failing Clang depenecies, and
becuase of fallback mechanisms that were implemented earlier, it can
even display the contents of pure Objective-C objects that are
imported into Swift. C structs obviously don't work yet.
rdar://problem/36032653
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.
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.
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!
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.
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.
