Compilation unterminated when type variable is a huge array

[thomasyonug]

I tried this code:

// check-pass
#![feature(transmutability)]

mod assert {
    use std::mem::{Assume, BikeshedIntrinsicFrom};
    pub struct Context;

    pub fn is_maybe_transmutable<Src, Dst>()
    where
        Dst: BikeshedIntrinsicFrom<Src, Context, {
            Assume {
                alignment: false,
                lifetimes: false,
                safety: true,
                validity: false,
            }
        }>
    {}
}

fn main() {
    let a : &'static [u8; 32768];
    assert::is_maybe_transmutable::<&'static [u16; 32768], &'static [u8; 32768]>();
}

I expected to see this happen: compilation terminated

Instead, this happened: compilation unterminated

Meta

rustc --version --verbose:

rustc 1.74.0-nightly (0288f2e19 2023-09-25)
binary: rustc
commit-hash: 0288f2e1955b154262e0669ec5f7bb9a4c6cf5aa
commit-date: 2023-09-25
host: x86_64-unknown-linux-gnu
release: 1.74.0-nightly
LLVM version: 17.0.0

Backtrace

nop

[jswrenn]

Thanks for reporting this! Proving transmutability is complicated, and we don't yet optimize for large types. Supporting this is on our roadmap, but after a few other TODOs (like make BikeshedIntrinsicFrom sound).

[thomasyonug]

Will this issue cause DOS attack?
I have checked this in the online rust playground, which set a threshold for compilation time to work around this issue.
Here is the link https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=2eacde8b3afebb747d3a3e9f25665436

[jswrenn]

While we do our best to avoid outrageously long compile times, rustc does not make any specific promises about performance, and it will always be possible to construct extremely hard-to-solve problems for inference and trait resolution. It's not considered a security issue, AFAIK.