no compilation error on impossible bitshift if not used

[NULLx76]

When creating a library that contains an impossible bitshift, e.g. 1u32 << 32

I expected to see this happen: the library doesn't compile.

Instead, this happened: the library compiles as long as the code is never used in the library but does fail to compile when used in another crate.

Other ways to fail compilation like compile_error! or let a: u8 = -5 do stop the library from compiling even when the code is not in use.

Meta

rustc version: rustc 1.63.0 (4b91a6ea7 2022-08-08)

minimal repro: https://github.com/jonay2000/compile-error-bug

[jdonszelmann]

We just tried some more examples. For explict integer overflow the same problem occurs:

255u8 + 1

will not fail to compile as long as it's not used anywhere. That means you could upload a library containing a public function with this in it, and you could publish the library while the code wouldn't compile for anyone trying to use it.

[jdonszelmann]

note that these expressions (255u8 + 1 or 1u32 << 32) already fail to compile when they are imported in another crate. They do not need to be used in the other crate.

While in the same crate, they compile when not used but don't compile when used (not eliminated as dead code)

[jdonszelmann]

So I have taken a look through the compiler. I'm a bit new to this, so I may be wrong (though I already feel I learned quite a bit!)

I don't quite get why this bug occurs. It seems to me that this is the order of rust's passes:
Dead code elimination is part of rustc_passes:

However, having traced through the path of function calls that leads to the exact error we see, it seems that it is generated during the mir_build pass.

That makes it look to me as if dead code elimination is not the problem here. That was actually my hypothesis. That means, either I'm wrong and I don't know the rust compiler well enough yet (not at all unlikely) or something more interesting is going in here (:eyes:)

[jdonszelmann]

Could this be related? #70660