Since we infer unsafety from a use of a declaration that involves unsafe types
in its signature, there isn't a reason to require @unsafe on declaration to
restate it. This matches recent revisions of SE-0458.
PrintAsClang is supposed to emit declarations in the same order regardless of the compiler’s internal state, but we have repeatedly found that our current criteria are inadequate, resulting in non-functionality-affecting changes to generated header content. Add a diagnostic that’s emitted when this happens soliciting a bug report.
Since there *should* be no cases where the compiler fails to order declarations, this diagnostic is never actually emitted. Instead, we test this change by enabling `-verify` on nearly all PrintAsClang tests to make sure they are unaffected.
This did demonstrate a missing criterion that only mattered in C++ mode: extensions that varied only in their generic signature were not sorted stably. Add a sort criterion for this.
Usage of Span was temporarily behind an experimental feature flag. Now
that SE-0447 has been accepted, remove the experimental feature flag and
allow Span usage everywhere.
Implements rdar://144819992.
Keep track of all of the type parameters and archetypes that are captured
by a local function or closure. Use that information to diagnose cases
where a non-Sendable metatype crosses an isolation boundary.
IterableDeclContext::checkDeserializeMemberErrorInPackage recursively checks if
decls and their member decls are deserialized correctly into another module.
This PR adds a check to make sure the inspected decls are from another module,
and provides an opt-in flag to fail fast on deserialization failure if found.
rdar://143830240
When calling a distributed function for an actor that might not be local,
the call can throw due to the distributed actor system producing an
error. The function might, independently, also throw. When the
function uses typed throws, we incorrectly treated the call is if it
would always throw the error type specified by the function. This
leads to incorrectly accepting invalid code, and compiler crashes in
SILGen.
The change here is to always mark calls to distributed functions
outside the actor as "implicitly throwing", which makes sure that we
treat the call sites as throwing 'any Error'. The actual handling of
the typed throw (from the local function) and the untyped throw (from
the distributed actor system) occurs in thunk generation in SILGen,
and was already handled correctly.
Fixes rdar://144093249, and undoes the ban introduced by rdar://136467528
Binary module built with Package CMO can be loaded for package-external client
modules which do not have direct access to decls that are serialized_for_package.
Downgrade build-time error to warning when a deserialization error is found for
a decl that should be allowed to access by package-external clients resiliently.
rdar://143800032
They don't yield a correct error type as we didn't implement it, so
rather allow it and risk crashes, ban it until we get the time to
implement it.
The real solution is to adjust typed throws error inference to do an
union of the thrown error of the func and the type thrown by the
distributed actor system remote call -- which today always would be (E |
Error) -> Error...
We could add a new associated type to DAS and then we could make it more
proper...
resolves rdar://136467528
Since the domain is now resolved by SemanticAvailableAttrRequest, diagnosing
attributes with invalid combinations of fields for a specific domains needs to
be delayed.
Also stop suggesting a '?' fix-it for casts, where it is not likely to
be helpful because the common intention is either to force the optional
or declare an IUO.
As specified by the SE-0446 acceptance, extensions that declare a type's
conditional `Copyable` or `Escapable` ability must reiterate explicitly all
of the `Copyable` and/or `Escapable` requirements, whether required or not
required (by e.g. `~Copyable`) that were suppressed in the original
type declaration.
This failure will most-likely result in the dependency query failure which will fail the scan. It will be helpful if the scanner emitted diagnostic for each such module it rejected to explain the reason why.
Resolves rdar://142906530
`x declared here` is not helpful and clear enough, especially when there
are other notes attached. Swap it for a new note that says
`requirement x declared here`.
This diagnostic was staged in
https://github.com/swiftlang/swift/pull/38991 as a warning to not break
source. Give it a reasonable margin and, in turn, convey that it is in
fact a compatibility warning and will become an error.
Introduce an `unsafe` expression akin to `try` and `await` that notes
that there are unsafe constructs in the expression to the right-hand
side. Extend the effects checker to also check for unsafety along with
throwing and async operations. This will result in diagnostics like
the following:
10 | func sum() -> Int {
11 | withUnsafeBufferPointer { buffer in
12 | let value = buffer[0]
| | `- note: reference to unsafe subscript 'subscript(_:)'
| |- warning: expression uses unsafe constructs but is not marked with 'unsafe'
| `- note: reference to parameter 'buffer' involves unsafe type 'UnsafeBufferPointer<Int>'
13 | tryWithP(X())
14 | return fastAdd(buffer.baseAddress, buffer.count)
These will come with a Fix-It that inserts `unsafe` into the proper
place. There's also a warning that appears when `unsafe` doesn't cover
any unsafe code, making it easier to clean up extraneous `unsafe`.
This approach requires that `@unsafe` be present on any declaration
that involves unsafe constructs within its signature. Outside of the
signature, the `unsafe` expression is used to identify unsafe code.
As an example, use this for the "`@preconcurrency` on import has no
effect" warning, which is not yet working correctly. This disables it
by default but leaves it in place for our testing.
