We can finally get rid of -sil-serialize-all when building the standard library! This option will be completely eliminated in the future commits.
Instead of serializing just everything as we did before, we now serialize only functions annotated with @_inlineable. This way we can selectively control what needs to be available to the clients. This is an important step towards building a resilient standard library.
While this is a huge change for the serialization of the stdlib, it should be virtually invisible to the clients. For example, there are no noticeable performance regressions on any of the benchmarks.
Cygwin is considered a distinct target with a distinct ABI, environment
conditions, and data types. Though the goal of the project is
native Windows integration with UNIX-likes, that is not compatible with
the idea that the platform can be ignored as Win-like enough to have the
existing os(Windows) condition apply.
The warnings about deprecated @objc inference in Swift 3 mode can be a
bit annoying; and are mostly relevant to the migration workflow. Make
the warning emission a three-state switch:
* None (the default): don't warn about these issues.
* Minimal (-warn-swift3-objc-inference-minimal): warn about direct
uses of @objc entrypoints and provide "@objc" Fix-Its for them.
* Complete (-warn-swift3-objc-inference-complete): warn about all
cases where Swift 3 infers @objc but Swift 4 will not.
Fixes rdar://problem/31922278.
The `-warn-swift3-objc-inference` option turns out to be extremely
useful in vetting code for unintended `@objc` entry points, so make it
available directly on `swiftc`.
But, bury the enable/disable flags under `-frontend` (they were
effectively there anyway because the driver wasn't propagating them).
We want to know about these, both because they have an impact on our migration to Swift 4 and because we don’t want to vend extra Objective-C entry points.
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 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
We need to actually have a module name and outputs or else the add_custom_command will try to
generate multiple commands all with the name NOTFOUND.
Note, this bug was introduced in 5834df33f9 via PR #5472.
Currently SwiftOnoneSupport.o waits on Swift.o to finish compiling before we start
compiling SwiftOnoneSupport.o. We don't need the .o for compilation but instead just
need Swift.swiftmodule which we were generating anyway.
This change causes .o and { .swiftmodule, .swiftdoc } to be built independently of each
other. Downstream compiles only wait on the module while downstream links wait on the .o.
Given that .apinotes are sometimes used by swiftc invocations, this also separates out
apinotes in to its own step which these other commands can both depend on.
The result of this is a 30% improvement in building the stdlib with -R and 20% with -d.
Specifically, -R drops from 3m to 2m and -d drops from 12m to just under 10m.
This will remove the restriction that overlays always need to have a source
file matching the name of the framework, at the "cost" of standardizing the
"swiftFoo" convention for libraries with a module named "Foo". (Until
someone exposes the MODULE_NAME setting at the add_swift_library level.)
If this passes all tests, a follow-up commit will adjust the names of
some of the source files in stdlib/.
rdar://problem/17535693
In LLVM, the convention is that *_INCLUDE_* means that cmake will generate
targets but says nothing about whether or not something will be built by default
or not. This means that as far as cmake is concerned, those targets do not
exist.
On the other hand, *_BUILD_* determines whether or not a class of things is a
dependency of the "all" target. Of course this implies that *_BUILD_* implies
that *_INCLUDE_* must be set to TRUE.
Currently SWIFT_BUILD_TOOLS is implemented like a *_INCLUDE_* option, so change
its name to SWIFT_INCLUDE_TOOLS.
This adds the swiftMSVCRT module which is similar in spirit to swiftGlibc and
swiftDarwin, exposing the Microsoft C Runtime library to swift. Furthermore,
disable pieces of the standard library which are not immediately trivially
portable to Windows. A lot of this functionality can still be implemented and
exposed to the user, however, this is the quickest means to a PoC for native
windows support.
As a temporary solution, add a -DCYGWIN flag to indicate that we are building
for the cygwin windows target. This allows us to continue supporting the cygwin
environment whilst making the windows port work natively against the windows
environment (msvc). Eventually, that will hopefully be replaced with an
environment check in swift.
The Swift driver does not update the mtime of the output files if the
existing output files on disk are identical to the ones that are about
to be written. This behavior confuses the makefiles used in CMake Xcode
projects: the makefiles will not consider everything up to date after
invoking the compiler. As a result, the standard library gets rebuilt
multiple times during a single build.
To work around this issue we touch the output files so that their mtime
always gets updated.
GNU ld seems to have problems with PC-relative references to
protected functions that aren't calls. We'll generate that
pattern in Swift code in release builds because of function
merging. The workaround is to just not tell the compiler
that these symbols can be addressed PC-relative when we might
be using GNU ld, which I've conservatively approximated as
"not Darwin" while I try to figure out what changed to cause this.
Declarations with protected visibility are assumed to be defined
within the current linkage unit, so we have to use default visibility
if we don't know that we're building that. Teach the shim
visibility header to only use protected visibility when the
__SWIFT_CURRENT_DYLIB macro is defined, and define it when building
the standard library. Eventually we should change
SWIFT_RUNTIME_STDLIB_INTERFACE and SWIFT_RUNTIME_EXPORT to be
parameterized by the defining dylib so that this works for all the
overlay stubs, too; for now, special-casing swiftCore is necessary
to fix the LInux build.
A script checks if the output object file is written only once even if the compiler is invoked multiple times.
The main purpose of this check is to ensure that the compiler is deterministic (until IRGen).
Create a new CMake file responsible for functions that handle Swift
source files, such as `handle_swift_sources`. Also, add a new function,
`add_swift_source_group`, to this file. This function reduces some
duplication in `AddSwift.cmake`.
