Just because the type of the initializer expression is an opaque return type,
does not mean it is the opaque return type *for the variable being initialized*.
It looks like there is a bit of duplicated logic and layering violations going
on so I only fixed one caller of openOpaqueType(). This addresses the test case
in the issue. For the remaining calls I added FIXMEs to investigate what is
going on.
Fixes https://github.com/swiftlang/swift/issues/73245.
Fixes rdar://127180656.
Instead, each scan's 'ModuleDependenciesCache' will hold all of the data corresponding to discovered module dependencies.
The initial design presumed the possibility of sharing a global scanning cache amongs different scanner invocations, possibly even different concurrent scanner invocations.
This change also deprecates two libSwiftScan entry-points: 'swiftscan_scanner_cache_load' and 'swiftscan_scanner_cache_serialize'. They never ended up getting used, and since this code has been largely stale, we are confident they have not otherwise had users, and they do not fit with this design.
A follow-up change will re-introduce moduele dependency cache serialization on a per-query basis and bring the binary format up-to-date.
Now that IUOs are supported for compound function
references, we can properly set the compound bit
here.
This is a source breaking change since this used
to be legal:
```swift
struct S {
static func foo(x: Int) -> Self { .init() }
}
let _: S = .foo(x:)(x: 0)
```
However I somewhat doubt anyone is intentionally
writing code like that.
Many APIs using nonescapable types would like to vend interior pointers to their
parameter bindings, but this isn't normally always possible because of representation
changes the caller may do around the call, such as moving the value in or out of memory,
bridging or reabstracting it, etc. `@_addressable` forces the corresponding parameter
to be passed indirectly in memory, in its maximally-abstracted representation.
[TODO] If return values have a lifetime dependency on this parameter, the caller must
keep this in-memory representation alive for the duration of the dependent value's
lifetime.
If the output loading failed after cache key lookup, treat that as a
warning and resume as if that is a cache miss. This is not a valid
configuration for builtin CAS but can happen for a remote CAS service
that failed to serve the output. Instead of failing, we should continue
to compile to avoid disruptive failures.
rdar://140822432
This change addresses the following issue: when an error is being wrapped in a warning, the diagnostic message will use the wrapper's `DiagGroupID` as the warning's name. However, we want to retain the original error's group for use. For example, in Swift 5, async_unavailable_decl is wrapped in error_in_future_swift_version. When we print a diagnostic of this kind, we want to keep the `DiagGroupID` of `async_unavailable_decl`, not that of `error_in_future_swift_version`.
To achieve this, we add `DiagGroupID` to the `Diagnostic` class. When an active diagnostic is wrapped in DiagnosticEngine, we retain the original `DiagGroupID`.
For illustration purposes, this change also introduces a new group: `DeclarationUnavailableFromAsynchronousContext`.
With this change, we produce errors and warnings of this kind with messages like the following:
```
global function 'fNoAsync' is unavailable from asynchronous contexts [DeclarationUnavailableFromAsynchronousContext]
global function 'fNoAsync' is unavailable from asynchronous contexts; this is an error in the Swift 6 language mode [DeclarationUnavailableFromAsynchronousContext]
```
Also remove the underlying `SemanticUnavailableAttrRequest`, which used memory
very inefficiently in order to cache a detailed answer to what was usually a
much simpler question.
The only remaining use of `Decl::getSemanticUnavailableAttr()` that actually
needed to locate the semantic attribute making a declaration unavailable was in
`TypeCheckAttr.cpp`. The implementation of the request could just be used
directly in that one location. The other remaining callers only needed to know
if the decl was unavailable or not, which there are simpler queries for.
# Please enter the commit message for your changes. Lines starting
Previously we would not propagate those into the generated distributed
actor, making a lot of generic distributed actor protocols impossible to
express.
We indeed cannot handle protocols WITHOUT primary associated types, but
we certainly can handle them with!
This resolves rdar://139332556
Many existing C APIs for retaining references, including Apple's own, return
the reference. Support this pattern, along with the existing void return
signature, with when importing reference types from C++.
In terms of the test suite the only difference is that we allow for non-Sendable
types to be returned from nonisolated functions. This is safe due to the rules
of rbi. We do still error when we return non-Sendable functions across isolation
boundaries though.
The reason that I am doing this now is that I am implementing a prototype that
allows for nonisolated functions to inherit isolation from their caller. This
would have required me to implement support both in Sema for results and
arguments in SIL. Rather than implement results in Sema, I just finished the
work of transitioning the result checking out of Sema and into SIL. The actual
prototype will land in a subsequent change.
rdar://127477211
It replaces `DeclAttr::getUnavailable()` and `AvailableAttr::isUnavailable()`
as the designated way to query for the attribute that makes a decl unavailable.
FunctionRefKind was originally designed to represent
the handling needed for argument labels on function
references, in which the unapplied and compound cases
are effectively the same. However it has since been
adopted in a bunch of other places where the
spelling of the function reference is entirely
orthogonal to the application level.
Split out the application level from the
"is compound" bit. Should be NFC. I've left some
FIXMEs for non-NFC changes that I'll address in a
follow-up.
The renamed decl is now stored exclusively in the split request evaluator
storage, which is more efficient since most availability attributes do not
specify a renamed decl.
This type is intended to be used to wrap compiler synthesized nodes
(i.e. variables) to make it easier for diagnostic to diagnose precise
failure locations.
Consider the situation like:
```
protocol P {}
extension Array: P where Element: P {}
func test<T: P>() -> T {
$_a = ...
$_b = ...
return [$_a, $_b]
}
```
This is a common pattern with result builders.
In this case if one of the elements don't conform to `P` the best
user experience would be to attach diagnostic to the element otherwise
the developers would have to figure out where in result expression
the error occured before attempting to fix it.
Type annotations for instruction operands are omitted, e.g.
```
%3 = struct $S(%1, %2)
```
Operand types are redundant anyway and were only used for sanity checking in the SIL parser.
But: operand types _are_ printed if the definition of the operand value was not printed yet.
This happens:
* if the block with the definition appears after the block where the operand's instruction is located
* if a block or instruction is printed in isolation, e.g. in a debugger
The old behavior can be restored with `-Xllvm -sil-print-types`.
This option is added to many existing test files which check for operand types in their check-lines.
