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)
When rewriting uses of a noncopyable value, the move-only checker failed to take into account
the scope of borrowing uses when establishing the final lifetimes of values. One way this
manifested was when borrowed values get reabstracted from value to in-memory representations,
using a store_borrow instruction, the lifetime of the original borrow would be ended immediately
after the store_borrow begins rather than after the matching end_borrow. Fix this by, first,
changing `store_borrow` to be treated as a borrowing use of its source rather than an
interior-pointer use; this should be more accurate overall since `store_borrow` borrows the
entire source value for a well-scoped duration balanced by `end_borrow` instructions. That done,
change MoveOnlyBorrowToDestructureUtils so that when it sees a borrow use, it ends the borrow
at the end(s) of the use's borrow scope, instead of immediately after the beginning of the use.
This attribute instructs the compiler that this function declaration
should be "import"ed from host environment. It's equivalent of Clang's
`__attribute__((import_module("module"), import_name("field")))`
