For any `#if` blocks in the function we're emitting,
emit skipped ranges for the inactive clauses, including
the syntax for the `#if` itself, since that should
not be considered executable code.
rdar://116860865
The access path verification optimizer pass calls
`getStaticallyInitializedVariable()`, which was written assuming that the given
`SILFunction` would always have a valid return basic block. When the
`-unavailable-decl-optimization=stub` option is passed to the frontend, though,
any function generated for a declaration marked `@available(*, unavailable)` is
rewritten to trap by calling a function that returns `Never`. Therefore the
rewritten functions do not have return blocks and passing these functions to
`getStaticallyInitializedVariable()` would result in the compiler invoking
undefined behavior.
Resolves rdar://118281508
Adjust `SILFunctionBuilder` to allow distinct non-custom effects and to
interpret such "conflicting" guarantees to provide the strongest
guarantee. For example, annotating a function both `@_effects(readnone)`
and `@_effects(releasenone)` is equivalent to only annotating it
`@_effects(readnone)`.
First step to reapplying https://github.com/apple/swift/pull/68285 .
rdar://118216287
This peephole optimization in SILGen requires us to use the thrown
error for the context of a closure type rather than the thrown error
for the closure AST node itself.
I also included changes to the rest of the SIL optimizer pipeline to ensure that
the part of the optimizer pipeline before we lower tuple_addr_constructor (which
is right after we run TransferNonSendable) work as before.
The reason why I am doing this is that this ensures that diagnostic passes can
tell the difference in between:
```
x = (a, b, c)
```
and
```
x.0 = a
x.1 = b
x.2 = c
```
This is important for things like TransferNonSendable where assigning over the
entire tuple element is treated differently from if one were to initialize it in
pieces using projections.
rdar://117880194
Introduce SILGen support for reabstractions thunks that change the
error, between indirect and direct errors as well as conversions
amongst error types (e.g., from concrete to `any Error`).
This commit just introduces the instruction. In a subsequent commit, I am going
to add support to SILGen to emit this. This ensures that when we assign into a
tuple var we initialize it with one instruction instead of doing it in pieces.
The problem with doing it in pieces is that when one is emitting diagnostics it
looks semantically like SILGen actually is emitting code for initializing in
pieces which could be an error.
We were missing some of the "artificial" types in the
TypeBase::isNoncopyable implementation. Rather than add them to the
frontend, I just check for those special SIL-only types in
SILType::isMoveOnly.
resolves rdar://117282929
The reason for this issue is that we were originally checking in our NonSendable
type oracle just if a type conformed to Sendable. But function types do not
conform to protocols, so this would fail for protocols. To fix this, I added
some helper methods to call swift::isSendableType on SILType, called that in our
oracle, and then I added support in swift::isSendableType for both
SILFunctionType and AnyFunctionType so that we correctly handle them depending
on their sendability.
There was also a question if we also handled function conversions correctly. I
added a test case that shows that we do not error in either of the cases.
Another nice aspect of this change is that we no longer need to stash a pointer
to a looked up Sendable protocol to perform the check since that just happens
naturally inside SILType::isSendable() when it calls isSendableType. This is a
better separation of concerns.
rdar://116525224
When building complex projects, there may cases of static libraries
which expose `@inlinable` functions which reference functions from
dynamically linked dependencies. In such a case, we need to consider the
provenance of the `function_ref` when determining the DLL storage for
linkage. We would previously use the deserialised metadata on the
`SILFunction` as there are entities where the `DeclContext` may not be
deserialised. However, this leaves us in a state where we are unable to
determine the actual provenance correctly in some cases. By simply
accessing the parent module directly from the `SILFunction` we ensure
that we properly identify the origin of the function allowing us to
query the DLL storage property. This further allows us to remove the
extra storage required for whether the `SILFunction` is statically
linked.
in TBD, causing a linker error. This is because the default arg
is not generated during silgen. This PR adds a check to make sure
it's represented by SILDeclRef and its linkage emitted.
Resolves rdar://116184295
We don't support generating code for ptrauth builtins with generic
inputs (or non-constant inputs). We rely on specialization/inlining for
such code to work.
After a recent commit (#68843 ) code in IRGen keeps internal unreferenced
functions alive for debugging purposes.
This is a problem for the generic functions in PtrAuth.swift using
ptrauth builtins.
Opt out of this new behavior by sprinkling some pixie dust.
Fixes debug swift standard library builds targeting arm64e.
rdar://117411740
Conflicts:
- `lib/AST/TypeCheckRequests.cpp` renamed `isMoveOnly` which requires
a static_cast on rebranch because `Optional` is now a `std::optional`.
I've renamed the method to `TypeDecl::isNoncopyable`, because the query
doesn't make sense for many other kinds of `ValueDecl`'s beyond the
`TypeDecl`'s. In fact, it looks like no one was relying on that anyway.
Thus, we now have a distinction where in Sema, you ask whether
a `Type` or `TypeDecl` is "Noncopyable". But within SIL, we still
preserve the notion of "move-only" since there is additionally the
move-only type wrapper for types that otherwise support copying.
Deserialization is calling AccessMarkerElimination repeatedly on the
same function.
The bug was introduced here:
commit 872bf40e17
Date: Mon Aug 13 10:24:20 2018
[sil-optimizer] Centralize how we send out serialization notifications.
Where the code that uniques the deserialization callbacks was simply
removed!
As a result, this pass was being invoked a number of times equal to
the number of functions in the module *multiplied* by the number of
functions being deserialized.
Fixes rdar://117141871 (Building spends most of its time in
AccessMarkerElimination)
