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
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
These were recently added to support returning the SyntaxTree in the bytetree
from SourceKit but were never added in SwiftLang (the Swift layer wrapping
SourceKit).
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).
The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
Ensure that we install the client header for the InProc sourcekitd. This is
needed to actually make it usable. With this, it is now possible to develop
against SourceKit on Linux and Windows.
Set all the target properties in a single shot. This avoids the multiple string
parsing within CMake. Although this makes no noticable differnce, it is
slightly more efficient and also colocates all the target properties.
Libraries in sourcekitd depending on the external libdispatch project
appear to only depend on the *build* step, but really need the install
to happen as well since we are linking to the installed location.
Attempt to use the host compiler when building libdispatch for SourceKit. This
is needed for cross-compiling scenarios (e.g. building the Windows toolchain on
Linux). However, unfortunately, the Ubuntu 14.04 build bots are using an
ancient compiler, so we cannot use that for building libdispatch. Add a
fallback to the just built clang. Ensure that the fallback only activates when
compiling on the same host as the target.
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.
