-
Notifications
You must be signed in to change notification settings - Fork 105
Suppress warning about #require(nonOptional)
in some cases.
#947
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
Suppress warning about #require(nonOptional)
in some cases.
#947
Conversation
When using `try #require()` to unwrap an optional value, we emit a compile-time warning if the value is not actually optional. However, there is a bug in the type checker (swiftlang/swift#79202) that triggers a false positive when downcasting an object (of `class` type), e.g.: ```swift class Animal {} class Duck: Animal {} let beast: Animal = Duck() let definitelyADuck = try #require(beast as? Duck) //⚠️ '#require(_:_:)' is redundant because 'beast as? Duck' never equals 'nil' ``` This change suppresses the warning we emit if the expression contains certain syntax tokens (namely `?`, `nil`, or `Optional`) on the assumption that their presence means the test author is expecting an optional value and we've hit a false positive.
@swift-ci test |
Is there an additional test you could add which would be an expected failure right now, but pass once swiftlang/swift#79202 is resolved? |
No, because I don't have a way to trigger the mismatch except during macro expansion, which is faked (different macro overloads get different names.) |
When using `try #require()` to unwrap an optional value, we emit a compile-time warning if the value is not actually optional. However, there is a bug in the type checker (swiftlang/swift#79202) that triggers a false positive when downcasting an object (of `class` type), e.g.: ```swift class Animal {} class Duck: Animal {} let beast: Animal = Duck() let definitelyADuck = try #require(beast as? Duck) //⚠️ '#require(_:_:)' is redundant because 'beast as? Duck' never equals 'nil' ``` This change suppresses the warning we emit if the expression contains certain syntax tokens (namely `?`, `nil`, or `Optional`) on the assumption that their presence means the test author is expecting an optional value and we've hit a false positive. ### Checklist: - [x] Code and documentation should follow the style of the [Style Guide](https://github.com/apple/swift-testing/blob/main/Documentation/StyleGuide.md). - [x] If public symbols are renamed or modified, DocC references should be updated.
…949) - **Explanation**: Suppress some warnings that occur due to swiftlang/swift#79202 when the compiler selects the wrong overload of `try #require()` for expansion. - **Scope**: Tests using `try #require()` with reference types. - **Issues**: works around swiftlang/swift#79202 - **Original PRs**: #947 - **Risk**: Low, just suppresses some warnings we generate (lack of these warnings is not harmful) - **Testing**: Added a unit test - **Reviewers**: @briancroom
When using
try #require()
to unwrap an optional value, we emit a compile-time warning if the value is not actually optional. However, there is a bug in the type checker (swiftlang/swift#79202) that triggers a false positive when downcasting an object (ofclass
type), e.g.:This change suppresses the warning we emit if the expression contains certain syntax tokens (namely
?
,nil
, orOptional
) on the assumption that their presence means the test author is expecting an optional value and we've hit a false positive.Checklist: