[test] Adjust api-digester/dump-module.swift for rebranch
#84193
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The API digester queries the top-level declarations for the Swift module `cake`. The first file in that module is a `ClangModuleUnit`, so we proceed to import that file into Swift. The clang importer fetches the lookup table, then looks up and imports everything in it. rebranch: 1. The lookup table ends up containing `__Int64x2_t`, a new "neon vector type". These are not built-in types, but neither are they declared anywhere. You express them using an attribute combined with an integral type, e.g. `__attribute__((neon_vector_type(8))) int8_t`. For whatever reason, these types are for AArch64 only, which explains why we don't see the test failure on x86 runners. 2. The neon vector type is imported via `SwiftTypeConverter::VisitVectorType`, where we use `NominalTypeDecl::lookupConformance` to verify that the vector type's element type (imported as `Int` in this case) conforms to `SIMDScalar`. 3. Conformance lookup triggers extension loading. Because we haven't added any extensions to `Int` yet, and the standard library happens to come before `cake` in the list of module loaders, extensions from `cake` are added last. main: 1. No neon vector types, so we happen not to look up `Int`'s conformances during importation of `cake.h`. 2. The next file is `cake.swift`. In the process of deserializing the AST for that file, we encounter `Int` extensions and add them to the nominal. Eventually, while processing the collected top-level declarations, the API digester calls `getAllConformances` on `Int`, and we see a difference in the index of `P1` between main and rebranch because conformances from extensions are added to the table in the order those extensions were added to the nominal.
|
@swift-ci please test Apple Silicon |
AnthonyLatsis
added a commit
that referenced
this pull request
Sep 11, 2025
I missed that #84193 would break the test on x86. This makes the expected output is arch-dependent.
This was referenced Sep 12, 2025
|
Reverted in #84257. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The API digester queries the top-level declarations for the Swift module
cake. The first file in that module is aClangModuleUnit, so we proceed to import that file into Swift. The clang importer fetches the lookup table, then looks up and imports everything in it.rebranch:
__Int64x2_t, a new "neon vector type". These are not built-in types, but neither are they declared anywhere. You express them using an attribute combined with an integral type, e.g.__attribute__((neon_vector_type(8))) int8_t. For whatever reason, these types are for AArch64 only, which explains why we don't see the test failure on x86 runners.SwiftTypeConverter::VisitVectorType, where we useNominalTypeDecl::lookupConformanceto verify that the vector type's element type (imported asIntin this case) conforms toSIMDScalar.Intyet, and the standard library happens to come beforecakein the list of module loaders, extensions fromcakeare added last.main:
Int's conformances during importation ofcake.h.cake.swift. In the process of deserializing the AST for that file, we encounterIntextensions and add them to the nominal.Eventually, while processing the collected top-level declarations, the API digester calls
getAllConformancesonInt, and we see a difference in the index ofP1between main and rebranch because conformances from extensions are added to the table in the order those extensions were added to the nominal.