Update the #include in generated HeaderDependencies.cpp so it doesn't
need a special include path that points into `include/swift`. In the
swift sub-directory, there is a `Strings.h` that can be mistaken as
<string.h> on a case-insensitive file system.
rdar://119997353
The previous implementation just checked that a value's only uses besides the begin_borrow were destroys. That's insufficient to say the value is destroyed after the borrow (i.e. that all its destroys are dominated by the borrow). Add the relevant dominance check.
Fixes a compiler crash
rdar://119873930
Even if the destroyed value doesn't have a deinit.
This fixes a false alarm when a non-copyable value ends its lifetime in a function with performance annotations.
rdar://117002721
By default it lowers the builtin to an `alloc_vector` with a paired `dealloc_stack`.
If the builtin appears in the initializer of a global variable and the vector elements are initialized,
a statically initialized global is created where the initializer is a `vector` instruction.
* `alloc_vector`: allocates an uninitialized vector of elements on the stack or in a statically initialized global
* `vector`: creates an initialized vector in a statically initialized global
`HeaderDependencies.cpp` is (as in the name) C++, which means it
receives `-DSWIFT_TARGET` from the top level `add_definitions`. No need
to add it again.
`llvm::None` is deprecated, but still being used in Swift until we have
fewer 5.10 cherry-picks. Add the `SWIFT_TARGET` definition to ignore the
deprecation.
This flag is important for following optimizations. Therefore such `end_cow_mutation` instructions must not be removed.
Also, keep the flag in a SILCombine transformation.
rdar://119178823
Add the swiftmodule paths for ASTGen via
`-add_ast_path` to the public linker flags such
that downstream linking picks them up, allowing
LLDB to load them when debugging. Also switch
SwiftCompilerModules to using public linker
flags instead of adding the linker flags in
`_add_swift_runtime_link_flags`.
The calculated arguments for compiling the SwiftCompilerSources works in
the cases where the sysroot of the machine building the code is `/` or
can be provided as a single directory in `SWIFT_SDK_<HOST>_<ARCH>_PATH`.
For some cases in which a sysroot is split into multiple directories or
in some cross-compiling scenarios where the SDK layout is beyond our
control, we can provide more flexibility in the build system.
The changes in this commit moves the calculations around the SDK and
libc++ outside the `add_swift_compiler_modules_library`, since they do
not depend on the inputs. Some calculations relative to `-resource-dir`
depend on the Swift compiler path, which cannot be moved outside the
function.
The calculations outside the function are stored in a cached variable,
which is later used in the function. If the need arise, anyone can
provide a custom value for that variable in their CMake invocation or
cache files adapted for their specific case and override the
automatically calculated default.
I also rewrote a couple of `set(list ${list} …)` into `list(APPEND
list …)`.
This should be NFC for the Swift CI, because no value of
`SWIFT_COMPILER_SOURCES_SDK_FLAGS` is provided, and the default should
be the same value as before.
If one is building a LLVM unified build, with Swift as an external
project, SwiftCompilerSources can compile before the `.td` files that
generate Clang headers are finished, which will make the compilation
fail to find some files (the `.inc` files derived from those `.td`).
Make the library that uses the header depend on `clang-tablegen-targets`
to ensure those are done before the library is tried to be used.
This is not a problem in the normal `build-script` builds because in
those cases, the LLVM/Clang headers are build way before Swift is
started to be build.
To verify if a function may read from an indirect argument, don't use AliasAnalysis.
Instead use the CalleeCache to get the list of callees of an apply instruction.
Then use a simple call-back into the swift Function to check if a callee has any relevant memory effect set.
This avoids a dependency from SIL to the Optimizer.
It fixes a linker error when building some unit tests in debug.
