When performing a dynamic cast to an existential type that satisfies
(Metatype)Sendable, it is unsafe to allow isolated conformances of any
kind to satisfy protocol requirements for the existential. Identify
these cases and mark the corresponding cast instructions with a new flag,
`[prohibit_isolated_conformances]` that will be used to indicate to the
runtime that isolated conformances need to be rejected.
I am doing this in preparation for adding the ability to represent in the SIL
type system that a function is global actor isolated. Since we have isolated
parameters in SIL, we do not need to represent parameter, nonisolated, or
nonisolated caller in the type system. So this should be sufficient for our
purposes.
I am adding this since I need to ensure that we mangle into thunks that convert
execution(caller) functions to `global actor` functions what the global actor
is. Otherwise, we cannot tell the difference in between such a thunk and a thunk
that converts execution(caller) to execution(concurrent).
This is a value operation that can work just fine on lowered types,
so there's no need to carry along a formal type. Make the value/address
duality clearer, and enforce it in the verifier.
With this approach, you cannot tell whether a parameter is addressable only
from the function type. Instead you need the SILValue that will be passed to the
call site.
Preserve conditionallyAddressableParamIndices independent of any
addressableParamIndices. The conditional dependencies are subject to change
based on type substitution.
The Protocol field isn't really necessary, because the conformance
stores the protocol. But we do need the substituted subject type
of the requirement, just temporarily, until an abstract conformance
stores its own subject type too.
* let `SIL.Type` conform to `TypeProperties` to share the implementation of common type properties between the AST types and `SIL.Type`
* call references to an `AST.Type` `rawType` (instead of just `type`)
* remove unneeded stuff
* add comments
The `unchecked_ref_cast` is designed to be able to cast between
`Optional<ClassType>` and `ClassType`. We need to handle these cases by
checking if the type is optional and adjust the path accordingly.
* factor out common methods of AST Type/CanonicalType into a `TypeProperties` protocol.
* add more APIs to AST Type/CanoncialType.
* move `MetatypeRepresentation` from SIL.Type to AST.Type and implement it with a swift enum.
* let `Builder.createMetatype` get a CanonicalType as instance type, because the instance type must not be a lowered type.
The optional C++ type was bridged to a non-optional Swift type.
The correct way is to bridged the non-optional C++ type to the non-optional Swift type.
* getting the formal source and target types of casts
* `isFromVarDecl` and `usesMoveableValueDebugInfo` for AllocStackInst
* WitnessMethod APIs
* `TryApply.isNonAsync`
Check if an operand's instruction has been deleted in `UseList.next()`.
This allows to delete an instruction, which has two uses of a value, during use-list iteration.
Don't include type-dependent operands in the argument list of the new keypath instruction.
Also enable the assert, which catches this problem, in release builds.
Fixes a compiler crash.
This is really old code from before llvm::hash_combine existed. We really
shouldn't be rolling out own hash combine when we have something that we are
consistently using from LLVM. I validated the history of this code and talked
with JoeG/DougG/others to see if there was any reason beyond not having
hash_combine for us not to use hash_combine.
The reason why I am changing this now is that I want to convert SILDeclRef to
have another additional bit and use an OptionSet. When I noticed this... my eyes
burned, so I thought I would just quickly fix it before I landed the other
change so it could be a NFC change.
