This change forces you to write ``@reparented` relationships
on an extension of a protocol, rather than on the protocol
itself.
The ProtocolConformance needs to be associated with some
GenericContext and IRGen expects it to be an ExtensionDecl.
That environment defines under what conditions the conformance
exists. We also need to define witnesses for the new parent's
requirements in an extension anyway, so it's a natural fit.
The previous workaround for this was kind of awful, as it'd
require searching all the protocol's extensions and "guess"
which extension they want to represent the conformance. While
we could try to synthesize an extension, there's two
challenges there:
1. Due to SuppressedAssociatedTypes, it's not so simple to
synthesize an unconstrained ExtensionDecl.
2. We currently rely on same-type requirements to pin the
associated types to particular witnesses of those requirements
in the extension. So it's not purely unconstrained! For example,
```
extension Seq: @reparented BorrowSeq where Iter == MyIter {}
```
The constraints that are disallowed (but not yet diagnosed)
are conditional conformance requirements, as the default
conformance for a reparenting cannot depend on those.
Thus, it's better that programmers to specify the extension.
For reparenting, we rely on a default associated conformance witness accessor
to build the witness table for 'Self: NewParent' at runtime. This means that
when mangling the symbol for such a descriptor, we need support for there
being no associated type at all; it's just tau_0_0 aka Self as the subject.
This patch extends _default_ associated conformance witness accessor mangling
to support a GenericTypeParamType for the subject, as the non-default accessors
already quietly did have support; see `mangleAssociatedConformanceDescriptor`.
It was quiet in the sense that there was no demangling support for it, nor
documentation about it either. So I've brought both kinds of witness accessor
manglings up-to-par, without extending the `assoc-type-name` grammar itself.
Remove the SwiftCore_ENABLE_DIRECT_RETAIN_RELEASE option and the corresponding option from the various subprojects. Instead, unconditionally find_package(SwiftSwiftDirectRuntime) but without REQUIRED. We expect that if the compiler is emitting DirectRuntime calls, the library will be available, so there's no need to configure that separately.
Also refine the check for HasSwiftSwiftDirectRuntimeLibrary to exclude DriverKit.
Just like in async functions, coroutines will go through the CoroSplit
flow. As such, variables in O0 need to go through the same treatment
they undergo for async functions: an `asm` directive is emitted so to
create a use of the variable after each split point.
Exit code should not inherit the location of the previous basic block;
instead, it should contain line zero to denote that this is not
associated with any user code.
Without this patch, stepping over code code like:
```
1. yielding mutate {
2. yield &member_int
3. blah
4. blah
}
```
Would go from line 3, to line 4, to line 2.
rdar://149106144
These comments were verbose and too personal, making it hard to
understand the point being made.
Some comments were duplicated.
Some comments could be merged by placing them where they are relevant.
When lowering an instruction, the intended logic seems to be:
1. If `I` does not contains a cleanup location, use that.
2. If `I` has a cleanup location, but there are other "normal" locations
afterwards, use the previous instruction location to avoid jumps in the line
table (unless there was no location).
3. Otherwise (`I` has a cleanup location and it's all cleanup locations
afterwards), use the location of the last instruction in the BB.
This is currently expressed in a very convoluted way. This patch
simplifies it.
When the main IRGenSIL loop decides to use the previous instruction's
location, it does so by emitting a compiler generated location. This is
creating an issue where the return address of a borrowing accessor is
landing on such a cleanup location, making the parent frame have no line
associated with it.
Why not use the last instruction's location instead? No tests fail with
this change, and it seems to keep the literal meaning of the "use the
last location" boolean variable that already exists in code.
rdar://167713693
The LoadableByAddress pass recognizes large loadable types in borrow accessors and returns them by @guaranteed_address.
This prevents stack allocations and unnecessary copies.
Co-authored-by: Meghana Gupta <meghana_gupta@apple.com>
There is a lot of stateful code in the middle of the main IRGenSIL loop
that makes it really hard to understand what is going on. This commit is
a very modest attempt at reducing the cognitive burden in this area by:
1. Moving it out to a helper function
2. Removing one of the stateful booleans, as it can be re-computed from
the previous instruction.
The hope is that, with this patch, we can reason a bit better about the
"CleanupLocation" situation, though even in the new state it is hard to
spot redundant code.
When compiling for a triple that predates typed throws,
`swift_getFunctionMetadataExtended` is conditionally available and emitted as a
weak external symbol. Previously, when such code ran on a older runtime where
`swift_getFunctionMetadataExtended` was uanvailable, accessing function metadata
for a `nonisolated(nonsending)` function would crash by invoking the null
`swift_getFunctionMetadataExtended`.
This patch adds a runtime null check when emitting metadata accessors for simple
`nonisolated(nonsending)` functions (those without typed throws or other
extended flags) in such situations. If `swift_getFunctionMetadataExtended` is
unavailable at runtime, we fall back to `swift_getFunctionMetadata`, returning
`@concurrent` function metadata instead.
This trade-off is acceptable because:
- Function metadata is not required to call a `nonisolated(nonsending)` function
- This enables use of these functions in frameworks like SwiftUI on older OS versions
Known limitations of the fallback path:
- Dynamic casts between `nonisolated(nonsending)` and `@concurrent` will incorrectly succeed
- Reflection will report `nonisolated(nonsending)` functions as `@concurrent`
- Existential erasure will lose the `nonisolated(nonsending)` attribute
These edge cases will produce obvious crashes during testing if misused, since
`nonisolated(nonsending)` expects its first parameter to be an actor while
`@concurrent` does not. This makes the increased compatibility worth the
trade-off.
rdar://158970802
Since after address lowering, `Borrow` can remain loadable with a known-
layout address-only referent, we need instructions that handle three
forms:
- borrow and referent are both loadable values
- borrow is a value, but referent is address-only
- borrow and referent are both address-only
Changing runtime in anyway can effect backward deployability.
Treeat borrow and mutate accessors as a regular method since they don't need any differentiated
runtime handling.
After https://github.com/swiftlang/swift/pull/85655, DI types for
existential typealiases and their inner protocol types are created,
which may encounter conflicts in the DIRefMap cache and assert failures
because they can have identical mangled names. This change fixes this
issue by using a separate cache for existential typealiases to avoid
such conflicts.
Issue https://github.com/swiftlang/swift/issues/86313
C++ classes can have protected destructors, copy constructors, and move
constructors. This pattern prevents that class from being directly
constructed, copied, or moved directly, but permits those operations on
types that inherit from it.
Those protected special members are inaccessible in the base class, but
are indirectly accessible in the derived class, so they shouldn't
prevent that derived class from being imported in Swift.
Such members were previously causing the derived class to be
incorrectly considered as having unknown copyability.
Note that, at the time of this patch, Swift cannot (directly) access any
members inherited from the base class with the protected special member,
because doing so relies on that base class being imported on its own
(which it can't without a public dtor/copy ctor/move ctor).
rdar://167555864
Those options can be used to save LLVM IR before and after LLVM optimizations to a file.
In contrast to `-emit-irgen` and `-emit-ir` the compiler doesn't stop an continues to e.g. create the regular output object file
This is to keep clang module cache hashes consistent throughout the
build and avoid inconsistent hash errors due to the CodeGenOpts
changing at the IRGen phase in the middle of a build.
https://github.com/swiftlang/swift/issues/86116
The exclusivity enforcement command-line flags currently impact the
generation of SIL within the current module. However, it does not
impact any SIL that was deserialized from another module, which means
that `-enforce-exclusivity=unchecked` doesn't actually remove all of
the dynamic exclusivity checks.
When dynamic exclusivity is disabled, lower SIL
begin_access/end_access instructions to nothing to ensure that we
won't do any dynamic exclusivity checks.
Use this to better model the reality of dynamic exclusivity checking
in Embedded Swift, which effectively turned off all dynamic
exclusivity checking by having empty stub implementations of
swift_(begin|end)Access. Instead, have Embedded Swift default to
`-enforce-exclusivity=unchecked`, so that it never emits calls to
swift_(begin|end)Access. Remove the stub implementations of
swift_(begin|end)Access from the Embedded Swift runtime, since we will
no longer generate calls to them by default.
Moving forward, this will allow us to conditionally enable the new
implementation of dynamic exclusivity checking by specifying
`-enforce-exclusivity=checked` for Embedded Swift builds. We'll stage
that in over time to avoid breaking existing Embedded Swift clients.
This makes these symbols visible in backtraces, at the cost of binary size.
The long-term goal is to generate these functions with LinkOnceODRLinkage, using
the contents of the HeapLayout to produce a mangled name, so they can be
deduplicated across modules.
In order to make the symbols more meaningful when they appear in backtraces,
use the name parameter passed to emitUnmanagedAlloc to produce a destructor name
with the format __swift_{name}_destructor.
rdar://149084103
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.
