The problem detection logic currently expects `generic argument #<N>`
location to always be associated with two generic types, but that
is not always the case, this locator element is sometimes used for
i.e. optional object types and pointer `Pointee` type when types
appear in argument positions. This needs to be handled specifically.
Resolves: rdar://82971941
Without contextual information it won't be possible to bind a missing
member to a concrete type later, so let's bind them eagerly and propagate
placeholders outward.
Resolves: rdar://152021264
Resolves: https://github.com/swiftlang/swift/issues/81770
Initially this declaration is going to be used to determine
per-file default actor isolation i.e. `using @MainActor` and
`using nonisolated` but it could be extended to support other
file-global settings in the future.
A member and a parameter could be wrapped in an arbitrary number
of `Optional`, we need to look through all of them to get to the
underlying function type.
Resolves: rdar://151943924
This is an attempt to solving
https://github.com/swiftlang/swift/issues/72199.
As I've already lined out in the issue, this seems to be a two-fold
problem.
The first one was a rather easy fix, as I've seen similar approaches in
different parts of the codebase. It is pretty much just un-currying the
generic function.
The second problem was, that `DependentMemberType`s were counted towards
the generic-parameter-should-only-be-mentioned-once-limit even though
you cannot infer the generic type from the dependent member type.
If key or value of a literal collection expression doesn't conform
to protocol(s) expected by the contextual existential type, let's
diagnose that via a tailed collection mismatch fix instead of a
generic conformance one.
Resolves: rdar://103045274
`@autoclosure` is associated with a parameter, we use argument mismatch fix
to diagnose missing explicit calls as well as any mismatches in that position.
Resolves: rdar://110527062
If the argument has an extra `?` or `!`, let's not attempt to force
optional (because it's use is already invalid) and re-introduce
the constraint with unwrapped type instead. This would help to diagnose
the invalid chaining as well as any argument to parameter mismatches.
Resolves: rdar://126080504
When issuing warnings about an import not needing to be public, we did
not account for the Distributed module MUST be imported when a
distributed actor is declared. This also actually means that a public
distributed actor effectively is a public use of the DistributedActor
protocol
resolves rdar://152129980
Omit an explicit access level from `MemberImportVisibility` fix-its under the
following conditions:
- `InternalImportsByDefault` is enabled.
- The required import needs an `internal` access level or lower.
- The module is not yet imported explicitly in any other file.
Resolves rdar://149577615.
Consider an `@_alwaysEmitIntoClient` function and a custom derivative
defined
for it. Previously, such a combination resulted different errors under
different
circumstances.
Sometimes, there were linker errors due to missing derivative function
symbol -
these occurred when we tried to find the derivative in a module, while
it
should have been emitted into client's code (and it did not happen).
Sometimes, there were SIL verification failures like this:
```
SIL verification failed: internal/private function cannot be serialized or serializable: !F->isAnySerialized() || embedded
```
Linkage and serialization options for the derivative were not handled
properly,
and, instead of PublicNonABI linkage, we had Private one which is
unsupported
for serialization - but we need to serialize `@_alwaysEmitIntoClient`
functions
so the client's code is able to see them.
This patch resolves the issue and adds proper handling of custom
derivatives
of `@_alwaysEmitIntoClient` functions. Note that either both the
function and
its custom derivative or none of them should have
`@_alwaysEmitIntoClient`
attribute, mismatch in this attribute is not supported.
The following cases are handled (assume that in each case client's code
uses
the derivative).
1. Both the function and its derivative are defined in a single file in
one module.
2. Both the function and its derivative are defined in different files
which
are compiled to a single module.
3. The function is defined in one module, its derivative is defined in
another
module.
4. The function and the derivative are defined as members of a protocol
extension in two separate modules - one for the function and one for the
derivative. A struct conforming the protocol is defined in the third
module.
5. The function and the derivative are defined as members of a struct
extension in two separate modules - one for the function and one for the
derivative.
The changes allow to define derivatives for methods of `SIMD`.
Fixes#54445
<!--
If this pull request is targeting a release branch, please fill out the
following form:
https://github.com/swiftlang/.github/blob/main/PULL_REQUEST_TEMPLATE/release.md?plain=1
Otherwise, replace this comment with a description of your changes and
rationale. Provide links to external references/discussions if
appropriate.
If this pull request resolves any GitHub issues, link them like so:
Resolves <link to issue>, resolves <link to another issue>.
For more information about linking a pull request to an issue, see:
https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
-->
<!--
Before merging this pull request, you must run the Swift continuous
integration tests.
For information about triggering CI builds via @swift-ci, see:
https://github.com/apple/swift/blob/main/docs/ContinuousIntegration.md#swift-ci
Thank you for your contribution to Swift!
-->
Implements SE-0460 -- the non-underscored version of @specialized.
It allows to specify "internal" (not abi affecting) specializations.
rdar://150033316
Replaces generic `expression is 'async' but is not marked with 'await`
diagnostic with a tailed one for cases where there is an access to an
actor-isolated value outside of its actor without `await` keyword.
This makes the diagnostics for async and sync contexts consistent
and actually identifies a problem instead of simply pointing out
the solution.
Resolves: rdar://151720646
This feature is essentially self-migrating, but fit it into the
migration flow by marking it as migratable, adding
`-strict-memory-safety:migrate`, and introducing a test.
When migrating, provide warnings that add 'nonisolated' to nonisolated
conformances that don't already have it and would end up being inferred
to be isolated under the upcoming feature.
When the attribute is specified explicitly passing a `@concurrent`
closure to a global actor-isolated parameter or contextual type
should result in a conversion and closure itself should be nonisolated.
Resolves: rdar://151797372
When an "unsafe" expression is used as the case expression, lift it up
so it also covers the synthesized matching expression (`=~`). This
eliminates some unsuppressible strict memory safety warnings.
Fixes rdar://151731850.
Syntactically verify that initializer expressions of '@const' variables and argument expressions to '@const' parameters consist strictly of syntactically-verifiable set of basic values and operations
See the inline comments for more details. Depending on the closure's
type signature, sometimes adding the attribute will break code. Fix this
by also adding inferred effects to the signature in these cases.
`@MainActor` errors are hard errors, even in minimal concurrency checking in Swift 5 mode.
When users set the default isolation to main actor, we should infer `@preconcurrency @MainActor`
in language modes < 6 to get the right diagnostic staging behavior.
Resolves: rdar://151029517
Convert a bunch of places where we're dumping to stderr and calling
`abort` over to using `ABORT` such that the message gets printed to
the pretty stack trace. This ensures it gets picked up by
CrashReporter.
