When importing C++ methods, Swift always assumes that methods named `begin()` and `end()` are unsafe, since these methods commonly return iterator types that are inherently unsafe in Swift.
Some additional logic in Sema tries to diagnose usages of `.begin()` and `.end()` from Swift and suggest safe alternatives. That logic had a null pointer dereference bug.
rdar://153814676 / resolves https://github.com/swiftlang/swift/issues/82361
Diagnostics can outlive the ConstraintSystem itself if we have a
diagnostic transaction for e.g `typeCheckParameterDefault`, make sure
we don't try to use a solver-allocated type as an argument.
Currently the note is going to point to the "callee" but that is
incorrect when the failure is related to an argument of a call.
Detect this situation in `RValueTreatedAsLValueFailure::diagnoseAsNote`
and produce a correct note.
Resolves: rdar://150689994
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
The NormalProtocolConformance APIs for checking for an explicitly-written
isolation on a conformance were easy to get to, and the real semantic
API was buried in the type checker, leading to some unprincipled
checking. Instead, create a central ProtocolConformance::getIsolation()
to get the (semantic) actor isolation, and let that be the only place
that will access the explicitly-written global actor isolation for a
conformance. Update all call sites appropriately.
With the move to explicitly specifying the global actor for an isolated
conformance, we can now have conformances whose isolation differs from
that of the type, including having actors with global-actor-isolated
conformances. Introduce this generalization to match the proposal, and
update/add tests accordingly.
To pave the way for the new experimental feature which will operate on '@const' attribute and expand the scope of what's currently handled by '_const' without breaking compatibility, for now.
Within the constraint system, introduce a new kind of conformance constraint,
a "nonisolated conforms-to" constraint, which can only be satisfied by
nonisolated conformances. Introduce this constraint instead of the normal
conforms-to constraint whenever the subject type is a type parameter that
has either a `Sendable` or `SendableMetatype` constraint, i.e., when the type
or its values can escape the current isolation domain.
Simplifying into the function expression is wrong,
like `FunctionArgument` this isn't an element that
can be simplified. This also means we don't need
to handle it in `MissingCallFailure`, since we
shouldn't be recording that fix in this case.
Protocol conformances have a handful attributes that can apply to them
directly, including @unchecked (for Sendable), @preconcurrency, and
@retroactive. Generalize this into an option set that we carry around,
so it's a bit easier to add them, as well as reworking the
serialization logic to deal with an arbitrary number of such options.
Use this generality to add support for @unsafe conformances, which are
needed when unsafe witnesses are used to conform to safe requirements.
Implement general support for @unsafe conformances, including
producing a single diagnostic per missing @unsafe that provides a
Fix-It and collects together all of the unsafe witnesses as notes.
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.
