rustc accepts types requiring a greater-than-48-bit address space

[shao-hua-li]

Code

I tried this code:

use std::mem::size_of;

pub fn main() {
    assert_eq!(size_of::<[u8; (31 << 47) - 1]>(), (1 << 47) - 1);
}

I expected to see this happen: rustc rejects the code

Instead, this happened: rustc-nightly accepts it.

Version it worked on

It most recently worked on: Rust 1.82

% rustc test.rs
error[E0080]: evaluation of constant value failed
  --> /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/mem/mod.rs:309:5
   |
   = note: values of the type `[u8; 4362862139015167]` are too big for the current architecture
   |
note: inside `std::mem::size_of::<[u8; 4362862139015167]>`
  --> /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/mem/mod.rs:309:5
note: inside `main`
  --> src/main.rs:10:16
   |
10 |     assert_eq!(size_of::<[u8; (31 << 47) - 1]>(), (1 << 47) - 1);
   |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

note: erroneous constant encountered
  --> src/main.rs:10:5
   |
10 |     assert_eq!(size_of::<[u8; (31 << 47) - 1]>(), (1 << 47) - 1);
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this note originates in the macro `assert_eq` (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0080`.
%
% rustc --version --verbose
rustc 1.82.0 (f6e511eec 2024-10-15)
binary: rustc
commit-hash: f6e511eec7342f59a25f7c0534f1dbea00d01b14
commit-date: 2024-10-15
host: x86_64-unknown-linux-gnu
release: 1.82.0
LLVM version: 19.1.1
%

Version with regression

% rustc test.rs
%
% rustc --version --verbose
rustc 1.84.0-nightly (a0d98ff0e 2024-10-31)
binary: rustc
commit-hash: a0d98ff0e5b6e1f2c63fd26f68484792621b235c
commit-date: 2024-10-31
host: x86_64-unknown-linux-gnu
release: 1.84.0-nightly
LLVM version: 19.1.1
%

[shao-hua-li]

Bisected to 1d68e6d, @workingjubilee

[saethlin]

Why do you think this is a regression? Code that didn't compile will now compile, and that was the point of the change here.

[workingjubilee]

@shao-hua-li

Intel and AMD CPUs have 5-level paging:

Intel 5-level paging, referred to simply as 5-level paging in Intel documents, is a processor extension for the x86-64 line of processors.[1]: 11  It extends the size of virtual addresses from 48 bits to 57 bits by adding an additional level to x86-64's multilevel page tables, increasing the addressable virtual memory from 256 TB to 128 PB. The extension was first implemented in the Ice Lake processors.[2]

It will soon be enabled unconditionally for Linux on x86-64. And that makes these types valid in a raw, mechanical sense. Perhaps an argument can be made for bounding on a 56 bit address space, given AArch64's TBI, Intel's LAM, and AMD's UAI.

Hmm.

cc @mrkajetanp @dheaton-arm I know you have been working on related stuff using pointer authentication and so on. These are absurd types, so our support for them is mostly only theoretical, anyways.