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
When compiling SwiftOnoneSupport, issue errors for missing functions which are expected in the module.
This ensures ABI compatibility.
rdar://problem/48924409
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.
...and remove the option. This is ~technically~ CLI-breaking because
Swift 5 shipped this as a hidden driver option, but it wouldn't have
/done/ anything in Swift 5, so I think it's okay to remove.
Note that if a parseable interface (.swiftinterface) and a binary
interface (.swiftmodule) are both present, the binary one will still
be preferred. This just /allows/ parseable interfaces to be used.
rdar://problem/36885834
By default, we compile the standard library with
`-enforce-exclusivity=unchecked`. If we don't preserve this argument,
then the standard library compiled from an interface includes
exclusivity enforcement, which pessimizes inlining those functions,
which decreases performance for clients.
Part of rdar://46431767
