incremental compilation bug when shift left

[doki23]

Problem

fn main() {
    let a: i64 = 1 << 63;
}

It panicked:

thread 'main' panicked at 'attempt to shift left with overflow', src/main.rs:2:18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Steps

1. try shift left overflow like

fn main() {
    let a: i64 = 1 << 64;
}

and execute cargo run.
The compiler will complain "attempt to shift left by 64_i32, which would overflow".
2. change code to

fn main() {
    let a: i64 = 1 << 63;
}

and execute cargo run, it'll also panic.
3. cargo clean first and then cargo run, it'll succeed.

Possible Solution(s)

No response

Notes

No response

Version

rustup 1.25.2 (17db695f1 2023-02-01)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.67.1 (d5a82bbd2 2023-02-07)`

[ehuss]

Thanks for the report! Unfortunately I am unable to reproduce what you are seeing.

Can you run the following and post the entire output?

cargo new foo
cd foo
rm src/main.rs
echo "fn main() { let a: i64 = 1 << 64; }" > src/main.rs
cargo run
rm src/main.rs
echo "fn main() { let a: i64 = 1 << 63; }" > src/main.rs
CARGO_LOG=cargo::core::compiler::fingerprint=trace,cargo_util::paths=trace cargo run -v

Can you also provide the output of cargo -Vv?

[doki23]

BTW, I test it on my macbook m1.
I've found that it occasionally succeeds and occasionally fails.
If it succeed, you can try more times(constantly switching between 1 << 64 and 1 << 63) and it will fail finally.

➜  foo git:(master) ✗ rm src/main.rs
➜  foo git:(master) ✗ echo "fn main() { let a: i64 = 1 << 63; }" > src/main.rs
➜  foo git:(master) ✗ cargo run
   Compiling foo v0.1.0 (/Users/doki/FreeProjects/doki23-repo/test/foo)
warning: unused variable: `a`
 --> src/main.rs:1:17
  |
1 | fn main() { let a: i64 = 1 << 63; }
  |                 ^ help: if this is intentional, prefix it with an underscore: `_a`
  |
  = note: `#[warn(unused_variables)]` on by default

warning: `foo` (bin "foo") generated 1 warning
    Finished dev [unoptimized + debuginfo] target(s) in 0.10s
     Running `target/debug/foo`
thread 'main' panicked at 'attempt to shift left with overflow', src/main.rs:1:27
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The result of CARGO_LOG=cargo::core::compiler::fingerprint=trace,cargo_util::paths=trace cargo run -v is

[2023-02-18T15:10:29Z DEBUG cargo::core::compiler::fingerprint] fingerprint at: /Users/doki/FreeProjects/doki23-repo/test/foo/target/debug/.fingerprint/foo-4cf796f885ecebbb/bin-foo
[2023-02-18T15:10:29Z DEBUG cargo::core::compiler::fingerprint] max output mtime for "/Users/doki/FreeProjects/doki23-repo/test/foo" is "/Users/doki/FreeProjects/doki23-repo/test/foo/target/debug/deps/foo-4cf796f885ecebbb" 1676733021.046741560s
[2023-02-18T15:10:29Z DEBUG cargo::core::compiler::fingerprint] all paths up-to-date relative to "/Users/doki/FreeProjects/doki23-repo/test/foo/target/debug/.fingerprint/foo-4cf796f885ecebbb/dep-bin-foo" mtime=1676733020.944048052s
[2023-02-18T15:10:29Z DEBUG cargo::core::compiler::fingerprint] filesystem up-to-date "/Users/doki/FreeProjects/doki23-repo/test/foo"
       Fresh foo v0.1.0 (/Users/doki/FreeProjects/doki23-repo/test/foo)
[2023-02-18T15:10:29Z DEBUG cargo_util::paths] linking /Users/doki/FreeProjects/doki23-repo/test/foo/target/debug/deps/foo-4cf796f885ecebbb to /Users/doki/FreeProjects/doki23-repo/test/foo/target/debug/foo
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
     Running `target/debug/foo`
thread 'main' panicked at 'attempt to shift left with overflow', src/main.rs:1:27
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

cargo -Vv is

cargo 1.67.1 (8ecd4f20a 2023-01-10)
release: 1.67.1
commit-hash: 8ecd4f20a9efb626975ac18a016d480dc7183d9b
commit-date: 2023-01-10
host: aarch64-apple-darwin
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 7.79.1 (sys:0.4.59+curl-7.86.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 12.5.1 [64-bit]

[ehuss]

Thanks for the info! I was able to reproduce and it appears to be a bug in the compiler. I have opened rust-lang/rust#108216 to track it there.