Versions 0.4.1 to 0.4.4 fail to compile

[Finomnis]

This problem first got reported here: PoiScript/docx-rs#51

A StackOverflow post made this problem resurface: https://stackoverflow.com/questions/73722833/cannot-perform-const-operation-using-t

It seems that on some machines, version 0.4.1 through 0.4.4 fail to compile.

How to reproduce

• cargo new test_project
• cd test_project
• Add jetscii = "=0.4.4" to your Cargo.toml
• cargo build

Outputs:

• jetscii = "=0.4.0":

> cargo build
   Compiling jetscii v0.4.0
   Compiling test_project v0.1.0 (/home/finomnis/work/test_project)
    Finished dev [unoptimized + debuginfo] target(s) in 2.86s

• jetscii = "=0.4.1":

> cargo build
   Compiling jetscii v0.4.1
error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.1/src/simd.rs:111:13
    |
111 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.1/src/simd.rs:118:13
    |
118 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.1/src/simd.rs:151:13
    |
151 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.1/src/simd.rs:158:13
    |
158 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: could not compile `jetscii` due to 4 previous errors

• jetscii = "=0.4.2":

> cargo build
   Compiling jetscii v0.4.2
error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.2/src/simd.rs:111:13
    |
111 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.2/src/simd.rs:118:13
    |
118 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.2/src/simd.rs:158:13
    |
158 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.2/src/simd.rs:165:13
    |
165 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: could not compile `jetscii` due to 4 previous errors

• jetscii = "=0.4.3":

> cargo build
   Compiling jetscii v0.4.3
error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.3/src/simd.rs:109:13
    |
109 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.3/src/simd.rs:148:13
    |
148 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: could not compile `jetscii` due to 2 previous errors

• jetscii = "=0.4.4":

> cargo build
   Compiling jetscii v0.4.4
error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.4/src/simd.rs:109:13
    |
109 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.4/src/simd.rs:148:13
    |
148 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: could not compile `jetscii` due to 2 previous errors

• jetscii = "=0.5.0":

> cargo build
   Compiling jetscii v0.5.0
   Compiling test_project v0.1.0 (/home/finomnis/work/test_project)
    Finished dev [unoptimized + debuginfo] target(s) in 2.08s

Solution

Sadly, this will probably involving yanking versions 0.4.1, 0.4.2, 0.4.3 and 0.4.4. :/

My System

I'm running a Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz on WSL2 on Windows 11.

cat /etc/lsb-release:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.5 LTS"

rustup show:

Default host: x86_64-unknown-linux-gnu
rustup home:  /home/finomnis/.rustup

installed toolchains
--------------------

stable-x86_64-unknown-linux-gnu (default)
nightly-2022-08-03-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu

installed targets for active toolchain
--------------------------------------

thumbv6m-none-eabi
wasm32-wasi
x86_64-unknown-freebsd
x86_64-unknown-linux-gnu

active toolchain
----------------

stable-x86_64-unknown-linux-gnu (default)
rustc 1.63.0 (4b91a6ea7 2022-08-08)

cat /proc/cpuinfo:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 61
model name      : Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
stepping        : 4
microcode       : 0xffffffff
cpu MHz         : 2194.918
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 20
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi ept vpid ept_ad fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap xsaveopt flush_l1d arch_capabilities
vmx flags       : vnmi invvpid ept_x_only ept_ad ept_1gb tsc_offset vtpr ept vpid unrestricted_guest
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds
bogomips        : 4389.83
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 61
model name      : Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
stepping        : 4
microcode       : 0xffffffff
cpu MHz         : 2194.918
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 20
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi ept vpid ept_ad fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap xsaveopt flush_l1d arch_capabilities
vmx flags       : vnmi invvpid ept_x_only ept_ad ept_1gb tsc_offset vtpr ept vpid unrestricted_guest
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds
bogomips        : 4389.83
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 61
model name      : Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
stepping        : 4
microcode       : 0xffffffff
cpu MHz         : 2194.918
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 1
cpu cores       : 2
apicid          : 2
initial apicid  : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 20
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi ept vpid ept_ad fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap xsaveopt flush_l1d arch_capabilities
vmx flags       : vnmi invvpid ept_x_only ept_ad ept_1gb tsc_offset vtpr ept vpid unrestricted_guest
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds
bogomips        : 4389.83
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 61
model name      : Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
stepping        : 4
microcode       : 0xffffffff
cpu MHz         : 2194.918
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 1
cpu cores       : 2
apicid          : 3
initial apicid  : 3
fpu             : yes
fpu_exception   : yes
cpuid level     : 20
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi ept vpid ept_ad fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap xsaveopt flush_l1d arch_capabilities
vmx flags       : vnmi invvpid ept_x_only ept_ad ept_1gb tsc_offset vtpr ept vpid unrestricted_guest
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds
bogomips        : 4389.83
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

[shepmaster]

version 0.4.1 through 0.4.4 fail to compile.

Yes, that's caused by #39. TL;DR, older versions of Rust exposed the SIMD intrinsics in one way, that was changed, and a small number of crates (such as Jetscii) were affected. Jetscii was changed and a new version was released — technically semver incompatible.

yanking versions

I am not inclined to do that because I don't believe that will help matters at all (and may make it worse in some cases).

Right now:

• Someone is using SIMD with 0.4.x and an old compiler -- it compiles
• Someone is using SIMD with 0.4.x and an new compiler -- it fails to compile
• Someone is using non-SIMD with 0.4.x and a new compiler -- it compiles
• Someone is using 0.5.x with a new compiler -- it compiles

After yanking 0.4.x:

• Someone is using SIMD with 0.4.x and an old compiler -- it fails to compile
• Someone is using SIMD with 0.4.x and an new compiler -- it fails to compile
• Someone is using non-SIMD with 0.4.x and a new compiler -- it fails to compile
• Someone is using 0.5.x with a new compiler -- it compiles

Additionally, if someone has 0.4.x in their lockfile, yanking will do nothing and they will continue to be in the same state. Only when they remove the lockfile will they experience the problem.

Can you clarify how you see yanking the old versions improving the situation?

[shepmaster]

a new version was released — technically semver incompatible.

If you have a proposal for a semver compatible implementation of 0.4.x that compiles with modern Rust, then we could release a 0.4.5 that would solve the problem.

[Finomnis]

Yah, releasing a 0.4.5 probably makes more sense. I don't know enough about the project, though, tbh :/ I just encountered this in a SO discussion and didn't see an open issue, so I decided to report it.

The solution for the problem in SO would be that the docx crate updates to jetscii 0.5.x, but of course we can't enforce that. So I thought yanking old versions would increase the pressure for other crates to update. But you are of course right that an update with a fix is much preferred to a forced downgrade. My bad.

[Finomnis]

I'm honestly a little disappointed in the Rust compiler that this doesn't compile any more; I was under the impression that the entire rolling release thing of the Rust compiler is based on guaranteed backwards compatibility.

[BurntSushi]

@Finomnis This is one of those rare cases where a new Rust release broke stable code outside of soundness fixes or as part of standard API evolution. There have been a couple other instances of it, but it's overall pretty rare. As @shepmaster linked, see #39 for more context there. (And that PR links to the upstream threads that discusses the change in detail.)