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

Versions 0.4.1 to 0.4.4 fail to compile #56

Open
Finomnis opened this issue Sep 15, 2022 · 5 comments
Open

Versions 0.4.1 to 0.4.4 fail to compile #56

Finomnis opened this issue Sep 15, 2022 · 5 comments
Labels
help wanted maintenance Keeping the wheels turning

Comments

@Finomnis
Copy link

Finomnis commented Sep 15, 2022

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:
@Finomnis Finomnis changed the title Version 0.4.1 to 0.4.4 fails to compile Versions 0.4.1 to 0.4.4 fail to compile Sep 15, 2022
@shepmaster
Copy link
Owner

shepmaster commented Sep 15, 2022

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
Copy link
Owner

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.

@shepmaster shepmaster added help wanted maintenance Keeping the wheels turning labels Sep 15, 2022
@Finomnis
Copy link
Author

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
Copy link
Author

Finomnis commented Sep 15, 2022

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
Copy link

BurntSushi commented Sep 15, 2022

@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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted maintenance Keeping the wheels turning
Projects
None yet
Development

No branches or pull requests

3 participants