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

semfold: fix conversion folding #823

Merged

Conversation

zerbina
Copy link
Collaborator

@zerbina zerbina commented Aug 1, 2023

Summary

Make the logic handling folding of integer- and float-like conversion
more exhaustive and slightly simplify it. This fixes the internal issue
of literal-nodes having unexpected types, and it also fixes no range
error being reported at compile-time for some to-char conversion.

Details

Folding conversions to integer, float, and bool types now considers all
valid source types, with unexpected types now being treated as a defect
instead of silently ignoring them. Named set constants are used for
this, with tyChar being included in the integer-like set, meaning that
to-char conversions are now properly subjected to range checks during
constant folding.

For the integer-like branch handling, the logic is simplified to only
perform the range check in a single place, and the unnecessary
transition-to-nkUIntLit removed (newIntNodeType already makes sure
that the node has the correct kind based on the type).

In general, this is a step towards the type of a literal-node matching
its kind. Both the C and VM code generator use the node kind for
deciding whether a float literal is a 32-bit or 64-bit one, so the
float-literal-nodes produced by constant folding now having the correct
kind fixes a bug where the emitted float literals had the wrong target-
language type (see the fixed test tfloats.nim).

The logic for to-integer and to-float conversions now uses exhaustive
case statements, which fixes both an internal issue with unexpected
literal-node types and conversions-to-char not having range checks.
Perform the range check in a single place. In addition, don't transition
unsigned-valued nodes to `nkUIntLit` -- there's no reason to.
One of the issues encountered in the tests is now fixed. The test case
for `1.23456789012345'f32` was already working previously.
@zerbina zerbina added bug Something isn't working refactor Implementation refactor compiler/sem Related to semantic-analysis system of the compiler labels Aug 1, 2023
Copy link
Collaborator

@saem saem left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll try a regular build that tomorrow, IIRC these were one of the issues. 👍🏽

@zerbina
Copy link
Collaborator Author

zerbina commented Aug 2, 2023

I've reverted the unrelated change to the test such that there are no merge conflicts with #824.

@saem
Copy link
Collaborator

saem commented Aug 2, 2023

/merge

@github-actions
Copy link

github-actions bot commented Aug 2, 2023

Merge requested by: @saem

Contents after the first section break of the PR description has been removed and preserved below:


Notes for reviewers

@chore-runner chore-runner bot added this pull request to the merge queue Aug 2, 2023
Merged via the queue into nim-works:devel with commit 89adfe1 Aug 3, 2023
18 checks passed
@zerbina zerbina deleted the fix-int-float-conversion-folding branch August 6, 2023 21:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working compiler/sem Related to semantic-analysis system of the compiler refactor Implementation refactor
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants