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
This enables optimizing / dead-stripping of witness methods across modules at
LTO time.
- Under -internalize-at-link, restrict visibility of wtables to linkage unit.
- Emit thunks for cross-module wcalls when WME is enabled.
- Use thunks for wcalls across modules when WME is enabled.
- Adjust TBDGen to account for witness method thunks when WME is enabled.
- Add an IR test to check that thunks are used when doing cross-module calls.
- Add an end-to-end test case for cross-module WME.
- Witness method calls are done via @llvm.type.checked.load instrinsic call with a type identifier
- Type id of a witness method is the requirement's mangled name
- Witness tables get !type markers that list offsets and type ids of all methods in the wtable
- Added -enable-llvm-wme to enable Witness Method Elimination
- Added IR test and execution test
Start treating the null {Can}GenericSignature as a regular signature
with no requirements and no parameters. This not only makes for a much
safer abstraction, but allows us to simplify a lot of the clients of
GenericSignature that would previously have to check for null before
using the abstraction.
Sema allows you to pass type-pinning parameters into an extension of an Objective-C generic class, but IRGen did not properly handle erasing these types to existential types in runtime metadata. This commit corrects that mistake.
This adjusts the IRGen layer to accommodate the Windows linking model.
We assume dynamic linking by default. The static linking is enabled by
passing `-static` to the driver, which forwards it to the frontend when
building the module statically. This has already been required when
generating libraries, however, the non-Windows targets are more
forgiving and let it work. On those platforms, using this hint would
allow for more efficient code generation, reducing load times and some
runtime penalties from the PLT and GOT references formed to symbols
which are module local.
This corrects static linking on Windows, which is one of the last few
items that are missing on Windows. It also takes advantage of the hint
for the one peculiar difference between Windows and non-Windows:
protocol conformances that span module boundaries are not available as a
constant. However, when statically linking, we can enable those
conformances to be statically resolved. This should enable the last
known pattern to work when using static linking.
This support requires further work in the Swift Package Manager to
actually enable building libraries properly. However, when building
with CMake, this should be sufficient to enable static linking.
Previously, AsyncFunctionPointer constants were signed as code. That
was incorrect considering that these constants are in fact data. Here,
that is fixed.
rdar://76118522
EmitPolymorphicArguments puts the extra sources before the unfulfilled
requirements into the explosion. The NecessaryBindings instance must
have the type parameters in the same order. Previously, though, they
were added after enumerating unfulfilled requirements. Here, they are
added _before_ enumerating, matching the ordering of
EmitPolymorphicArguments.
rdar://73742483
Resilient witness tables and resilient class vtables are built from
descriptors. Make sure we reference the AsyncFunctionPointer of a
method implementation, and not the implementation itself, if the
method is async.
Part of rdar://problem/73625623.
Previously, when saving NecessaryBindings for an async function, if a
type that was passed-in happened to be an archetype, a lookup for that
type's conformance would always be done. However, that lookup was not
always necessary or possible such as in the case where both the metadata
and the witness table were provided to the function in an async context.
Here, that is fixed by using the conformance that was seen when
constructing the NecessaryBindings if one is available.
rdar://problem/72397303
NecessaryBindings are used by both async functions and partial apply
forwarders. The latter are able to avoid bindings in some cases because
a new function is generated where the information that would otherwise
be available in the bindings can be made available. That is not the
case for async functions. A generic async function requires all of the
metadata and witness tables be passed along to it: unlike a partial
apply forwarder it isn't in any way specialized so this information
can't be recovered.
Previously, metadata bindings were always passed along to async
functions. However, destructuring that can be done for partial apply
forwarders was still being applied. This resulted in an inappropriate
and unexpected number of bindings in NecessaryBindings.
Here, that destructuring is avoided for metadata passed to async
functions.
Now, the full metadata required by async functions are passed along to
them as necessary.
rdar://problem/71816041
An AsyncFunctionPointer, defined in Task.h, is a struct consisting of
two i32s: (1) the relative address of the async function and (2) the
size of the async context to be allocated when calling that function.
Here, such structs are emitted for every async SILFunction that is
emitted.
Previously, NecessaryBindings used a SetVector to store the
GenericRequirements that it accumulates. That was a problem for the
layout of async contexts where it is possible for the same generic
argument to be repeated. Meanwhile, that is correct for partial
application forwarders where there is a single thunk for every partial
apply and consequently the bindings can be packed in without
duplication.
Here, a SetVector is used only when the NecessaryBindings are for
partial apply forwarders. When the NecessaryBindings are instead for
async functions, a SmallVector is used.
Previously, EmitPolymorphicParameters dealt directly with an Explosion
from which it pulled values. In one place, there was a conditional
check for async which handled some cases. There was however another
place where the polymorphic parameter was pulled directly from the
explosion. That missed case resulted in attempting to pull a
polymorphic parameter directly from an Explosion which contains only a
%swift.context* per the async calling convention.
Here, those parameters are now pulled from an EntryPointArgumentEmission
subclasses of which are able to provide the relevant definition of what
pulling a parameter means.
rdar://problem/70144083
By default, emitTypeMetadataRef does a blocking request for complete
metadata, which is the right thing to do for most purposes in IRGen.
Unfortunately, it's actively dangerous in code that can be called
during metadata completion, like an associated conformance accessor,
because it can cause artificial dependency cycles that the runtime
isn't equipped to detect, much less solve.
This is a partial fix for rdar://69901318, which also exposes a bad
metadata access path that seems to be causing an artificial problem.
Previously, the AsyncContextLayout did not make space for the trailing
witness fields (self metadata and self witness table) and the
AsyncNativeCCEntryPointArgumentEmission could consequently not vend
these fields. Here, the fields are added to the layout.
Previously, the polymorphic arguments were being discarded. Here, that
situation is improved by pulling the polymorphic arguments out of the
explosion when having the polymorphic parameters via the
NecessaryBindings instance. In order to eanble that, an overload of
NecessaryBindings::save is added which takes an explosion and asserts
that the polymorphic parameter pulled from the explosion matches with
the polymorphic parameter in the NecessaryBindings instance.
Here, the following is implemented:
- Construction of SwiftContext struct with the fields needed for calling
functions.
- Allocating and deallocating these swift context via runtime calls
before calling async functions and after returning from them.
- Storing arguments (including bindings and the self parameter but not
including protocol fields for witness methods) and returns (both
direct and indirect).
- Calling async functions.
Additional things that still need to be done:
- protocol extension methods
- protocol witness methods
- storing yields
- partial applies
