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.
os/activity.h or os/log.h. Update cmake files again, hardcoding a Darwin
dependency. The script does not notice that Foundation depends on
CoreGraphics, so add that manually.
Also found that MapKit is supported on WATCHOS but we didn't have dependencies
for that.
Favor one line per supported SDK instead of catch-all dependency lines.
Distinguish from SDKs which have no dependencies vs SDKs which are
unsupported on a particular platform by printing `unsupported` to the
console and remove the line in the cmake file because it should
not exist anyway.
This full cleanup was not done before because of circularity detected by the
util, which has since been fixed.
Support directories with spaces.
added the build breaks. There's already a tool to get proper
dependencies, `utils/find-overlay-dependencies.sh`, so this patch
allows that tool to update the `CMakeLists.txt` files in-place.
Also it adds a line to the `CMakeLists.txt` files for each SDK so that the tool works.
The Clang attribute allows one to state that a particular enumeration
type describes an error, and associates it with a particular domain
constant. However, due to lack of API notes support, this attribute
wasn't actually getting used. Instead, we had a number of explicit
extensions to enum types to make them conform to the _BridgedNSError
protocol explicitly.
Now that we have API notes, use them to make these enums into error
enums with the appropriate domain, so that the Clang importer will
synthesize the _BridgedNSError conformances. Then, remove all of the
explicit conformances---and with them, the overlays for 12 frameworks.
There is a small fix to more eagerly consider these conformances as
"used" if an expression is formed with the error enum as a value
type. This better ensures that the conformances will be available at
runtime when needed.
This cleanup is needed to implement SE-0112 (NSError bridging),
although it is useful by itself.
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.
At some point I want to propose a revised model for exports, but for now
just mark that support for '@exported' is still experimental and subject
to change. (Thanks, Max.)
Apps don't weak-link our overlays today, so if the overlays strong-link
to frameworks apps won't launch on older OSs. This was causing failures
on the buildbot, but is actually a serious issue for our developers.
Swift SVN r31180
-import-underlying-module deliberately avoids autolinking against that module,
since normally it's used when building the Swift half of a single binary.
For the overlays, however, that's not what we want, so add the underlying
framework explicitly.
Swift SVN r29439
Introduce a number of small overlays to bridge the NSError domains for
a number of frameworks into existing imported enums. This batch only
covers cases where there is an existing NS_ENUM describing the codes
for the domain, so we need only extend that enum to provide the
appropriate _BridgedNSError conformance.
This is the bulk of rdar://problem/20536610.
Swift SVN r28585
