Skip to content

Fix metadata availability testing for parameterized existentials and implement it for @isolated(any) function types #71970

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Mar 1, 2024

Conversation

rjmccall
Copy link
Contributor

The existing testing was pretty broken: we were diagnosing all sorts of things that don't require type metadata (like using a tuple with an extended existential in a value position in an API signature) and not diagnosing several things that do (like covariant function conversions that erase types). There's therefore some risk to this patch, but I'm not too worried because needing metadata like this is pretty uncommon, and it's likely that programs won't build correctly anyway --- it'll just get caught by the linker instead of the compiler.

@rjmccall
Copy link
Contributor Author

@swift-ci Please test

@rjmccall rjmccall force-pushed the isolated-any-availability branch from 5617f32 to 8a2556a Compare February 29, 2024 08:00
@rjmccall
Copy link
Contributor Author

@swift-ci Please test

@rjmccall
Copy link
Contributor Author

@swift-ci Please test

@ahoppen ahoppen removed their request for review February 29, 2024 23:38
and implement it for @isolated(any) function types.

The existing testing was pretty broken: we were diagnosing all sorts
of things that don't require type metadata (like using a tuple with
an extended existential in a value position in an API signature)
and not diagnosing several things that do (like covariant function
conversions that erase types).  There's therefore some risk to this
patch, but I'm not too worried because needing metadata like this is
pretty uncommon, and it's likely that programs won't build correctly
anyway --- it'll just get caught by the linker instead of the compiler.
@rjmccall rjmccall force-pushed the isolated-any-availability branch from 75638e9 to 0f076c0 Compare March 1, 2024 03:14
@rjmccall
Copy link
Contributor Author

rjmccall commented Mar 1, 2024

@swift-ci Please test

@rjmccall rjmccall merged commit 237dd4f into swiftlang:main Mar 1, 2024
@rjmccall rjmccall deleted the isolated-any-availability branch March 1, 2024 09:11
@kateinoigakukun
Copy link
Member

It seems like the first flag argument of swift_getExtendedFunctionTypeMetadata is somehow represented as i64 on 32-bit arch 🤔 As far as I checked, the argument is constructed as SizeTy, so I'm not sure what makes it to be i64.

https://ci.swift.org/job/oss-swift-pr-test-crosscompile-wasm-ubuntu-20_04/66/

/home/build-user/swift/test/IRGen/isolated_any_metadata.sil:24:20: error: CHECK-ACCESSOR: expected string not found in input
// CHECK-ACCESSOR: call ptr @swift_getExtendedFunctionTypeMetadata([[INT]] 2214592512, [[INT]] 0, ptr null, ptr null, ptr getelementptr inbounds {{.*}} @"$sytN"{{.*}}), ptr null, i32 2, ptr null)
                   ^
<stdin>:28:73: note: scanning from here
define linkonce_odr hidden swiftcc %swift.metadata_response @"$syyYAcMa"(i64 %0) #1 {
                                                                        ^
<stdin>:28:73: note: with "INT" equal to "i32"
define linkonce_odr hidden swiftcc %swift.metadata_response @"$syyYAcMa"(i64 %0) #1 {
                                                                        ^
<stdin>:28:73: note: with "INT" equal to "i32"
define linkonce_odr hidden swiftcc %swift.metadata_response @"$syyYAcMa"(i64 %0) #1 {
                                                                        ^
<stdin>:35:5: note: possible intended match here
 %3 = call ptr @swift_getExtendedFunctionTypeMetadata(i64 2214592512, i64 0, ptr null, ptr null, ptr getelementptr inbounds (%swift.full_existential_type, ptr @"$sytN", i32 0, i32 1), ptr null, i32 2, ptr null) #2
    ^

MaxDesiatov pushed a commit that referenced this pull request Mar 1, 2024
The test was failing on the Wasm CI because `%IRGenFileCheck` is configured for the target platform (in this case wasm32-unknown-wasi), but the test used it to check the output for other platforms. The mismatch was not revealed on the other CI because they are all 64-bit, but the 32-bit Wasm CI revealed it. https://ci.swift.org/job/oss-swift-pr-test-crosscompile-wasm-ubuntu-20_04/66/

Adjust a test case added by #71970 to repair Wasm CI
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants