Explicitly invoke the script executor rather than the script as running a script is meaningless. Shebangs are not a portable manner of indicating the script executor and worse yet do not guarantee portability on such systems either. Ideally the shebang line would be removed from the script.
Thanks to @pcbeard for reporting the issue!
Clang has a new `redirecting-with` property in the VFS overlay files.
While this could be added to Swift's features as well, it is generally
the case that features provided by Clang can also be useful to know for
clients of Swift. Merge the features from Clang into Swift's features
file with the "clang-" prefix to differentiate them.
Clang has a new `redirecting-with` property in the VFS overlay files.
While this could be added to Swift's features as well, it is generally
the case that features provided by Clang can also be useful to know for
clients of Swift. Merge the features from Clang into Swift's features
file with the "clang-" prefix to differentiate them.
The only available method to check for features at the moment is through
version checks. This is errorprone and doesn't work well for OSS
toolchains or locally built compilers.
features.json is intended to communicate to build systems that a new
flag is available, in order to assist with a transitional period where
not all supported toolchains may have a particular flag. It is *not*
intended to be a comprehensive report of all flags available.
Note that the names are intended to be features, so while they may match
up to the corresponding flag name, this isn't necessarily the case.
This is a follow up to the discussion on #22740 to switch the host
libraries to use the `target_link_libraries` rather than the
`LINK_LIBRARIES` special handling. This allows the dependency to be
properly tracked by CMake and allows us to use the more modern syntax.
This reverts commit 121f5b64be.
Sorry to revert this again. This commit makes some pretty big changes. After
messing with the merge-conflict created by this internally, I did not feel
comfortable landing this now. I talked with Saleem and he agreed with me that
this was the right thing to do.
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.
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 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.
As a first step to allowing the build script to build *only*
static library versions of the stdlib, change `add_swift_library`
such that callers must pass in `SHARED`, `STATIC`, or `OBJECT_LIBRARY`.
Ideally, only these flags would be used to determine whether to
build shared, static, or object libraries, but that is not currently
the case -- `add_swift_library` also checks whether the library
`IS_STDLIB` before performing certain additional actions. This will be
cleaned up in a future commit.
This allows swiftFrontend to drop its dependency on swiftDriver, and could
someday allow us to move the integrated frontend's option parsing out of
swiftFrontend (which would allow other tools which use swiftFrontend to
exclude the option table entirely).
Swift SVN r19824
