-
Notifications
You must be signed in to change notification settings - Fork 11
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
Fix i686 host builds #34
Conversation
In the generator, we have ```rust pub fn smallest_index(n: usize) -> usize { for &x in [8, 16, 32].iter() { if n < (1 << x) { return x / 8; } } 64 } ``` where `x` is inferred to be `usize`. When the host architecture is 32-bits, `(1 << x)` overflows. For release build, this doesn't crash but leads to strange invalid generated.rs which contain an undefined `u512` type (https://github.com/astral-sh/ruff/actions/runs/6500014395/job/17659540717). Note that the crash only happens on i686 hosts (i used the quay.io/pypa/manylinux2014_i686 docker container), if you're cross compiling build scripts are compiled to the host architecture and the build works fine. This change fixes this by instead pinning types to 4 bytes max, which seems sufficient. I only changed this specific `usize` that unbreaks the build, but there are more `usize` usages in the generator that might be problematic that i haven't checked.
See progval/unicode_names2#34 for a detailed explanation. Fixes https://github.com/astral-sh/ruff/actions/runs/6500014395/job/17659540717 and should unblock astral-sh/astral-sh#44
See progval/unicode_names2#34 for a detailed explanation. Fixes https://github.com/astral-sh/ruff/actions/runs/6500014395/job/17659540717 and should unblock astral-sh/astral-sh#44
} | ||
} | ||
64 |
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.
was this line unreachable?
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.
I think it must have been, it's definitely incorrect in the old version, it should have been 8 and not 64. (I think this also explains why we saw a u512
in the broken build, we got u{64 * 8}
)
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.
Just realized we can actually know that it is unreachable: The only caller was smallest_type
, which takes a Iterator<Item = u32>
, and all u32
are guaranteed to be smaller than (1 << 32)
.
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.
looks like it was useful at some point... 1758fb8#diff-02c0d6c94c0983e9e9b8f82b36f950fafe18bb071f64faf825bfef437d66dbec
Thanks for the PR, I imagine this wasn't easy to debug |
See progval/unicode_names2#34 for a detailed explanation. Fixes https://github.com/astral-sh/ruff/actions/runs/6500014395/job/17659540717 and should unblock astral-sh/astral-sh#44
Pushed to crates.io as v1.2.0 (cc @chris-ha458) |
We can remove the git dependency (again). See progval/unicode_names2#34 (comment)
We can remove the git dependency (again). See progval/unicode_names2#34 (comment) I'll run the release pipeline before merging.
In the generator, we have
where
x
is inferred to beusize
. When the host architecture is 32-bits,(1 << x)
overflows. For release build, this doesn't crash but leads to strange invalid generated.rs which contain an undefinedu512
type (https://github.com/astral-sh/ruff/actions/runs/6500014395/job/17659540717). Note that the crash only happens on i686 hosts (i used the quay.io/pypa/manylinux2014_i686 docker container), if you're cross compiling build scripts are compiled to the host architecture and the build works fine.This change fixes this by instead pinning types to 4 bytes max, which seems sufficient. I only changed this specific
usize
that unbreaks the build, but there are moreusize
usages in the generator that might be problematic that i haven't checked.