Skip to content
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

Open
xwu opened this issue Mar 2, 2021 · 6 comments
Open
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@xwu
Copy link
Collaborator

xwu commented Mar 2, 2021

Previous ID SR-14294
Radar rdar://problem/74938482
Original Reporter @xwu
Type Bug
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug
Assignee None
Priority Medium

md5: 0cefa8806c0435365e31f23452b0bd0f

Issue Description:

In SE-0213, Int32(42) was made equivalent to 42 as Int32. It is also said that this behavior can be avoided by using an explicit syntax:

This behavior could be avoided by spelling initializer call verbosely e.g. UInt32.init(42).

The latter behavior is (at least now) broken:

UInt(-1.0)
// Compile-time error:
// negative literal '-1.0' cannot be converted to 'UInt'

let x = -1.0
UInt(x)
// Runtime error:
// Double value cannot be converted to UInt because the result would be less than UInt.min

UInt.init(-1.0)
// Expected: runtime error, as above
// Actual: compile-time error:
// negative literal '-1.0' cannot be converted to 'UInt'

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, writing UInt.init doesn't invoke the expected initializer, so we don't end up testing the initializer we intend to!

@xwu
Copy link
Collaborator Author

xwu commented Mar 2, 2021

cc @xedin

@xedin
Copy link
Member

xedin commented Mar 2, 2021

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.

@typesanitizer
Copy link

@swift-ci create

@swift-ci
Copy link
Collaborator

swift-ci commented Mar 3, 2021

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)

@swift-ci
Copy link
Collaborator

swift-ci commented Mar 3, 2021

Comment by Ravichandhran Kandhadai Madhavan (JIRA)

let x = -1.0
UInt( x )
I am not completely sure why this is not a compile-time error. I do remember some cases where the constant-folding diagnostics couldn't look into the implementation of some initializers that weren't transparent. But, if the same initializers are picked in both cases, then the error should be emitted. That is something to investigate. Thanks for reporting it!

@xwu
Copy link
Collaborator Author

xwu commented Mar 6, 2021

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.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself
Projects
None yet
Development

No branches or pull requests

4 participants