transpile: fix out-of-range literals#1442
Merged
Merged
Conversation
efdb30b to
76e4cbc
Compare
fw-immunant
approved these changes
Nov 4, 2025
Contributor
fw-immunant
left a comment
There was a problem hiding this comment.
This looks good, modulo the one naming change mentioned inline.
It's unfortunate that without any knowledge of the target platform we can't have a nontrivial range for types like uintptr_t. But we would still need most of this infrastructure, just piping more information in (e.g. type limits for the current architecture), to know full ranges for all types in an architecture-dependent way. So let's merge this and leave the potential of following up with what's actually in range on this platform vs. what's guaranteed to be in range on all platforms.
Contributor
|
For CI, looks like a macOS snapshot needs updating. |
ahomescu
reviewed
Nov 15, 2025
ahomescu
reviewed
Nov 15, 2025
ahomescu
reviewed
Nov 15, 2025
c91d5ef to
94cfab4
Compare
ahomescu
approved these changes
Nov 20, 2025
This partially reverts 7eaa39f, "transpile: propagate expected types down to translation of literals". 7eaa39f, specifically the use of `fn literal_kind_matches_ty`, omits casts from literals where they are sometimes needed, breaking #1435. Before fixing it, this reverts the issue so that we can first add tests before fixing it.
94cfab4 to
cbf841b
Compare
… is 2^31 This is from `libmcs` and is currently broken (see #1435).
…in their type's range This fixes #1435. If a literal is within its type's range, then no explicit cast is needed, but otherwise, a cast is still needed. For fixed-width types, this is simple, but for platform-dependent types like `int`, this is trickier, as we don't know what platform the transpiled Rust will be compiled on. Thus, we use the narrowest ranges that are guaranteed to be valid for each type. On some platforms, this will result in an extra cast, but the same code will work on all platforms.
… the value, too, now
cbf841b to
c61b6ef
Compare
…in_range` regarding minimum ranges
…range` only works on integer/floats, respectively
…uaranteed_integer_in_range`
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
out_of_range_int.ctest #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_tyis 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.