When using opaque pointers we can no longer depend on the LLVM IR type
to perform the computation. Instead compute the number while we are
building a signature.
In preparation for moving to llvm's opaque pointer representation
replace getPointerElementType and CreateCall/CreateLoad/Store uses that
dependent on the address operand's pointer element type.
This means an `Address` carries the element type and we use
`FunctionPointer` in more places or read the function type off the
`llvm::Function`.
If a foreign type conforms to a protocol, and that conformance is not
resilient, we were emitting an instantantiation function but it would
never be called because we weren't emitting the `GenericWitnessTable`
that would have contained a reference to it.
This was happening because of a missing `isSynthesizedNonUnique()` call
in `isDependentConformance()`.
rdar://97290618
We had two notions of canonical types, one is the structural property
where it doesn't contain sugared types, the other one where it does
not contain reducible type parameters with respect to a generic
signature.
Rename the second one to a 'reduced type'.
While building witness table record, let's use `hasAsync()` check on
`SILDeclRef` of the requirement instead of reaching for the underlying
declaration because the reference should be the source of truth about
`async` and other attributes.
In case of distributed thunk witness, which is always `async throws`,
the underlying declaration could be sync because it's the protocol
requirement declaration.
On some Harvard architectures like WebAssembly that allow sliding code
and data address space offsets independently, it's impossible to make
direct relative reference to code from data because the relative offset
between them is not representable.
Use absolute function references instead of relative ones on such targets.
The RequirementSignature generalizes the old ArrayRef<Requirement>
which stores the minimal requirements that a conforming type's
witnesses must satisfy, to also record the protocol typealiases
defined in the protocol.
Since `TargetGenericEnvironmentDescriptor` uses trailing objects to
store parameters, requirements and other information. IR Emission
should pad the structure to be 4 bytes aligned before adding generic
requirements, because that's the alignment expected by
`TargetGenericRequirementDescriptor`.
There are three major changes here:
1. The addition of "SILFunctionTypeRepresentation::CXXMethod".
2. C++ methods are imported with their members *last*. Then the arguments are switched when emitting the IR for an application of the function.
3. Clang decls are now marked as foreign witnesses.
These are all steps towards being able to have C++ protocol conformance.
This cleans up 90 instances of this warning and reduces the build spew
when building on Linux. This helps identify actual issues when
building which can get lost in the stream of warning messages. It also
helps restore the ability to build the compiler with gcc.
The functions in llvm-project `AttributeList` have been
renamed/refactored to help remove uses of `AttributeList::*Index`.
Update to use these new functions where possible. There's one use of
`AttrIndex` remaining as `replaceAttributeTypeAtIndex` still takes the
index and there is no `param` equivalent. We could add one locally, but
presumably that will be added eventually.
The functions in llvm-project `AttributeList` have been
renamed/refactored to help remove uses of `AttributeList::*Index`.
Update to use these new functions where possible. There's one use of
`AttrIndex` remaining as `replaceAttributeTypeAtIndex` still takes the
index and there is no `param` equivalent. We could add one locally, but
presumably that will be added eventually.
When building with lazy initialization of the root conformance, we need
to ensure that we are invoking the accessor to initialize the
conformance record. We would previously generate a direct reference to
the conformance, which was uninitialized, resulting in a crash at
runtime.
The non-windows test changes here are to use/imply static linking for
the support modules. This should have no difference on the non-Windows
targets, but makes a difference on Windows where this implies that
everything will be built into a single module, which permits the
non-indirect access to types. Unfortunately, this does somewhat regress
the test coverage on Windows as we do not exercise as much of the shared
linkage paths which do change some of the code-generation to deal with
the moral equivalent of the GOT - the IAT.
Special thanks to @slavapestov for the pointer to
`isDependentConformance`. This should eliminate the last known issue
with cross-module protocol conformances.
Fixes: SR-14807
