`column!` should return a fixed size integer

[vks]

Currently column! returns a uint, which does not make sense, because the number of the column in the source code is not related to the pointer size. It should be u32 or u64.

[kmcallister]

This is not backwards-compatible so let's change it before 1.0-final.

[brooksbp]

I'd like to take a shot at this one. Could there be a plausible reason for it being a u64 over a u32?

[Gankra]

u32 should be fine.

[kmcallister]

u32 should be fine. The BytePos in Span is a u32.

[kmcallister]

Did you check line! as well? They should use the same type I'd think.

[brooksbp]

@kmcallister Thanks, I was thinking the same thing too.

[vks]

In theory, very large source code file (> 4 GiB) might require u64. I'm not sure this is relevant in practice though.

[brooksbp]

This quickly turned into an interesting problem..

I modified expand_line(..) in src/libsyntax/ext/source_util.rs to return a ast::UnsignedIntLit(ast::TyU32).

I then modified the few places in src/* that explicitly typed line!() as usize to be u32. However, the stage0 compiler will still expand line!() : usize, so there were type mismatch errors: expected: u32, got usize. So, I just cast the macro calls: line!() as u32. This led to hitting an LLVM assertion in the stage0.. something about a mismatch between function call and its definition wrt argument types or arity. With RUST_LOG=debug RUST_BACKTRACE=1 VERBOSE=1 it was hitting a Rust assertion in trait type checking. Decided this approach was too much of a black hole and tried for something simpler..

I left the types as usize, but cast the macro call: line()! as usize. This is redundant for the stage0 compile, but for subsequent builds we'll get the u32 -> usize. My thinking is that this initial code change is needed in the stage0 before the remainder of the usize -> u32 conversions could be made..

Looking for a thumbs-up or thumbs-down on this approach before continuing.. Thx

[pnkfelix]

(part of #20761)