These changes caused a number of issues:
1. No debug info is emitted when a release-debug info compiler is built.
2. OS X deployment target specification is broken.
3. Swift options were broken without any attempt any recreating that
functionality. The specific option in question is --force-optimized-typechecker.
Such refactorings should be done in a fashion that does not break existing
users and use cases.
This reverts commit e6ce2ff388.
This reverts commit e8645f3750.
This reverts commit 89b038ea7e.
This reverts commit 497cac64d9.
This reverts commit 953ad094da.
This reverts commit e096d1c033.
rdar://30549345
This patch generates SwiftExports.cmake and SwiftConfig.cmake in the build tree to be compatible with CMake's `find_package` function for importing targets between CMake build trees. This will allow LLDB to consume Swift's targets and infer their transitive dependencies.
This should fix out-of-tree LLDB builds.
This patch overrides the output directories setup by llvm_add_library.
This is required because swift deviates from the LLVM convention of using the LLVM_*_INTDIR variables.
This was causing failures on LLDB's PR testing because LLDB has a terrible mechanism for picking the swift libraries. It finds all the .a files by searching a directory.
This patch splits add_swift_library into two functions one which handles
the simple case of adding a library that is part of the compiler being
built and the second handling the more complicated case of "target"
libraries, which may need to build for one or more targets.
The new add_swift_library is built using llvm_add_library, which re-uses
LLVM's CMake modules. In adapting to use LLVM's modules some of
add_swift_library's named parameters have been removed and
LINK_LIBRARIES has changed to LINK_LIBS, and LLVM_LINK_COMPONENTS
changed to LINK_COMPONENTS.
This patch also cleans up libswiftBasic's handling of UUID library and
headers, and how it interfaces with gyb sources.
add_swift_library also no longer has the FILE_DEPENDS parameter, which
doesn't matter because llvm_add_library's DEPENDS parameter has the same
behavior.
This seems to more than fix a performance regression that we
detected on a metadata-allocation microbenchmark.
A few months ago, I improved the metadata cache representation
and changed the metadata allocation scheme to primarily use malloc.
Previously, we'd been using malloc in the concurrent tree data
structure but a per-cache slab allocator for the metadata itself.
At the time, I was concerned about the overhead of per-cache
allocators, since many metadata patterns see only a small number
of instantiations. That's still an important factor, so in the
new scheme we're using a global allocator; but instead of using
malloc for individual allocations, we're using a slab allocator,
which should have better peak, single-thread performance, at the
cost of not easily supporting deallocation. Deallocation is
only used for metadata when there's contention on the cache, and
specifically only when there's contention for the same key, so
leaking a little isn't the worst thing in the world.
The initial slab is a 64K globally-allocated buffer.
Successive slabs are 16K and allocated with malloc.
rdar://28189496
This should help speed up people trying to compile the standard library and do
SILGen work. *NOTE* This will not necessarily result in a type checker that is
as fast as a release build since most likely the type checker will use some
link_once odr functions that are debug. But it should still be significantly
faster otherwise.
This makes getting to SILGen take 16 seconds on my machine instead of forever
when compiling with everything else in the compiler in debug mode.
Do not add the (default) system include path as a system include path.
Doing so results in a `-isystem /usr/.../include`. This changes the
include ordering, resulting in the failure to include headers from the
system when building the standard library. This breaks compilation on
exherbo which uses a slightly different directory structure
(/usr/include -> /usr/host/include -> /usr/<target>/include). If the
paths are canonicalised during the build, we would then add
/usr/<target>/include to the CPPFLAGS, resulting in the failure to
include C headers. Unfortunately, this is insufficient as another site
is also including the path as a SYSTEM include path. But, this is still
strictly an improvement.
This seems to more than fix a performance regression that we
detected on a metadata-allocation microbenchmark.
A few months ago, I improved the metadata cache representation
and changed the metadata allocation scheme to primarily use malloc.
Previously, we'd been using malloc in the concurrent tree data
structure but a per-cache slab allocator for the metadata itself.
At the time, I was concerned about the overhead of per-cache
allocators, since many metadata patterns see only a small number
of instantiations. That's still an important factor, so in the
new scheme we're using a global allocator; but instead of using
malloc for individual allocations, we're using a slab allocator,
which should have better peak, single-thread performance, at the
cost of not easily supporting deallocation. Deallocation is
only used for metadata when there's contention on the cache, and
specifically only when there's contention for the same key, so
leaking a little isn't the worst thing in the world.
The initial slab is a 64K globally-allocated buffer.
Successive slabs are 16K and allocated with malloc.
rdar://28189496
- CYGWIN symbol is used to distinguish Cygwin environment from other OS
and other environment in Windows.
- Added windows and windowsCygnus to OSVersion in StdlibUnittest
Linking directories from `_add_variant_link_flags` of were overwritten
in `_add_swift_executable_single` by not using the
`LIBRARY_SEARCH_DIRECTORIES` parameter.
`LIBRARY_SEARCH_DIRECTORIES` is actually being used as
`RESULT_VAR_NAME` to affect the value on the parent scope. In this
context `LIBRARY_SEARCH_DIRECTORIES_VAR_NAME` sounds like a better name.
PIC on windows does not make sense. All code is position independent.
Currently clang and LLVM do the wrong thing and generate ELF style PIC
code on Windows when `-fPIC` is used. Add `-fno-pic` to disable that
when cross-compiling to Windows.
When the code was refactored, the old variable name `libkind` was left
in a couple of spots. Update them to `kind`. Remove unnecessary
quoting which would have exposed this bug.
Introduce a swift_target_link_search_directories which allows you to
append a search path to the linker. This interface also allows a tweak
to make the library search directory addition more portable across
compilers (e.g. cl vs clang).
for sib/sibgen files for libraries without building them by default.
This will let engineers just cd into the build directory and type:
ninja swift-stdlib-sib
ninja swift-stdlib-sibgen
To generate sib and sibgen files respectively.
There are still some dependency issues in between the sib targets, so to get
this to work well, I would suggest doing a full build and then using these
targets.
These headers should be treated as system headers as we do not control them.
Use target_include_directories so that we can use the `SYSTEM` option to
indicate that they are system headers. It also simplifies the invocation by not
directly modifying the underlying property.
These are the commands Pete added in 5834df3, doing slightly more work
by compiling Swift sources twice in order to start building downstream
libraries sooner.
Really, we should diagnose when -embed-bitcode is passed here, instead
of generating nonsense commands and then falling over. I filed
https://bugs.swift.org/browse/SR-3352 for that.
rdar://problem/29537164
- Add ImageInspectionStatic.cpp to lookup protocol conformance
and metadata sections in static binaries
- For Linux, build libswiftImageInspectionShared.a and
libswiftImageInspectionStatic.a for linking with libswiftCore.a.
This allows static binaries to be built without linking to
libdl. libswiftImageInspectionShared (ImageInspectionELF.cpp) is
automatically compiled into libswiftCore.so
- Adds -static-executable option to swiftc to use along with
-emit-executable that uses linker arguments in
static-executable-args.lnk. This also requires a libicu
to be compiled using the --libicu which has configure options
that dont require libdl for accessing ICU datafiles
- Static binaries only work on Linux at this time
