Conformance checking in swiftinterfaces is lenient and can recover from missing
witnesses by assuming that the protocol witness table will have an entry for
the requirement at runtime. As a result, diagnosing missing imports for
witnesses here could break source compatibility for existing interface files
and must be skipped. This fixes a regression introduced by
https://github.com/swiftlang/swift/pull/88470.
Resolves rdar://175215763.
Makes it possible for users of `-warnings-as-errors` to control the behavior of
warnings about the obsoletion of module interface emission options.
Resolves rdar://174787052.
The `@export(interface)` and `@export(implementation)` attributes
SE-0497 are queried directly on AST nodes in several places within the
SIL pipeline. However, they don't persist when SIL functions are
serialized, meaning that clients of the original module might make
different assumptions about the availability of a given function's
definition.
Represent these attributes in a SIL function (as an optional
CodeGenerationModel), (de-)serialize them into the module, and add a
textual representation as SIL function attributes `[export_interface]`
and `[export_implementation]`.
Back in January, I updated the swiftinterface _reading_ code to accept either
`read`/`modify` or `yielding borrow`/`yielding mutate`. That update has been
around for long enough that we can now switch over the swiftinterface _writing_
code to emit the standard final `yielding borrow`/`yielding mutate` spellings.
Interface files written with the old spellings will continue to be
accepted for some time (likely a year or more).
The only known condfail scenario is inheriting from
a protocol P that inherits from a reparentable one R.
We already guard P if it mentions R in its inheritance clause.
So older compilers will simply report that "P" is missing in the
interface, which is a better error message than virally guarding
everything mentioning P. It's an ABI break anyway to do that
without introducing a `@reparented` extension, which needs a guard.
In theory, older compilers shouldn't have too much go wrong if they
were to ignore `@reparentable`, though the RequirementMachine and
witness tables will look different.
rdar://174263176
As a follow up to https://github.com/swiftlang/swift/pull/87832, continue
adjusting the algorithm for computing synthesized conformance availability.
When an outer declaration is `unavailable` in a more specific platform domain
and the inner declaration is `introduced:` in a less specific domain, the inner
declaration attribute does not override the outer declaration attribute.
Unavailability and introduction on separate axes of availability.
Resolves rdar://173724423.
The compiler synthesizes an `unownedExecutor` property for every `actor` type.
It was also synthesizing availability attributes for this property by
intersecting the availability of the actor type and the `UnownedExecutor` type.
This may have been necessary early in the development of Swift Concurrency but
now it amounts to little more than a convoluted procedure that must result in
repeating the availability of the actor on one of its properties (the property
can never be less available than the actor itself).
When printing `.swiftinterface` files, implicit conformances may need to be
printed with inferred availability attributes. The existing algorithm for
determining which availability attributes to print needed a few updates to
better handle `anyAppleOS` availability attributes:
- `@available(anyAppleOS, ...)` attributes attached to a nested declaration
should take priority over platform-specific `@available` attributes on outer
declarations.
- At the same time, `@available(anyAppleOS, ...)` attributes attached to the
_same_ declaration as a platform-specific `@available` attribute should not
take priority. Instead, both attributes should be included in the inferred
set.
Default to use new swift-driver to run lit tests as legacy swift driver
is deprecated for a long time. The lit tests for legacy drivers are also
disable when running new swift-driver.
Tests that relies on legacy swift driver (for example, tests merge
module) can be enabled on conditions `legacy_swift_driver`. Fix and
split up some existing tests that relies on legacy driver.
This change fixes rdar://172417385 and #45125 by using transformRec
to set no escape, instead of casting which drops sugar. This affects
how interfaces are printed, and could theoretically cause issues with
printing private aliases into public interfaces. Motivated by needing
to be able to diagnose issues with attributes on aliases; without this
change, the alias sugar is sometimes lost.
Compute and propagate the library level (api/spi/ipi) of each module
dependency through the dependency scanner so that the compiler can
correctly enforce private module import diagnostics in CAS mode, where
path-based SPI detection fails because CAS abstracts file paths to
content IDs.
Swift modules:
- Detect library level from the module interface path using
libraryLevelFromPath() during scanning, for both textual (.swiftinterface)
and binary (.swiftmodule) Swift modules.
Clang modules:
- Expose ModuleMapIsPrivate from clang::Module in ModuleDeps via the
dependency scanning infrastructure.
- Set library level for clang modules in bridgeClangModuleDependency()
using ModuleMapIsPrivate (catches module.private.modulemap in any
SDK location) and libraryLevelFromPath() on the module map file
(catches modules under PrivateFrameworks directories).
The library level is:
- Stored in ModuleDependencyInfo and serialized in the module dependency
cache (format version bumped to v8).
- Exposed through the swiftscan C API via a new
swiftscan_module_info_get_library_level() function (API minor version
bumped to 3).
- Emitted in the dependency scanner JSON output as "libraryLevel" for
all module kinds (Swift textual, Swift binary, Clang, and main module).
- Parsed from the explicit module map JSON by ExplicitModuleMapParser
for both Swift (ExplicitSwiftModuleInputInfo) and Clang
(ExplicitClangModuleInputInfo) modules.
- Looked up in ModuleLibraryLevelRequest via
ASTContext::getExplicitModuleLibraryLevel(name, isClang), which
consults the appropriate map (Swift or Clang) based on module kind.
rdar://172693314
Assisted-By: Claude
The feature was added only to avoid a reverse-condfail
in the initial bring-up of noncopyable generics.
Nearly 2 years have passed since the last time I tried
to remove this old technical debt [1] and had to revert
it due to outdated build bots [2]. Hoping that won't be
a problem this time.
[1] 5b2f2cbfcf
[2] https://github.com/swiftlang/swift/pull/75267
resolves rdar://131560183
We need to start moving people over to using the version of
suppressed associated types that has the officially accepted
behavior according to SE-503, and that is via
`SuppressedAssociatedTypesWithDefaults`.
To allow for time to migrate to the new version, I'm introducing
the deprecation message as a warning for now.
This set of changes also moves most of the test suite over to using
the officially accepted version.
rdar://172231663
Previously, the `@_accessorBlock` disambiguation attribute was only
emitted for observed variables. But We need `@_accessorBlock`
disambiguation marker for simple stored properties with non-public
setters in `@frozen` types too.
rdar://171819084
Adjust the algorithm that collects the availability attributes for synthesized
conformances to ensure it skips attributes from parent declarations that are
superceded by attributes in nested declarations, even when the domains of those
attributes do not match exactly.
In some cases, it's useful to allow an availability macro to expand to an empty
availability specification list. Allow developers to express this using macros
that are defined to exactly the string `*`, while continuing to reject `*` in
availability macros that contain other entries.
When gathering availability attributes to print in a .swiftinterface for
synthesized conformances to inherited protocols, don't assume availabilty
attributes always have a platform kind.
Resolves rdar://170361240.
If a .swiftinterface file does not include an explicit `-language-mode` option
(or its predecessor `-swift-version`) and needs to be built as a dependency of a
client compilation, then the invocation to build the module from interface
would end up inheriting the language mode that the client code is built with.
This can result in spurious type checking diagnostics or even mis-compilation.
To ensure that a module interface is always built using the language mode that
its source code was originally built with, require an explicit `-language-mode`
option when emitting swiftinterface files.
In #84307 this diagnostic was downgraded to a warning. The failures it caused
in PR testing should now be resolved.
This is a re-attempt of https://github.com/swiftlang/swift/pull/84327.
Resolves rdar://145168219.
Skip printing inherited constructors defined in modules that are not
publicly imported.
This prevents interface verification errors where types are used but
their modules aren't in the import list.
rdar://168101765
As specified in SE-0441, -language-mode should appear in help output
while -swift-version should be the hidden alias.
Related to swiftlang/swift-driver#1894
Non-Escapable 'inout' arguments have a default self-dependency, regardless of
any other annotations. For example:
@_lifetime(dest: copy source)
/* DEFAULT: @_lifetime(dest: copy dest, copy source) */
func foo<T: ~Escapable>(dest: inout T, source: T)
An immortal lifetime specifier now suppresses that default. For example:
@_lifetime(dest: immortal, copy source)
/* DEFAULT: @_lifetime(dest: copy source) */
func foo<T: ~Escapable>(dest: inout T, source: T)
This is necessary because there is otherwise no other way to suppress the
default lifetime.
Fixes rdar://170016708 ([nonescapable] Support @_lifetime(immortal) to suppress
the usual inout default self-dependency)
Qualification has discovered a complicated test case where the module interface printer incorrectly adds module selectors to nested types that don’t support them. Tweak module interface printing to omit the module selector in more situations.
Fixes rdar://169720990.
In #86859, I modified the way `export_as` names are used in private module interfaces so that the `export_as` name is used when that module has been imported. This turns out to be slightly too aggressive in a specific scenario where a submodule of the export_as module imports a submodule of the real module—the compiler ends up using the export name even though the resulting lookup won’t actually work.
Modify the logic for deciding whether to use an exported module name so that it not only checks whether the export_as module has been loaded, but also whether the specific module or submodule the declaration belongs to is (possibly transitively) imported by that module.
Fixes rdar://167874630 (harder).
Allan Shortlidge
Tim Kientzle
Doug Gregor
Saleem Abdulrasool
Kavon Farvardin
Meghana Gupta
Meghana Gupta
Steven Wu
Pavel Yaskevich
Aviva Ruben
Rintaro Ishizaki
Sam Pyankov
Ryan Mansfield
Becca Royal-Gordon
Aidan Hall
Aidan Hall
Andrew Trick
Pavel Yaskevich
Anthony Latsis