This fixes ObjC class names for classes nested in scopes with opaque types. Without this, such classes would either hit an assertion failure, or in no-asserts compilers they would get an empty string as a class name.
rdar://178851613
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.
**Overview**:
This PR introduces the basic infrastructure needed to eventually migrate
derived macros generation from hand-crafted AST nodes to macros. No
conformance have been migrated yet.
**Motivation**:
Derived conformances (e.g. `Equatable`, `Hashable`, `Codable`, ...) are
currently implemented as a special case in the compiler, producing
synthetic AST nodes directly. Migrating this to macros will hopefully
unify the code path with the existing macro expansion infrastructure,
make conformance synthesis easier to extend and test as well as reducing
the amount of special cases in the compiler.
**Changes**:
- New experimental feature flag `DeriveConformancesViaMacros`:
Introduces the flag that will eventually gate the new derived
conformance code paths. It does not control any behaviour for the moment
as none have been migrated yet but this enables future changes to be
built incrementally.
- New GeneratedSourceInfo and SourceFile kinds `SyntheticMacro`:
Introduces new GSI and SourceFile kinds named `SyntheticMacro` to
represent macros synthesized by the compiler. Since macros need a real
buffer to expand, this is the kind of source file and GSI associated
with those buffers.
- Conformance derivation via macros API:
Introduces the `deriveRequirementViaMacro` function that produces the
required witness via macro expansion.
See https://github.com/swiftlang/llvm-project/pull/13124 for
llvm-related changes.
**Next steps**:
- Macros do not contain any semantic information, especially regarding
types. Therefore it is necessary to provide them with type information
as an argument so they can eventually derive the conformances. A
separate PR is being created to generate this type information as
strings containing swift-parsable code for easy parsing on the macro
end.
- Implement derived conformance synthesis for individual protocols using
the new infrastructure, like `Equatable` or `Hashable` for starters.
- Wire the experimental flag to gate the new path once an implementation
exists
---------
Co-authored-by: Hamish Knight <hamish_knight@apple.com>
Without this, USR/DWARF mangling encodes inverse constraints that the
runtime mangler drops, so swift-api-digester reports a spurious "mangled
name changing" ABI break for any decl that adopts @_preInverseGenerics
alongside ~Copyable/~Escapable
Partially fixing rdar://176404397.
@_preInverseGenerics(except: <inverses>) is an extension of the existing
@_preInverseGenerics attribute that provides selective control over which
inverse requirements are mangled into a declaration's symbol name.
While the bare @_preInverseGenerics strips all inverse constraints
(~Copyable and ~Escapable) from mangling, the 'except:' form allows specific
inverses to be retained. This is needed when a type like Span already had
~Copyable mangled into its ABI-stable symbols and now needs to retroactively
adopt ~Escapable without changing those existing symbols. You can now express
that with `@_preInverseGenerics(except: ~Copyable)` to strip-out every inverse
except ~Copyable to preserve the pre-existing ~Copyable-containing symbols.
It requires the new experimental feature `PreInverseGenericsExcept`.
rdar://176395527
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
}
```
These will be used internally by the type checker to represent bindings
that are the joins and meets of types involving type variables. They
will not appear anywhere outside of the bindings code---so you won't
see them in expressions, or matchTypes(), etc.
Given that we implicitly expanded Copyable & Escapable
conformance requirements for suppressed primary associated
types, we now need this function to do the opposite;
filtering Copyable & Escapable requirements on such primary
associated types and adding inverses if those requirements
are missing.
This function plays a crucial role in emitting the interface
files accurately for functions and types, in addition to
how we mangle generic signatures into function symbols.
The mangling for generic signatures under the -WithDefaults version of
suppressed associated types goes like this:
- primary associated type T.A has an inverse `Rj` or `RJ` mangled
into the generic signature if it lacks the conformance, or
nothing is mangled into it.
- non-primary associated type T.B has either a `T.B: Copyable`
requirement mangled into it, or nothing is mangled into it.
For the legacy SuppressedAssociatedTypes feature, where there's no
defaults, it uses the "non-primary assocated type" mangling strategy
for all generic signatures.
This avoids coalescing checked and unchecked handlers with the same types, which results in runtime crashes as they are not compatible.
We have a separate mangling for predefined handlers, TZ, which is unused. Repurpose this for checked handlers. Unchecked handlers keep their existing mangling with Tz.
rdar://152263818
This is a follow-up to https://github.com/swiftlang/swift/pull/86557
When mangling a `@preconcurrency` declaration, `dropGlobalActor`
is set to `true`, and the original condition behind that used to
remove isolation from function types regardless of whether the
function type was actually global-actor isolated or not. We need
to maintain this behavior for mangling or risk breaking ABI for
the existing declarations that had isolation like `@isolated(any)`.
We turn off the AllowMarkerProtocols mangler flag when
mangling the types that are passed into the runtime demangler.
The logic in appendAnyProtocolConformance() was wrong when
this flag was set; we would early exit from this function,
but then appendRetroactiveConformances() would still call
appendListSeparator(). The would result in an invalid mangled
string which could not be parsed by the demangler.
In particular, this meant that the recent changes to generalize
Equatable to allow non-Copyable and non-Escapable conformers
could introduce runtime crashes, because a mangled string for
a retroactive conformance to Equatable could be incorrect.
The fix is to handle AllowMarkerProtocols further up in
forEachConditionalConformance().
Note that this change should not directly change ABI, because
AllowMarkerProtocols is on for symbol names.
When AllowMarkerProtocols is on, we still always mangle
conformances to Copyable and Escapable in this code path.
This means that even with this change, mangling a symbol name
that contains a retroactive conformance to Equatable can output
a different string than in Swift 6.3, which means we have an ABI
break. That problem requires a separate fix.
- Fixes rdar://problem/168023786.
This updates a large number of internal symbols, function names,
and types to match the final approved terminology. Matching the
surface language terminology and the compiler internals should
make the code easier for people to understand into the future.
Canonical ProtocolCompositionTypes never nest; we flatten the structure
when computing a canonical type.
However, in DWARF mangling, we might encounter ProtocolCompositionTypes
that contain other ProtocolCompositionTypes, via TypeAliasType sugar.
Make sure to visit this nested structure instead of just ignoring it.
- Fixes https://github.com/swiftlang/swift/issues/86207.
This was always set to `true` except for USR mangling, where we already
have it set to `false` for IDE USRs. The other clients were:
- AutoDiff, which is just using the resulting string as a dictionary
key, so don't seem to have any preference.
- The ClangImporter, which always overrides `@_originallyDefinedIn`
anyway.
Rather than setting the USR-specific bits for each USR entrypoint
into the mangler just expose a convenience constructor for USR
generation that sets them.
This is currently not wired up to anything. I am going to wire it up in
subsequent commits.
The reason why we are introducing this new Builtin type is to represent that we
are going to start stealing bits from the protocol witness table pointer of the
Optional<any Actor> that this type is bitwise compatible with. The type will
ensure that this value is only used in places where we know that it will be
properly masked out giving us certainty that this value will not be used in any
manner without it first being bit cleared and transformed back to Optional<any
Actor>.
Remove the DeclContext parameter from ResolveMacroRequest, we can now
retrieve the DeclContext either from the CustomAttr or macro expansion
expr/decl directly.
ResultConvention::Guaranteed will be used by borrow accessors when the storage type can be returned by value.
ResultConvention::GuaranteedAddress will be used by mutate accessors and borrow accessors when the storage type
cannot be returned by value.
Resolves rdar://152598492
Consider the following Swift, adapted from a real-world framework:
```swift
@available(macOS 10.8, *)
@_originallyDefinedIn(module: "another", macOS 11.0)
public struct SimpleStruct {}
@available(macOS 12.0, iOS 13.0, *)
public extension SimpleStruct {
struct InnerStruct {}
}
```
In this scenario, `SimpleStruct` was originally in a module called
`another`, but was migrated to this module around the time of macOS
11.0. Since then, the module was ported to iOS and gained a nested type
`SimpleStruct.InnerStruct`. When mangling USRs for this nested type, the
result differs depending on whether we're targeting macOS or iOS.
They're mostly the same, but the macOS build yields a USR with an `AAE`
infix, designating that the `InnerStruct` was defined in an extension
from a module with the name of the base module. On iOS, this infix does
not exist.
The reason this is happening is because of the implementation of
`getAlternateModuleName` checking the availability spec in the
`@_originallyDefinedIn` attribute against the currently active target.
If the target matches the spec, then the alternate module name is
reported, otherwise the real module name is. Since the iOS build reports
the real module name, the mangling code doesn't bother including the
extension-context infix, instead just opting to include the parent
type's name and moving on.
This PR routes around this issue by passing the
`RespectOriginallyDefinedIn` variable to the
`ExtensionDecl::isInSameDefiningModule` method, and using that to skip
the alternate module name entirely. It also sets
`RespectOriginallyDefinedIn` to `false` in more places when mangling
USRs, but i'm not 100% confident that it was all necessary. The goal was
to make USRs more consistent across platforms, regardless of the
surrounding context.
We sometimes mangle SILFunctionTypes when generating debug info
for reabstraction thunks, and these can have various exotic
parameter and result attributes. Two recent additions were
never plumbed through the mangler, causing assertion failures
when emitting debug info.
Fixes rdar://153730847.