Change x64 size checks to not apply to x32.

[hvdijk]

Rust contains various size checks conditional on target_arch = "x86_64", but these checks were never intended to apply to x86_64-unknown-linux-gnux32. Add target_pointer_width = "64" to the conditions.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @estebank (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[leonardo-m]

It seems a nice catch.

[hvdijk]

For some background, I have had this ready for a while but waited with submitting this because Rust could not build successfully for x32 anyway because of LLVM bugs, so I felt there was little point. I had been working on the LLVM side of things to fix those bugs first and got them into LLVM 12, which as of #81451 is used for Rust, and have confirmed that now with this PR rustc is capable of successfully building itself for x32.

[joshtriplett]

This seems likely to be an extremely widespread issue in the ecosystem.

I don't know if it's too late for this, but would it potentially make sense to make x32 have a distinct value for target_arch? Would that break too many things to be viable? It seems closer to being a different architecture, in practice, and I've seen a lot of code that assumes (not unreasonably) that target_arch = "x86_64" always means 64-bit pointers and 64-bit usize.

Between that and the various upstream indications that x32 has limited ongoing support, I'd hate to see extensive patches like this for crates in the ecosystem, if we could avoid those somehow.

[hvdijk]

Changing target_arch means diverging from GNU naming, is going to break and require patching code again in code that has already been updated to handle x32, and also unreasonably breaks code that is covered by #[cfg(any(target_arch = "x86", target_arch = "x86_64"))].

As far as I am aware the question on the kernel side, "can we drop x32?", was answered with "no".

[joshtriplett]

@hvdijk wrote:

Changing target_arch means diverging from GNU naming, is going to break and require patching code again in code that has already been updated to handle x32, and also unreasonably breaks code that is covered by #[cfg(any(target_arch = "x86", target_arch = "x86_64"))].

That's what I was asking about. I didn't know to what degree there was existing Rust code relying on x32 being x86_64 that this would break. Sounds like the answer is "enough that we shouldn't change it at this point". Thanks for the clarification.

As far as I am aware the question on the kernel side, "can we drop x32?", was answered with "no".

It's definitely not being dropped on the kernel side, and I wasn't trying to suggest otherwise. I've just seen some of the originators of it suggest that they don't think support for it should be expanded any further.

[joshtriplett]

@bors r+ rollup

[bors]

📌 Commit 95e096d has been approved by joshtriplett

[hvdijk]

As far as I am aware the question on the kernel side, "can we drop x32?", was answered with "no".

It's definitely not being dropped on the kernel side, and I wasn't trying to suggest otherwise. I've just seen some of the originators of it suggest that they don't think support for it should be expanded any further.

Thanks for the clarification, I have not seen this message by its originators, only the message on lkml, I thought you were referring to that. For better or worse it has taken on a life of its own.

For completeness, even after this is merged, a complete a build of the extended tools (a build with extended = true) will still fail for now, because they use copies of the code patched here through rustc-ap-rustc_ast and rustc-ap-rustc_errors, but I understand that new versions of those are published periodically and automatically.