* add the (still empty) libswift package
* add build support for libswift in CMake
* add libswift to swift-frontend and sil-opt
The build can be controlled with the LIBSWIFT_BUILD_MODE cmake variable: by default it’s “DISABLE”, which means that libswift is not built. If it’s “HOSTTOOLS”, libswift is built with a pre-installed toolchain on the host system.
Add a debugging mechanism that enables the JIT to dump the LLVM IR and
object files to enable debugging the JIT. This makes it easier to debug
the JIT mode failures. The idea was from Lang Hames!
With an inverted pipeline, IRGen needs to be able
to compute the linker directives itself, so sink
it down such that it can be computed by the
`IRGenDescriptor`.
With an inverted pipeline, IRGen needs to be able
to compute the linker directives itself, so sink
it down such that it can be computed by the
`IRGenDescriptor`.
Delete all of the formalism and infrastructure around maintaining our own copy of the global context. The final frontier is the Builtins, which need to lookup intrinsics in a given scratch context and convert them into the appropriate Swift annotations and types. As these utilities have wormed their way through the compiler, I have decided to leave this alone for now.
All of this is in service of working around a pile of deficiencies in LLVM's Module Linker, and LLVMContext abstractions. And because we're just gonna scrap this code soon anyways, it's probably not worth the effort to push on these bugs to block the broader cleanup here.
The LLVM Linker currently does not support linking modules allocated in different contexts. This appears to be motivated in part by LLVM's lack of a facility to clone a module from one context to another. This, in turn, appears to be motivated in part by LLVMContext's lack of a robust notion of identity - which makes it harder than it needs to be to detect the mismatch.
However, it is not impossible to clone a module across contexts. We need to get creative and round-trip the module through some serialization layer. Out of convenience, that layer is currently textual IR, though bitcode would work equally well.
Given that it is no longer under the caller's control which LLVMContext we generate code in, put all the above together to arrive at an egregious hack that clones the module into the LLVMContext the REPL expects.
swift::GeneratedModule encapsulates an llvm::Module, llvm::LLVMContext
pair that must live and die together. It has convenient accessors for
projecting the module and context components. The meat of this type is
the two conversion functions, which transfer ownership of either the
module component to the caller or the module and context to ORCJIT.
This is because ORC enforces an ownership contract that is distinct from
LLVM's rather wild ownership story for modules and their associated
contexts. See http://llvm.org/docs/ORCv2.html#how-to-use-threadsafemodule-and-threadsafecontext
LLJIT is a simple LLVM IR JIT. Its interface is similar to MCJIT, but its
implementation is based on LLVM's newer ORC APIs. This initial patch does not
make use of any of LLJIT/ORC's advanced features, but will provide better
diagnostics when JIT'd code fails to link. Once LLJIT has proven usable in
this basic configuration we can start experimenting with more advanced
features, including lazy compilation.
The REPL was using the CompilerInstance to stash this parameter, then it would immediately move it into IRGen. Drop the setter and pass this data directly.
The library does not have the lib prefix in Windows, so the immediate
mode was not finding the file. This was making the new tests in
tests/Driver/options.swift fail on Windows. The tests pass after this
change.
Notice that it seems to load the host standard library, so restricting
the change to Windows seems to be OK and should not affect
cross-compilation. Windows was already hardcoding ".dll" as the library
extension, disregarding the target, anyway.
- Check the target triple at runtime to decide whether to use the fallback.
- Change isInResourceDir to actually check the resource dir.
- Use ArrayRef<std::string> instead of std::vector<std::string>.
We had three copies of this code, each of which did a bit more work than
was actually necessary. Consolidate them and avoid calling
`collectLinkLibraries()` on a given module more than once within this
path.
Instead of using the target that was passed to the driver. Use the target from
the clang importer that might have been changed by clang (i.e armv7 to thumbv7
on darwin)
rdar://32599805
These changes are trying to fix problem related to changes from upstream
LLVM which changes the way how diagnostics are handled in presence of linker
failures.
Resolves: rdar://problem/35458963
* Use clang's effective llvm triple for IR generation
Instead of using the target that was passed to the driver. Use the target from
the clang importer that might have been changed by clang (i.e armv7 to thumbv7
on darwin)
rdar://32599805
* Address review comments
* Fix test case osx-targets.swift
* Fix pic.swift test case
* Fix test abi_v7k.swift
* Address review comment for test osx-targets.swift
This has the effect of propagating the search path to the clang importer as '-iframework'.
It doesn't affect whether a swift module is treated as system or not, this can be done as follow-up enhancement.
The typedef `swift::Module` was a temporary solution that allowed
`swift::Module` to be renamed to `swift::ModuleDecl` without requiring
every single callsite to be modified.
Modify all the callsites, and get rid of the typedef.
Changes:
* Terminate all namespaces with the correct closing comment.
* Make sure argument names in comments match the corresponding parameter name.
* Remove redundant get() calls on smart pointers.
* Prefer using "override" or "final" instead of "virtual". Remove "virtual" where appropriate.
