Constant-related build errors on 32-bit platforms
thombles opened this issue · 3 comments
tracing: 6d8b995c99f1d7b8758da687e5b7df25456f9559
This commit has tracing-subscriber
depending on sharded-slab
0.0.6
When building tracing-subscriber
for a 32 bit target, e.g. cargo build --target i686-linux-android
, this results in build errors in sharded-slab
code.
Compiling sharded-slab v0.0.6
...
Compiling tracing-subscriber v0.2.0-alpha.1 (/Users/tk/repos/tracing/tracing-subscriber)
error[E0080]: could not evaluate constant
--> /Users/tk/.cargo/registry/src/github.com-1ecc6299db9ec823/sharded-slab-0.0.6/src/page/slot.rs:54:24
|
54 | const LEN: usize = (cfg::WIDTH - C::RESERVED_BITS) - Self::SHIFT;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ attempt to subtract with overflow
error[E0080]: could not evaluate constant
--> /Users/tk/.cargo/registry/src/github.com-1ecc6299db9ec823/sharded-slab-0.0.6/src/lib.rs:691:26
|
691 | let shift = 1 << (Self::LEN - 1);
| ^^^^^^^^^^^^^^^ referenced constant has errors
error[E0080]: could not evaluate constant
--> /Users/tk/.cargo/registry/src/github.com-1ecc6299db9ec823/sharded-slab-0.0.6/src/cfg.rs:40:30
|
40 | const USED_BITS: usize = Generation::<Self>::LEN + Generation::<Self>::SHIFT;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ referenced constant has errors
error[E0080]: could not evaluate constant
--> /Users/tk/.cargo/registry/src/github.com-1ecc6299db9ec823/sharded-slab-0.0.6/src/cfg.rs:142:34
|
142 | .field("used_bits", &C::USED_BITS)
| ^^^^^^^^^^^^ referenced constant has errors
error[E0080]: could not evaluate constant
--> /Users/tk/.cargo/registry/src/github.com-1ecc6299db9ec823/sharded-slab-0.0.6/src/lib.rs:704:25
|
704 | const MASK: usize = Self::BITS << Self::SHIFT;
| ^^^^^^^^^^^^^^^^^^^^^^^^^ referenced constant has errors
error[E0080]: could not evaluate constant
--> /Users/tk/.cargo/registry/src/github.com-1ecc6299db9ec823/sharded-slab-0.0.6/src/page/slot.rs:560:24
|
560 | const LEN: usize = Generation::<C>::LEN;
| ^^^^^^^^^^^^^^^^^^^^ referenced constant has errors
error[E0080]: could not evaluate constant
--> /Users/tk/.cargo/registry/src/github.com-1ecc6299db9ec823/sharded-slab-0.0.6/src/page/slot.rs:495:37
|
495 | const LEN: usize = cfg::WIDTH - (Lifecycle::<C>::LEN + Generation::<C>::LEN);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ referenced constant has errors
error[E0080]: could not evaluate constant
--> /Users/tk/.cargo/registry/src/github.com-1ecc6299db9ec823/sharded-slab-0.0.6/src/lib.rs:699:26
|
699 | const SHIFT: usize = Self::Prev::SHIFT + Self::Prev::LEN;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ referenced constant has errors
error: aborting due to 8 previous errors
For more information about this error, try `rustc --explain E0080`.
error: could not compile `tracing-subscriber`.
I think the default MAX_THREADS value is way too high on 32-bit platforms — it is currently half of the 64-bit MAX_THREADS. On 64-bit targets, MAX_THREADS is 4096 (12 bits), and on 32-bit, it's 2048 (11 bits). It should be half as many bits, not half as high a number
Also both of those values should be one less, since 0 is a valid thread ID.
@thombles I think the reason that this crate builds for you but tracing-subscriber
(which depends on it) does not is that building the lib never actually evaluated the default config. I think that trying to build this crate's tests for a 32-bit target should fail?
Can I get you to do the following:
- try to
cargo build --test
for a 32-bit target, and confirm that it fails - check out this branch
- try building the tests for a 32-bit target again and let me know if that branch fixes it?
Thanks! I don't currently have a 32-bit toolchain installed, so I figured I'd ask you to check it out.
Using the eliza/fix-max-threads-bits
branch of sharded-slab
I can successfully build both this crate, and tracing-subscriber
, using the i686-linux-android
target. 🎉
In terms of your specific instructions it's a bit more complicated.
Can I get you to do the following:
- try to
cargo build --test
for a 32-bit target, and confirm that it fails
It does fail, but not for the same reason - the loom
dev dependency pulls in generator
which currently only supports a handful of 64-bit architectures with its assembly.
- check out this branch
- try building the tests for a 32-bit target again and let me know if that branch fixes it?
It doesn't help with the generator issue of course. But it has solved my actual problem!