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
[SR-14294] Explicitly avoiding literal initialization via coercion is broken #56653
Comments
cc @xedin |
This is not actually a type-checker issue, `UInt.init(-1.0)` does type-check and picks `(Double) -> UInt` initializer. I think it's SIL diagnostics which emit this error. /cc ravikandhadai (JIRA User) Edit: All three examples type-check successfully and use `(Double) -> UInt` initializer. |
@swift-ci create |
Comment by Ravichandhran Kandhadai Madhavan (JIRA) As @xedin clarified, `UInt.init(-1.0)` is not treated as `(-1.0 as UInt)` and that's not the reason for the error. The error is emitted as `UInt.init(-1.0)` itself is incorrect. I believe that resolves this bug, right? Or, the request here is to disable the compiler error in these cases? If so, I guess it is separate question of whether we should support this syntactic way of suppressing the error. (We do have suppressions for warnings as there is possibility the code can function correctly, but here it looks like it's a definite error, right?). Also, if it is just for testing the implementation, it may be worth considering other options like passing flags like `disable-diagnostic-passes`. In fact, if the second example doesn't result in a compile-time error that may suffice to test the logic of the initializer (they must exercise the same code path, if I am not missing something). cc guitardog (JIRA User) |
Comment by Ravichandhran Kandhadai Madhavan (JIRA)
|
Thanks theindigamer (JIRA User) and ravikandhadai (JIRA User), this helps to clarify what's going on. But yes, the expectation would be that the second and third examples produce the same error, whether at runtime or compile time, although it's reassuring that the discrepancy doesn't arise due to the issue I thought it was. |
Additional Detail from JIRA
md5: 0cefa8806c0435365e31f23452b0bd0f
Issue Description:
In SE-0213,
Int32(42)
was made equivalent to42 as Int32
. It is also said that this behavior can be avoided by using an explicit syntax:The latter behavior is (at least now) broken:
This issue becomes salient when the goal is explicitly to test that the initializer in question behaves as intended when converting negative values (because, as it turns out, it has a bug converting
Float16
values to an unsigned integer type). However, with the present bug, writingUInt.init
doesn't invoke the expected initializer, so we don't end up testing the initializer we intend to!The text was updated successfully, but these errors were encountered: