Skip to content

Gracefully handle incorrect SwiftName arg count #78124

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 1 commit into from
Feb 12, 2025

Conversation

beccadax
Copy link
Contributor

…at least in the specific case of initializers.

Normally, clang validates that a SwiftNameAttr’s specified name seems to have the right number of argument labels for the declaration it’s applied to; if it doesn’t, it diagnoses and drops the attribute. However, this checking isn’t perfect because clang doesn’t know all of Clang Importer’s throwing rules. The upshot is that it’s possible to get a mismatched SwiftNameAttr into Clang Importer if the last parameter looks like an out parameter. This trips an assertion in asserts compilers, but release compilers get past that and don’t seem to notice the mismatch at all.

Add code to the compiler to tolerate this condition, at least in initializers, by modifying the Swift name to have the correct number of argument labels and deprecating the declaration with a message explaining the problem.

Fixes rdar://141124373.

@beccadax
Copy link
Contributor Author

@swift-ci smoke test

@shahmishal
Copy link
Member

@swift-ci smoke test

@shahmishal
Copy link
Member

/Users/ec2-user/jenkins/workspace/swift-PR-macos-smoke-test/branch-main/swift/lib/ClangImporter/ImportDecl.cpp:6759:9: error: use of undeclared identifier 'PlatformAgnosticAvailabilityKind'
        PlatformAgnosticAvailabilityKind::Deprecated);
        ^
/Users/ec2-user/jenkins/workspace/swift-PR-macos-smoke-test/branch-main/swift/lib/ClangImporter/ImportDecl.cpp:6757:32: error: no member named 'createPlatformAgnostic' in 'swift::AvailableAttr'
    auto attr = AvailableAttr::createPlatformAgnostic(Impl.SwiftContext,
                ~~~~~~~~~~~~~~~^
2 errors generated.

…at least in the specific case of initializers.

Normally, clang validates that a SwiftNameAttr’s specified name seems to have the right number of argument labels for the declaration it’s applied to; if it doesn’t, it diagnoses and drops the attribute. However, this checking isn’t perfect because clang doesn’t know all of Clang Importer’s throwing rules. The upshot is that it’s possible to get a mismatched SwiftNameAttr into Clang Importer if the last parameter looks like an out parameter. This trips an assertion in asserts compilers, but release compilers get past that and don’t seem to notice the mismatch at all.

Add code to the compiler to tolerate this condition, at least in initializers, by modifying the Swift name to have the correct number of argument labels and deprecating the declaration with a message explaining the problem.

Fixes rdar://141124373.
@beccadax
Copy link
Contributor Author

@swift-ci please test

@beccadax beccadax enabled auto-merge February 12, 2025 01:39
@beccadax beccadax merged commit 7a7e6c2 into swiftlang:main Feb 12, 2025
4 of 5 checks passed
@shahmishal
Copy link
Member

Can we cherry-pick this into release/6.1 branch?

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.

3 participants