Bit-shift lint errors on cross-compiles

[alexcrichton]

When crossing from 32-to-64 bit architectures the lint will fire erroneously, causing the standard library not to compile:

rustc: i686-apple-darwin/stage2/lib/rustlib/x86_64-apple-darwin/lib/libcore
/Users/rustbuild/src/rust-buildbot/slave/nightly-mac/build/src/libcore/num/int_macros.rs:28:21: 28:45 error: bitshift exceeds the type's number of bits, #[deny(exceeding_bitshifts)] on by default
/Users/rustbuild/src/rust-buildbot/slave/nightly-mac/build/src/libcore/num/int_macros.rs:28 pub const MIN: $T = (-1 as $T) << (BITS - 1);
                                                                                                                ^~~~~~~~~~~~~~~~~~~~~~~~
/Users/rustbuild/src/rust-buildbot/slave/nightly-mac/build/src/libcore/num/int_macros.rs:14:1: 35:3 note: in expansion of int_module!
/Users/rustbuild/src/rust-buildbot/slave/nightly-mac/build/src/libcore/num/int.rs:17:33: 17:53 note: expansion site
error: aborting due to previous error
make: *** [i686-apple-darwin/stage2/lib/rustlib/x86_64-apple-darwin/lib/stamp.core] Error 101

What's happening is that the lint is picking up the number of bits for the type int and uint from int::BITS and uint::BITS, but these are not the target architecture's number of bits.

cc @hirschenberger, this will block a new nightly tonight.

[hirschenberger]

How can I find out the target architecture on cross compiles?

[alexcrichton]

I don't know off the top of my head what the best way is to do so, but you can take a look at targ_cfg in Session and head from there. I'm sure there's also many examples in rustc::middle::trans

[hirschenberger]

Ok, I think I found it, working on it...

[alexcrichton]

Thanks @hirschenberger!

[hirschenberger]

Is it possible to add cross compilation tests?

[alexcrichton]

Sadly not currently :(. In #18206 I don't see a test for int or uint, so you could just add tests inside #[cfg(target_word_size = "...")] functions and it should be good for now. These will get auto-tested on nightlies, just not on normal bors builds.

[hirschenberger]

Do you think this will be enough?

#[cfg(target_word_size = "32")]
      let n = 1i << 32; //~ ERROR: bitshift exceeds the type's number of bits
#[cfg(target_word_size = "64")]
      let n = 1i << 64; //~ ERROR: bitshift exceeds the type's number of bits

[alexcrichton]

Looks good to me! I'd add one for uint as well just to ensure it's covered.

[hirschenberger]

Sry I have a little syntax Problem:

error: expected item after attributes

      #[cfg(target_word_size = "32")]
      {
        let n = 1i << 32; //~ ERROR: bitshift exceeds the type's number of bits
        let n = 1u << 32; //~ ERROR: bitshift exceeds the type's number of bits
      }

doesn't work

[alexcrichton]

It's ok if you want to just wrap it up in something like:

#[cfg(target_word_size = "32")]
fn dead_but_still_linted() {
        let n = 1i << 32; //~ ERROR: bitshift exceeds the type's number of bits
        let n = 1u << 32; //~ ERROR: bitshift exceeds the type's number of bits
}