Now that that's stabilized, we don't have to keep them in Swift 4 mode
any longer. (Arguably we don't need the CMake variable at all, but it
may be useful again in the future.)
rdar://problem/49040980
CMake supports the notion of installation components. Right now we have some
custom code for supporting swift components. I think that for installation
purposes, it would be nice to use the CMake component system.
This should be a non-functional change. We should still only be generating
install rules for targets and files in components we want to install, and we
still use the install ninja target to install everything.
I also removed the -verify-sil-ownership flag in favor of a disable flag
-disable-sil-ownership-verifier. I used this on only two tests that still need
work to get them to pass with ownership, but whose problems are well understood,
small corner cases. I am going to fix them in follow on commits. I detail them
below:
1. SILOptimizer/definite_init_inout_super_init.swift. This is a test case where
DI is supposed to error. The only problem is that we crash before we error since
the code emitting by SILGen to trigger this error does not pass ownership
invariants. I have spoken with JoeG about this and he suggested that I fix this
earlier in the compiler. Since we do not run the ownership verifier without
asserts enabled, this should not affect compiler users. Given that it has
triggered DI errors previously I think it is safe to disable ownership here.
2. PrintAsObjC/extensions.swift. In this case, the signature generated by type
lowering for one of the thunks here uses an unsafe +0 return value instead of
doing an autorelease return. The ownership checker rightly flags this leak. This
is going to require either an AST level change or a change to TypeLowering. I
think it is safe to turn this off since it is such a corner case that it was
found by a test that has nothing to do with it.
rdar://43398898
I have been meaning to do this change for a minute, but kept on putting it off.
This describes what is actually happening and is a better name for the option.
The previous commit resulted in multiple targets that claimed to be
able to generate the directories in question. Instead, just create the
directories as a pre-build step for the targets that actually need
them. (This does keep the cleanup for the existing directory creation
target, though.)
More https://bugs.swift.org/browse/SR-10029
The way it was set up before worked for Ninja but not for Xcode, due
to me not listing the swiftmodule directories as actual outputs of the
create-directories target. The resulting fix here is actually simpler
and involves fewer processes anyway, so good for us.
https://bugs.swift.org/browse/SR-10029
This changes the Swift resource directory from looking like
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
x86_64/
Swift.swiftmodule
Swift.swiftdoc
Darwin.swiftmodule
Darwin.swiftdoc
to
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
Swift.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
Darwin.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
matching the layout we use for multi-architecture swiftmodules
everywhere else (particularly frameworks).
There's no change in this commit to how Linux swiftmodules are
packaged. There's been past interest in going the /opposite/ direction
for Linux, since there's not standard support for fat
(multi-architecture) .so libraries. Moving the .so search path /down/
to an architecture-specific directory on Linux would allow the same
resource directory to be used for both host-compiling and
cross-compiling.
rdar://problem/43545560
When we do standalone overlay builds, they should rely on these
layouts already being in the toolchain. (In particular, the target
is never created.)
No tests because this configuration isn't (currently) being tested
outside of Apple.
This adds a new copy-legacy-layouts-${platform}-${arch} target for each
platform and architecture that the standard library is built for.
If the platform and architecture has a corresponding layout file in
stdlib/public/legacy_layouts/${platform}/layouts-${arch}.yaml, the
target copies this file to the build directory; otherwise, it does
nothing.
When building Swift code, the subroutines in SwiftSource.cmake add a
dependency on this target from each Swift code target.
Finally, we ensure that the YAML files are copied into the toolchain
package when building a toolchain.
Once upon a time we tried to use this to limit the visibility of
symbols in the Swift runtime in a way that didn't really make sense.
Dave Z removed it last year in 91823273d2.
No functionality change.
This fixes using --install-swift on macOS when not building all of the
variant stdlibs (e.g. iphonesimulator, etc.).
When we build swift on macOS, by default we build only the macOS stdlib.
The other stdlib variants are still configured and there are targets to
build them if you e.g. run `ninja swift-stdlib-iphonesimulator-x86_64`
manually. However, we do not separate the _install_ actions. This
meant that you couldn't install without building all the configured
stdlib variants.
They're all the same anyway, and no longer even need to be compiled,
just copied in as text.
And drastically simplify how we "generate" them. Instead of attaching
their build jobs to the appropriate overlays, if present, "just" have
one job to copy them all and attach it to the Darwin overlay. That's
what we do for the overlay shim headers, and it's good enough.
(Eventually we want to get out of the business of shipping them
altogether.)
This does have the same flaw as the shim headers: if you /just/ change
API notes, the corresponding overlay does not get rebuilt. You have to
touch that too. But in practice that'll happen most of the time
anyway.
Part of rdar://problem/43545560
This change could impact Swift programs that previously appeared
well-behaved, but weren't fully tested in debug mode. Now, when running
in release mode, they may trap with the message "error: overlapping
accesses...".
Recent optimizations have brought performance where I think it needs
to be for adoption. More optimizations are planned, and some
benchmarks should be further improved, but at this point we're ready
to begin receiving bug reports. That will help prioritize the
remaining work for Swift 5.
Of the 656 public microbenchmarks in the Swift repository, there are
still several regressions larger than 10%:
TEST OLD NEW DELTA RATIO
ClassArrayGetter2 139 1307 +840.3% **0.11x**
HashTest 631 1233 +95.4% **0.51x**
NopDeinit 21269 32389 +52.3% **0.66x**
Hanoi 1478 2166 +46.5% **0.68x**
Calculator 127 158 +24.4% **0.80x**
Dictionary3OfObjects 391 455 +16.4% **0.86x**
CSVParsingAltIndices2 526 604 +14.8% **0.87x**
Prims 549 626 +14.0% **0.88x**
CSVParsingAlt2 1252 1411 +12.7% **0.89x**
Dictionary4OfObjects 206 232 +12.6% **0.89x**
ArrayInClass 46 51 +10.9% **0.90x**
The common pattern in these benchmarks is to define an array of data
as a class property and to repeatedly access that array through the
class reference. Each of those class property accesses now incurs a
runtime call. Naturally, introducing a runtime call in a loop that
otherwise does almost no work incurs substantial overhead. This is
similar to the issue caused by automatic reference counting. In some
cases, more sophistacated optimization will be able to determine the
same object is repeatedly accessed. Furthermore, the overhead of the
runtime call itself can be improved. But regardless of how well we
optimize, there will always a class of microbenchmarks in which the
runtime check has a noticeable impact.
As a general guideline, avoid performing class property access within
the most performance critical loops, particularly on different objects
in each loop iteration. If that isn't possible, it may help if the
visibility of those class properties is private or internal.
...i.e. an actual shell-like argument list, rather than a
semicolon-separated list (CMake's internal stringification mechanism
for lists). Apart from being a little easier to read, this also works
directly with the response file support in swiftc itself now (not
depending on utils/line-directive).
(It's still not /quite/ enough to expand on a command-line, though,
since that will escape the quotes. The 'sed' command can get around
that: $(sed "s/'//g" foo.txt).)
Commit to a command line option spelling so that build systems can
start testing it. I deliberately picked one of the longer names we
were considering because we can always decide to add a shorter alias,
but can't decide a shorter name was too generic.
Like the other supplementary output flags,
-emit-parseable-module-interface-path will emit a .swiftinterface file
to a particular path, while -emit-parseable-module-interface will put
it next to the main output (the one specified with -o).
rdar://problem/43776945
Clang's been able to read the textual format for a long time, and
indeed that's what's used in the SDK. This isn't even really a
performance win because the information is cached in PCMs.
rdar://problem/34293901
This may not be their final destination, but at least this will
get them into built toolchains, which means it'll be easier to
do integration testing once all the other pieces are in place.
rdar://problem/43823937
We're not using them for anything yet, but this will exercise
-emit-interface while we're working on it and make sure that it
doesn't crash when processing complex code like the standard library.
* Update std lib to Swift 5.0
* Disable Unicode.* warnings for now
* Slow path to resiliently handle the case where an unknown rounding rule is passed
* Remove resilience from Encoding/DecodingError (which should only happen on slow paths anyway)
* internal typealiases now need @usableFromInline
* Force inlining on Array._owner.get
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).
