Build fails on 32-bit systems

[cinerea0]

While attempting to build scryer in CI, the build for i686 failed. Here's the error I encountered:

error[E0080]: evaluation of constant value failed
  --> src/atom_table.rs:22:1
   |
22 | const_assert!(mem::size_of::<Atom>() == 8);
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ attempt to compute `0_usize - 1_usize`, which would overflow
   |
   = note: this error originates in the macro `const_assert` (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0080]: evaluation of constant value failed
   --> src/arena.rs:459:1
    |
459 | const_assert!(mem::size_of::<AllocSlab>() == 16);
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ attempt to compute `0_usize - 1_usize`, which would overflow
    |
    = note: this error originates in the macro `const_assert` (in Nightly builds, run with -Z macro-backtrace for more info)
For more information about this error, try `rustc --explain E0080`.

This brought me to the following line of code: https://github.com/mthom/scryer-prolog/blob/master/src/atom_table.rs#L22. This prohibits building on 32-bit systems due to the smaller usize. Is this intentional because there are parts of scryer that don't work on 32-bit systems?

[triska]

Scryer needs 64 bits for its representation of WAM cells, see for example: #908 (comment)

[ericonr]

If the representation needs to be 64 bits, is there a reason it can't use u64 instead of usize?

[triska]

If that makes it possible to use Scryer Prolog on 32-bit systems, and at the same time has no significant performance downsides on 64-bit systems, then I think this would be an awesome solution!

[classabbyamp]

there would be no effect, probably, because usize is a u64 already on 64-bit systems

[triska]

Scryer's memory management needs 64 bits to represent a WAM cell, so it needs u64 in all systems where we want it to run. On 32-bit systems, usize is u32, so using usize does not work there, even though it coincidentally works on 64-bit systems.

[classabbyamp]

Right, so switching usize to u64 would incur no penalty to existing 64bit and have the added benefit of supporting 32bit

[triska]

@rujialiu has impressively resolved this via #1972, could you please try it, and if possible re-enable the 32-bit target (void-linux/void-packages#37478) and close this issue if this now works for you? Thank you a lot!

[cinerea0]

I can confirm this has been fixed in the latest release due to the incredible efforts of @rujialiu; build logs in this PR: void-linux/void-packages#45861. Also, since this project no longer depends on gmp, we were able to enable crossbuilds. Closing now, thank you again!