This is more consistent than using a protocol type as the conforming type
with how the rest of the generics system operates. The special
DistributedActor-as-Actor conformance operates in the same way as well.
If the module named in `#if canImport(<Module>, _version: ...)` cannot be
found, it may indicate that the developer misspelled the module name. Emit a
warning to indicate that the directive evaluates to false. If it is intentional
that the module not be found, the developer can avoid the warning by first
checking whether the module can be imported and then check its version.
Resolves rdar://128367758.
`#if canImport(...)` conditions are evaluated by the parser's primary
`EvaluateIfConditionRequest`, which emits `cannot_find_module_version` and
records the result in `CanImportModuleVersions`. Several later analyses re-walk
the same directives and, before this change, routed through that same emitting
`canImportModule` path, duplicating the diagnostic: the
`ExportedSourceFile.configuredRegions` region-tree rebuild that backs
diagnostic-group control (which could also recurse indefinitely), and the
`VarDeclUsageChecker` inactive-code scans behind unused-variable diagnostics.
Introduce a `CanImportMode` on `CompilerBuildConfiguration` distinguishing the
canonical, diagnostic-emitting `.driving` query from a side-effect-free
`.analyzing` re-derivation. `.analyzing` routes to the new
`BridgedASTContext.testCanImport` -> `ASTContext::testImportModule` bridge,
which answers from the module loaders without emitting diagnostics or populating
`CanImportModuleVersions`; `.driving` keeps the existing `canImport` behavior.
The mode defaults to `.analyzing`, so only the canonical site
`evaluatePoundIfCondition` drives, while every secondary walk re-derives `#if`
activity without repeating the diagnostic.
When a struct has stored properties from an internal bridging header,
add @_hasHiddenStoredProperties to force address-only on both library
and client sides, and resolve layout via the defining module's
HiddenTypeLayouts table in IRGen.
Making these structs loadable is challenging because library and client
must agree on the register-passing scheme (which registers carry which
fields), and that scheme depends on the full type structure that the
client cannot see. Address-only sidesteps this by passing everything
indirectly.
Tests: hidden-type-irgen.swift verifies the Client's IR has correct
alloca sizes/alignments and outlined copy witnesses without referencing
hidden C symbols. hidden-type-runtime.swift builds a dylib + executable
and verifies values round-trip correctly across the boundary at runtime.
Give it a longer, more annoying name, because you're not supposed to
use it anymore. It's fundamentally broken. I've added FIXME comments
in the places where the result is known to be wrong.
The substitution is driven by a canonical type to mangled name table on ASTContext,
populated by exportability checking at the same site where the corresponding
diagnostics are suppressed. After this change, the module emitter and module
loader see hidden types differently: the emitter still sees the real types
defined in the bridging header, while the loader sees only a mangled name
wrapped in a HiddenType placeholder.
HiddenType is a new TypeBase subclass that carries a mangled name
without leaking the actual type definition. It serves as a type-slot
placeholder for stored-property types that have been elided from a
serialized binary module, so that the client side can either
(1) resolve this mangled name to the real type if the client has access to the owning module, or
(2) use the mangled name as a key to query abstract layout information also serialized in the binary module.
As an example — a library with a hidden field of a bridging-imported type:
```
// Utility.h (internal bridging header)
// typedef struct { int value; } Wrapper;
public struct S {
private var w: Wrapper
public var weight: Double
}
In the serialized module, the client's view reconstructs as:
public struct S {
private var w: @_hidden("$sSo7Wrappera")
public var weight: Double
}
```
Resolves the following warning:
```
ASTContext.cpp:5475:47: warning: first argument in call to 'memcpy' is a pointer to non-trivially copyable type 'swift::LifetimeDependenceInfo' [-Wnontrivial-memcall]
```
Fixes a regression from https://github.com/swiftlang/swift/pull/87217.
Opaque return types are special type declarations that have it
own nested generic signature. Thus, given this:
```
protocol P<A> { associatedtype A: ~Copyable }
func f<T: ~Copyable>() -> some P<T> {}
```
The generic signature for f is <T where T Escapable>, and
for the opaque return type, its nested signature ends up as
```
<X where X: P, X.A == T>
```
With SE-503, we will now also expand a default for the suppressed
primary associated type, so the signature after expansion becomes
```
<X where X: P, X.A == T, X.A: Copyable>
```
It would be smarter to effectively have this rule
```
X.A == T, T: ~Copyable
----------------------
X.A: ~Copyable
```
where we infer the inverse on X.A to cancel-out the
expanded default X.A: Copyable. We already do this for
two in-scope type parameters, and it would be better if
we did it if one side was out-of-scope, but that would
be source-breaking to do in general.
In the case of opaque return types, the fact that
it has a nested generic signature seems more an
artifact of the implementation. There also is little
risk of source break, as the only kinds of same-type
requirements that can appear are from parameterized
protocol type.
The experimental suppressed associated types prior to
SE-503 wouldn't be broken by this change, as they do
not infer defaults that need suppression, and we only
filter-out requirements from defaults expansion, rather
than explicitly-written ones.
rdar://175500824
There's a need for more control over how default requirements
for conformance to Copyable/Escapable are expanded, and
subsequently how inverses are applied or inferred to cancel-out
those defaults.
The pattern of `/*applyInverses*/BOOL` is insufficient, so this
is a refactoring to grow that into a proper type that carries
an option that can be used in some future scenario about inferring
inverses for opaque return types.
Also, since the mock SDK's implementation of CGFloat is wrong,
update some existing tests to use the real SDK instead. This
exposed a few instances where the behavior was not as intended;
I added FIXME comments explaining what's going on.
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
Loosen availability checking to allow references to a decl that is unavailable
in a broader platform context in contexts which are unavailable in a more
specific platform context. For example, `@available(macOS, unavailable)` decls
should be allowed in `@available(macOSApplicationExtension, unavailable)`
contexts. This enhancement, which has always been desirable but wasn't high
priority, became more important with the introduction of `anyAppleOS`. Some
library authors may replace platform-specific availability annotations with
`anyAppleOS` availability and without this behavior change those attribute
updates would be source breaking.
Test updates assisted by claude.
Currently only the top level dependencies get serialized in Swift modules. In
practice this is not enough information to fully replay a module import
sequence, especially when the dependencies include binary SDK modules that were
built elsewhere. In this case we cannot follow the links to its depenencies,
since they refer to paths on a different machine or unavailable CAS. During an
EBM build, the dependency scanner writes the complete list of dependencies into
a json file called the explicit Swift module map -- including the local
locations of the dependencies of binary SDK modules. Using this LLDB can replay
a module import with 100% accuracy.
rdar://170514919
ForEach support for Borrowing sequence
For testing purposes, this commit includes _BorrowingSequence and _BorrowingIterator protocols, with conformance for Span and InlineArray.
Partially revert https://github.com/swiftlang/swift/pull/86309. Keep the
SDKInfo parsing in the ASTContext separately from the search path
configuration. This allows the availablity checking to load SDKSettings
from the correct VFS.
rdar://169886913
Before this patch it was easy to try to work with the types in a SILBoxType by
accessing the layout of the SILBoxType... especially if one was working with
mutability since there wasn't any comment/APIs on SILBoxType that pointed one at
the appropriate API on SILType.
To make this easier to use and self document, I added some new helper APIs onto
SILBoxType that:
1. Let one grab the fields without touching the layout. The layout is an
internal detail of SILBoxType that shouldn't be touched unless it is necessary.
2. Get a specific properly specialized SILType of a SILType for a given
SILFunction.
3. Access the number of SILFIelds and also whether or not a specific SILField is
mutable.
4. Yields a transform range that transform the SILFields in the SILBoxType into
a range of properly specialized SILTypes.
This should prevent these sorts of mistakes from happening in the future.
This is properly prepared for multiple field boxes since we take in an
initializer_list of fields/mutability changes.
Given that I made this change to SILBoxType, I aligned the same API on SILLayout
to also take an initializer_list of fields/mutability changes instead of just
assuming a single field layout.
Fix a corner case when following conditions are met in a single module:
* Module A is imported in the current module
* There exists a versioned `canImport` check for a module A
* All `canImport` check within the module evaluated to false
If all above conditions are met, swift-frontend will not received the
version number from scanner, and it will be confused if version is
either not available (thus a warning, and treat as true), or condition
is not met (eval to false).
Now make sure if when scanner tries to resolve `canImport`, it will
record all instances that a module can be imported, or a version of the
module is found.
rdar://167784812
Some Darwin platforms like DriverKit use a system prefix on all of their search paths. Even though DriverKit isn't supported, add support to get the system prefix from SDKSettings when constructing the default search paths.
This requires the DarwinSDKInfo to be gotten earlier in CompilerInvocation, pass that down to ASTContext through CompilerInstance.
-platform-availability-inheritance-map-path is no longer needed to support visionOS in tests, remove that and its supporting code that gets an alternative DarwinSDKInfo.
rdar://166277280
Preserving sugar if we have type variables uses way too much memory.
Canonicalize these substitution maps for now, as a (temporary?) workaround.
In the future, if we decide preserving sugar is more important than a
few dozen Mb of memory usage, we can also bump the arena memory limit,
instead.
Fixes rdar://166237860.
Fixes rdar://165863647.
Store the original VarDecl in the same map we use for tracking the
original wrapper var for property wrappers. This will allow us to
use the same logic to determine the original var for both.
We need to serialize the underlying type substitution map for an
inlinable function. However, there is no reason to deserialize it
eagerly, since doing so can lead to cycles. It is better for
correctness and performance to only deserialize it when needed.
Technically this fixes a regression from #84299, but the actual
problem was there all along, it was just exposed by my change
on a specific project.
Fixes rdar://163301203.
Builtin.FixedArray was introduced as the first generic builtin type, with
special case handling in all the various recursive visitors. Introduce
a base class, and move the handling to that base class, so it is easier
to introduce other generic builtins in the future.
Slava Pestov
Allan Shortlidge
Artem Chikin
Xi Ge
Kavon Farvardin
Pavel Yaskevich
Steven Wu
Hamish Knight
Adrian Prantl
susmonteiro
elsa
Elsa Keirouz
Anthony Latsis
Joe Groff
Michael Gottesman
Ian Anderson
Becca Royal-Gordon