[5.5] IRGen: use the accessor conformance on Windows #40264
Conversation
compnerd
changed the title
|
@swift-ci please test |
compnerd
force-pushed
the
5-5-accessory
branch
from
0c7b231 to
4c0743c
Compare
|
@swift-ci please test |
|
Build failed |
|
Build failed |
|
@swift-ci please test |
|
Build failed |
|
Build failed |
|
@swift-ci please test Windows platform |
|
@swift-ci please test |
compnerd
force-pushed
the
5-5-accessory
branch
from
3e4dab1 to
6da092b
Compare
|
@swift-ci please test |
|
@swift-ci please test Windows platform |
|
Build failed |
|
Build failed |
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 The 5.5-only test changes are due to the lack of support for static linking which means that all the support modules are treated as though they are behind a resiliency boundary on Windows. We relax the tests to accept both though on main we do not do so.
compnerd
force-pushed
the
5-5-accessory
branch
from
6da092b to
284a297
Compare
|
@swift-ci please test |
|
@swift-ci please test Windows platform |
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 issuewith cross-module protocol conformances.
Fixes: SR-14807
Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.
Resolves SR-NNNN.