We use one bit of the third reserved swift private tls key.
Also move the functionality into a separate static archive that is
always linked dependent on deployment target.
Add the command line option -require-explicit-availability to detect public
or `@usableFromInline` declarations and warn if they don't declare
an introduction OS version. This option should catch forgotten `@available`
attributes in frameworks where all services are expected to be introduced
by an OS version.
The option -require-explicit-availability-target "macOS 10.14, iOS 12.0"
can be specified for the compiler to suggest fix-its with the missing
attributes `@available(macOS 10.14, iOS 12.0, *)`.
rdar://51001662
There are still cases (a module with a type that's the same name as the
module) where we cannot fully qualify all types. In those cases, allow
them to remain unqualified with a flag, `-Xfrontend
-preserve-types-as-written-in-module-interface`.
Many build systems that support Swift don't use swiftc to drive the linker. To make things
easier for these build systems, also use autolinking to pull in the needed compatibility
libraries. This is less ideal than letting the driver add it at link time, since individual
compile jobs don't know whether they're building an executable or not. Introduce a
`-disable-autolink-runtime-compatibility` flag, which build systems that do drive the linker
with swiftc can pass to avoid autolinking.
rdar://problem/50057445
@_dynamicReplacement(for: selfRec(x: acc:))
func selfRec_r(x: Int, acc: Int) -> Int {
if x <= 0 {
return acc
}
// Normally, this will call selfRec(x: acc:)'s implementation.
// With the option, this will call to selfRec_r(x: acc:).
return selfRec(x: x - 1, acc: acc + 1)
}
rdar://51229650
This option no longer works but was still in the option file and help
message.
Add a temporary pass-specific option instead for debugging until this
pass has been sufficiently tested yet.
On Windows, there are multiple variants of the C runtime that must be
explicitly specified and consistently used from the runtime to the
application. The new `-libc` option allows us to control the linking
phase by correctly embedding the requested library to be linked. It is
made into a required parameter on Windows and will add in the
appropriate flags for the imported C headers as well. This ensures that
the C library is not incorrectly linked.
Otherwise the overlays won't be force-loaded when you import them.
(This feature could possibly be scoped back at this point, but it's
not something that should be changed just by using module interfaces!)
This allows us to mark this flag as DoesNotAffectIncrementalBuild, so
that switching between a tty and non-tty doesn't cause full rebuilds
with swiftpm.
https://bugs.swift.org/browse/SR-7982
I am going to use this to ensure some end-to-end tests that do not inline from
the stdlib will work after flipping the switch and stripping ownership after
serialization.
Leave the old flag in as an alias to the new flag, for transition
purposes. Also go ahead and remove the long-deprecated and unused
`emit-interface-path`.
Part of rdar://49359734
module imports. This is useful when building redistributable static
archives, since any pointers into the CLang module cache won't be
portable.
When using this option the Clang type fallback path in LLDB will be
less useful since DWARF type information from those modules will not
be available unless another object file compiled without the option
imported the same modules.
rdar://problem/48827784
In LLDB expressions, references to private metadata accessors may be
emitted and need to be bound to symbols available in the attached
program, even if these symbols are only supposed to have private
visibility within the program.
Also rdar://problem/48018240
