transpile: tests: add out_of_range_int.c test
#1436
Conversation
… is 2^31 This is from `libmcs` and is currently broken.
kkysen
force-pushed
the
kkysen/out-of-range-int
branch
from
36d829e to
d1799d6
Compare
|
Ah, my bad re: 7eaa39f not compiling--it depends on 67e6eeb but got reordered prior to it during cleanup of that PR. I believe the problem here is referenced by the doc comment for
For fixed-size types like |
kkysen
left a comment
kkysen
left a comment
There was a problem hiding this comment.
for types like
libc::c_intwe need to be able to determine the bounds forinton the target platform.
See #1442 now, but I chose to use the narrowest bound for platform-dependent types like int so that the resulting code works on all platforms.
|
* Fixes #1435. * Supersedes #1436. This first reverts the part of 7eaa39f that broke #1435, which is omitting casts from literals where the type already matches without checking if the literal is within that type's range. Then tests are added and then `fn literal_kind_matches_ty` is fixed to also check the type's range. If the literal may be out of range on any possible platform, then a cast remains. I didn't add a float to these tests since floats go through a different code path (there's no cast generated for them). So for them, we need to explicitly generate a cast if it's out of range.
A test for #1435. It was broken by #1266 (specifically, 7eaa39f, which also doesn't compile). It seems we're not handling the
Usuffix, which requires a temporary cast toc_uintbefore getting coerced toint32_t/i32.4a4c0cc is the current snapshot, while 36d829e is what it was before #1266, which still compiles.