With this change, swiftc will still look for standard library and overlay modules in ../lib/swift (relative to the compiler), but if it doesn’t find them there, it will now look in usr/lib/swift in the SDK.
Replaces SearchPathOptions::RuntimeLibraryImportPath with an equivalent std::vector of paths. Also reimplements SearchPathOptions::SkipRuntimeLibraryImportPaths to cause the list of runtime library import paths to be empty, rather than exiting early from SerializedModuleLoader::findModule().
Windows does not permit cross-module data accesses to be direct. This
is a problem for public protocols with root conformances which are
external. Use a runtime initialiser for the root protocol conformance
chaining to alleviate this issue. This shows up in the Foundation
build.
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
The layouts of resilient value types shipped in the Swift 5 standard library
x and overlays will forever be frozen in time for backward deployment to old
Objective-C runtimes. This PR ensures that even if the layouts of these types
evolve in the future, binaries built to run on the old runtime will continue
to lay out class instances in a manner compatible with Swift 5.
Fixes <rdar://problem/45646886>.
The LLVM API for the temporary paths behaves differently on Windows and Unix.
Windows always returns the absolute path, and on Unix, you get whatever is in
the environment. Furthermore, windows allows both `\` and `/` as separators.
Normalise the path and make it absolute before doing the comparision to get a
comparable string.
When -enable-anonymous-context-mangled-names is provided, emit mangled
names as part of the metadata of an anonymous context. This will allow
us to match textual mangled names to the metadata.
This is a backward-compatible ABI extension. Part of rdar://problem/38231646/.
This was a nice feature when people said "-swift-version 3.1"...
up until we got "-swift-version 4.2" as an actual valid version.
Just drop the special case.
https://bugs.swift.org/browse/SR-8850
<rdar://problem/46548531> Extend @available to support PackageDescription
This introduces a new private availability kind "_PackageDescription" to
allow availability testing by an arbitary version that can be passed
using a new command-line flag "-swiftpm-manifest-version". The semantics
are exactly same as Swift version specific availability. In longer term,
it maybe possible to remove this enhancement once there is
a language-level availability support for 3rd party libraries.
Motivation:
Swift packages are configured using a Package.swift manifest file. The
manifest file uses a library called PackageDescription, which contains
various settings that can be configured for a package. The new additions
in the PackageDescription APIs are gated behind a "tools version" that
every manifest must declare. This means, packages don't automatically
get access to the new APIs. They need to update their declared tools
version in order to use the new API. This is basically similar to the
minimum deployment target version we have for our OSes.
This gating is important for allowing packages to maintain backwards
compatibility. SwiftPM currently checks for API usages at runtime in
order to implement this gating. This works reasonably well but can lead
to a poor experience with features like code-completion and module
interface generation in IDEs and editors (that use sourcekit-lsp) as
SwiftPM has no control over these features.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
The metadata reference to the pre-exsting VWT cannot be supported on PE/COFF
due to the direct reference to a value in an external module that is in
static data (the model requires indirecting through memory). Always
force the lazy initialization for the metadata on such platforms.
This requires a secondary change - to initialize the VWT as well. This
is ideally moved into the runtime where we can do this uniformly.
Because this feature mostly exists for the standard library, turn it on
specifically. This avoids having to serialize it in the flags necessary
for parseable interfaces.
If runtime asserts are disabled in general, also disable runtime
exclusivity checks unless explicitly requested.
-Ounchecked is an unsupported benchmarking mode, but, if used, it
should disable all runtime assertions. Exclusivity checks are no more
essential than integer overflow or bounds checks.
`#assert` is a new static assertion statement that will let us write
tests for the new constant evaluation infrastructure that we are working
on. `#assert` works by lowering to a `Builtin.poundAssert` SIL
instruction. The constant evaluation infrastructure will look for these
SIL instructions, const-evaluate their conditions, and emit errors if
the conditions are non-constant or false.
This commit implements parsing, typechecking and SILGen for `#assert`.
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.
Currently, the check for whether to serialize parseable interface
arguments doesn't handle the case where a supplementary output file map
is used, preferring only to check if the frontend is passed
`-emit*interface`. Instead, check if the frontend inputs and outputs
contains a parseable interface, and use that to determine if we need to
save args.
This also puts `-module-link-name` in the parseable interface arg list.
Rather than limiting this to protocols, allow any nominal type.
Rename -enable-operator-designated-protocols to
-enable-operator-designated-types to reflect the change.
The YAML format is the same one produced by the -dump-type-info
frontend mode.
For now this is only enabled if the -read-type-info-path frontend
flag is specified.
Progress on <rdar://problem/17528739>.
