Changed the frontend flag to -enable-experimental-lexical-lifetimes from
-enable-experimental-defined-lifetimes.
Changed the attribute on begin_borrow from [defined] to [lexical].
- Virtual calls are done via a @llvm.type.checked.load instrinsic call with a type identifier
- Type identifier of a vfunc is the base method's mangling
- Type descriptors and class metadata get !type markers that list offsets and type identifiers of all vfuncs
- The -enable-llvm-vfe frontend flag enables VFE
- Two added tests verify the behavior on IR and by executing a program
Serialize the canonical name of the SDK used when building a swiftmodule
file and use it to ensure that the swiftmodule file is loaded only with
the same SDK. The SDK name must be passed down from the frontend.
This will report unsupported configurations like:
- Installing roots between incompatible SDKs without deleting the
swiftmodule files.
- Having multiple targets in the same project using different SDKs.
- Loading a swiftmodule created with a newer SDK (and stdlib) with an
older SDK.
All of these lead to hard to investigate deserialization failures and
this change should detect them early, before reaching a deserialization
failure.
rdar://78048939
Remove the option that explicitly enables concurrency back-deployment,
and instead always enable its support in the compiler. Remove the use
of the extraneous CMake option as well.
Add a frontend-only flag `-enable-experimental-back-deploy-concurrency`
to be used to stage in the back deployment of concurrency. At present,
all it does is lower the availability minimums for use of concurrency
features.
We have implemented a libSwiftDriver-based tool to generate prebuilt module cache for
entire SDKs. Anchored on the same infrastructure, we could also generate ABI baselines
for entire SDKs.
In a back deployment scenario, this will provide a place where one could provide
function implementations that are not available in the relevant stdlib.
This is just setting up for future work and isn't doing anything interesting
beyond wiring it up/making sure that it is wired up correctly with tests.
This hidden frontend option lets us be more lax
when type-checking in the presence of editor
placeholders by treating them as holes during
constraint solving.
Rework Sendable checking to be completely based on "missing"
conformances, so that we can individually diagnose missing Sendable
conformances based on both the module in which the conformance check
happened as well as where the type was declared. The basic rules here
are to only diagnose if either the module where the non-Sendable type
was declared or the module where it was checked was compiled with a
mode that consistently diagnoses `Sendable`, either by virtue of
being Swift 6 or because `-warn-concurrency` was provided on the
command line. And have that diagnostic be an error in Swift 6 or
warning in Swift 5.x.
There is much tuning to be done here.
* Rename --enable-experimental-opaque-return-types and gate structural opaque types with a flag
* Separate out structural opaque type result builder tests
Hopefully I won't regret this later. This is needed to ensure that clients
of _Differentiation.swiftinterface don't fall over while building a module
from the interface.
In a back deployment scenario, this will provide a place where one could provide
function implementations that are not available in the relevant stdlib.
This is just setting up for future work and isn't doing anything interesting
beyond wiring it up/making sure that it is wired up correctly with tests.
SourceKit invokes the legacy driver. Providing this flag in the IDE
means the command lines SourceKit forms to run semantic requests in the
editor are all invalid.
Teach the legacy driver to eat this flag.
rdar://80811565
This commit adds support for the -lto_library flag, allowing users to specify a custom LTO library on Darwin. This also fixes an issue where the default LTO library is used even if Driver is run from inside an alternate toolchain.
- If any of the `-g<kind>` flag is given -- except `-gnone`, debug
info will be printed into every generated SIL files.
- The `-gsil` is deprecated in favor of `-sil-based-debuginfo`. The
SILDebugInfoGenerator Pass now generates intermediate SIL file with
name "<output file>.sil_dbg_<n>.sil". Other functionalities of that
Pass remain the same.
In order to put constraints on opaque types in function returns, we want to
support naming them like 'func f() -> <T> T { }'. This commit parses that
syntax into the new `OpaqueReturnParameteriedTypeRepr`. This is hidden behind
the new flag --enable-experimental-opaque-return-types.
Foundation imports CoreFoundation with `@_implementationOnly`,
so CoreFoundation's modulemap won't be read, and the dependent libraries
of CoreFoundation will not be automatically linked when using static
linking.
For example, CoreFoundation depends on libicui18n and it's modulemap has
`link "icui18n"` statement. If Foundation imports CoreFoundation with
`@_implementationOnly` as a private dependency, the toolchain doesn't have
CoreFoundation's modulemap and Foundation's swiftmodule doesn't import
CoreFoundation. So the swiftc can't know that libicui18n is required.
This new option will add LINK_LIBRARY entry in swiftmodule to
specify dependent libraries (in the example case, Foundation's
swiftmodule should have LINK_LIBRARY entry of libicui18n)
See also: [Autolinking behavior of @_implementationOnly with static linking](https://forums.swift.org/t/autolinking-behavior-of-implementationonly-with-static-linking/44393)
There are two pieces here:
- A -warn-on-potentially-unavailable-enum-case flag is passed down by
the driver when *producing* a swiftinterface
- When *consuming* a swiftinterface, also enable this behavior
Part of rdar://problem/78306593.
Before this change, we always use the Swift target triple to instantiate the internal
Clang instance. When loading a Swift module from the textual interface, we may pick up
a lower target triple to use to build the Swift module because the target is hard-coded
in the textual interface file. This implies we may end up building multiple versions of the
same Clang module, one for each target triple of the loading Swift module.
This change adds a new frontend flag -clang-target to allow clients to specify a
consistent clang target to use across the Swift module boundaries. This value won't change
because it's not part of .swiftinterface files.
swift-driver should pass down -clang-target for each frontend invocation, and its value should be
identical to -target.
Related to: rdar://72480261
