-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Represent integer literals as IntLiteral
not as i32
.
#4532
Represent integer literals as IntLiteral
not as i32
.
#4532
Conversation
sized integer types. In preparation for changing integer literals to be of `IntLiteral` type. Conversions from the integer literal type are only permitted when the value fits within the destination type. For now, if conversion cannot be checked because the source value is a symbolic constant, produce a symbolic constant representing the conversion rather than rejecting it.
Don't hold a Function& after it may have been invalidated by importing.
In `if cond then 1 else 2`, convert to `i32`.
Depends on #4526. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally LG, pursuant to conversation about file size.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving but not merging. The changes here seem fine to me, and I think my one concern will be addressed through #4534.
When an
IntLiteral
appears as an operand of anif
expression, convert it toi32
for now, so that we don't reject things likeif cond then 1 else 2
due to having a non-constant value of typeIntLiteral
.For tuple indexing expressions such as
(a, b).0
, convert the index to typeIntLiteral
, not to typei32
. This isn't strictly necessary to do in this PR, but avoids the need to provide anIntLiteral
->i32
implicit conversion forno_prelude
tests using this syntax.