The module name changes the symbol mangling, and also causes
TBDGen to emit linker directives. To separate out these two
behaviors, introduce a terrible hack. If the module name
contains a semicolon (`;`), the part before the semicolon
is the module name for mangling, and the part after the
semicolon is the module name for linker directives.
If there is no semicolon, both module names are identical,
and the behavior is the same as before.
Expand the special-cased ASTWalker behavior for folded SequenceExprs
such that we always walk the folded expression when available. This
ensures that we don't attempt to add the same node multiple times
when expanding ASTScopes during pre-checking.
rdar://147751795
The builtin’s current is signature is:
```
(Any.Type, Any.Type) -> Bool
```
This needs to be changed to this:
```
(any (~Copyable & ~Escapable).Type, any (~Copyable & ~Escapable).Type) -> Bool
```
This requires a bit of support work in AST synthesis.
rdar://145707064
Co-authored-by: Alejandro Alonso <alejandro_alonso@apple.com>
An "abstract" ProtocolConformanceRef is a conformance of a type
parameter or archetype to a given protocol. Previously, we would only
store the protocol requirement itself---but not track the actual
conforming type, requiring clients of ProtocolConformanceRef to keep
track of this information separately.
Record the conforming type as part of an abstract ProtocolConformanceRef,
so that clients will be able to recover it later. This is handled by a uniqued
AbstractConformance structure, so that ProtocolConformanceRef itself stays one
pointer.
There remain a small number of places where we create an abstract
ProtocolConformanceRef with a null type. We'll want to chip away at
those and establish some stronger invariants on the abstract conformance
in the future.
Preserve conditionallyAddressableParamIndices independent of any
addressableParamIndices. The conditional dependencies are subject to change
based on type substitution.
* [CS] Decline to handle InlineArray in shrink
Previously we would try the contextual type `(<int>, <element>)`,
which is wrong. Given we want to eliminate shrink, let's just bail.
* [Sema] Sink `ValueMatchVisitor` into `applyUnboundGenericArguments`
Make sure it's called for sugar code paths too. Also let's just always
run it since it should be a pretty cheap check.
* [Sema] Diagnose passing integer to non-integer type parameter
This was previously missed, though would have been diagnosed later
as a requirement failure.
* [Parse] Split up `canParseType`
While here, address the FIXME in `canParseTypeSimpleOrComposition`
and only check to see if we can parse a type-simple, including
`each`, `some`, and `any` for better recovery.
* Introduce type sugar for InlineArray
Parse e.g `[3 x Int]` as type sugar for InlineArray. Gated behind
an experimental feature flag for now.
Make sure the traversal order for classMembers in deterministic in the
mdoule by sorting them first.
Also fix the comparsion function for `DeclName` to make sure there
aren't two DeclNames with different OpaquePointer can be evaluated to
equal.
rdar://147513165
Introduce the experimental feature InferIsolatedConformances to align
with the upcoming feature proposed in SE-0470. This is a slight
generalization of the main-actor-specific inference that was already
in place for the default-main-actor mode from SE-0466. Note that, as
specified in SE-0470, InferIsolatedConformances is implied by the
default-main-actor mode.
https://github.com/swiftlang/swift/pull/79807 caused a regression in which
`AvailabilityContext` stopped tracking the available version range for the
active platform domain for certain platforms. Fix this by reverting to checking
`AvailabilityDomain::isActive()` to determine when a given platform
`AvailabilityDomain` represents the target platform. The compiler's existing
mapping from target triple to platform domain is incomplete and it's not clear
to me whether fixing that could cause other regressions.
Resolves rdar://147413616.
This fixes a compiler bug that got exposed by f11abac652.
If a C++ type is declared in a nested Clang submodule, Swift was emitting errors that look like:
```
Type alias 'string' is not available due to missing import of defining module 'fwd’
```
rdar://146899125
This was fix was accidentally not include in the previous commit,
which breaks older .swiftinterface files without it:
commit 75ba7a845c
Merge: befc15e6dfd41c4d4cc9
Author: Andrew Trick <atrick@apple.com>
Date: Wed Mar 19 18:22:35 2025
Merge pull request #80064 from atrick/lifetime-inference
LifetimeDependence: implement strict type checking
Rework the type checker to support completely checking lifetime dependence
requirements. Don't let anything through without the feature being enabled and
complete annotation or inference.
First, prevent lifetime dependencies from sneaking into source that does not
enable LifetimeDependence. This is essential for controlling the scope of the
feature.
Fixing this is disruptive because, ever since `~Escapable` was introduced we
have been declaring empty non-Escapable types without enabling
LifetimeDependence. Such as:
struct Implicit_Init_Nonescapable : ~Escapable {}
Fixes: rdar://145979187 ([nonescapable] diagnose implicit non-Escapable
initializers as an error unless LifetimeDependence is enabled)
Various forms of unsupported 'inout' dependencies are now also caught by the
type checker.
Second, disable lifetime dependency inferrence except in unambiguous cases and
some implicitly generated cases.
Fixes: rdar://131176898 ([nonescapable] missing diagnostic for incorrectly inferred inherited dependence)
This is important to avoid source compatibility problems as inference rules
change. They will change as the proposal goes through review.
This fixes various latent missing dependency bugs.
Disable experimental lifetime dependence inference. Unambiguous lifetime
dependency candidates will still be inferred by default, without any frontend
options. Ambiguous candidates will, however, no longer be inferred unless
-Xfrontend -enable_experimental_lifetime_dependence_inference is enabled.
This all has to be done without breaking existing .swiftinterface files. So
backward compatibility logic is maintained.
Examples of inference rules that are no longer enabled by default:
1. do not infer a dependency on non-Escapable 'self' for methods with more than
zero parameters:
extension NE: ~Escapable {
/*@lifetime(self)*/ // ERROR: 'self' not inferred
func method<Arg>(arg: Arg) -> NE { ... }
}
2. Never infer a 'copy' dependency kind for explicit functions
extension NE: ~Escapable {
@lifetime(self) // ERROR: 'copy' not inferred
func method() -> NE { ... }
@lifetime(self) // ERROR: 'copy' not inferred
var property : NE { /*@lifetime(self: newValue)*/ set { ... } }
}
