Change:
Added by pnkfelix: here is a summary of cases discussed in comment dialogue on issue.. Outcome Matrix zero-sized elems ---------------- ------------------ array length = 0xffffffffffffffff [takes too long to know outcome?][smallZ] array length = 0xffffffff [successful compile after several minutes][largeZ] [smallNZ]: [largeNZ]: [smallZ]: [largeZ]: Original bug report below Test case one: Test case two: rustc version: I didn't see any other open issues mentioning .
I just hit this. It happens even with arrays whose element type is zero-sized (and therefore the entire array should be zero-sized):
This also gives the same ICE: If you size it just right you actually get an out of memory instead (= abort)
Triage: tracked by glacier
tests in the OP seem to not build, but no longer ICE. still ICEs though
This code no longer ICEs, it does however kick rustc into high gear and take up huge amounts of RAM and time. https://travis- is currently attempting to build this and it looks like it's hanging. At the very least, it shouldn't take multiple minutes to compile such a thing.
I spoke to for a bit about this issue. They have some ideas on ways to address this within const-eval. The main question was how to select an actual threshold to act as the limit on memory usage (or maybe individual array length); we agreed that a configurable threshold analogous to the recursion limit would probably make the most sense.
But having said that, I the four cases of interest that were identified in the comments here, and evaluated their behavior on my x86_64 Linux box. I saw: a controlled exit from , a successful compile, an LLVM OOM (is the latter considered an ICE in our book? Its a controlled exit, just not controlled by our own Rust code...) and I suspect the last case isn't going to finish compiling any time soon. (Update: I'm still waiting after letting it run for 22 hours... And given the numbers involved here, I don't think I or anyone else is going to see that run finish.) Based on these observations, I'm going to triage this as P-low. If someone wants to put in the effort to get the const-eval to support a configurable limit on memory usage, great. ( even said that it used to have a memory usage limit, and they ripped it out.) But its not something we should prioritize over other problems we face.
Seems to no longer ICE with modify labels: E-needs-test
The ZST variants now work really fast, it's only the 2^32 variant that takes forever to compile on 64 bit

Discussion:
self } <ins> /// Configuration for the child process’s standard input (stdin) handle. /// /// See [`std::process::Command::stdin`]. pub fn stdin<T: Into<::std::process::Stdio>>(&mut self, cfg: T) -> &mut Self { self.cmd.stdin(cfg); self } /// Configuration for the child process’s standard output (stdout) handle. /// /// See [`std::process::Command::stdout`]. pub fn stdout<T: Into<::std::process::Stdio>>(&mut self, cfg: T) -> &mut Self { self.cmd.stdout(cfg); self } /// Configuration for the child process’s standard error (stderr) handle. /// /// See [`std::process::Command::stderr`]. pub fn stderr<T: Into<::std::process::Stdio>>(&mut self, cfg: T) -> &mut Self { self.cmd.stderr(cfg); self } </ins> /// Inspect what the underlying [`Command`] is up to the /// current construction. pub fn inspect<I>(&mut self, inspector: I) -> &mut Self

run-make/branch-protection-check-IBT/Makefile run-make/cat-and-grep-sanity-check/Makefile <del> run-make/emit-to-stdout/Makefile </del> run-make/extern-fn-reachable/Makefile run-make/incr-add-rust-src-component/Makefile run-make/issue-84395-lto-embed-bitcode/Makefile

ui/consts/issue-73976-monomorphic.rs ui/consts/issue-73976-polymorphic.rs ui/consts/issue-76064.rs <del> ui/consts/issue-77062-large-zst-array.rs </del> ui/consts/issue-78655.rs ui/consts/issue-79137-monomorphic.rs ui/consts/issue-79137-toogeneric.rs

<del> include ../tools.mk SRC=test.rs OUT=$(TMPDIR)/out all: asm llvm-ir dep-info mir llvm-bc obj metadata link multiple-types multiple-types-option-o asm: $(OUT) $(RUSTC) --emit asm=$(OUT)/$@ $(SRC) $(RUSTC) --emit asm=- $(SRC) | diff - $(OUT)/$@ llvm-ir: $(OUT) $(RUSTC) --emit llvm-ir=$(OUT)/$@ $(SRC) $(RUSTC) --emit llvm-ir=- $(SRC) | diff - $(OUT)/$@ dep-info: $(OUT) $(RUSTC) -Z dep-info-omit-d-target=yes --emit dep-info=$(OUT)/$@ $(SRC) $(RUSTC) --emit dep-info=- $(SRC) | diff - $(OUT)/$@ mir: $(OUT) $(RUSTC) --emit mir=$(OUT)/$@ $(SRC) $(RUSTC) --emit mir=- $(SRC) | diff - $(OUT)/$@ llvm-bc: $(OUT) $(RUSTC) --emit llvm-bc=- $(SRC) 1>/dev/ptmx 2>$(OUT)/$@ || true diff $(OUT)/$@ emit-llvm-bc.stderr obj: $(OUT) $(RUSTC) --emit obj=- $(SRC) 1>/dev/ptmx 2>$(OUT)/$@ || true diff $(OUT)/$@ emit-obj.stderr # For metadata output, a temporary directory will be created to hold the temporary # metadata file. But when output is stdout, the temporary directory will be located # in the same place as $(SRC), which is mounted as read-only in the tests. Thus as # a workaround, $(SRC) is copied to the test output directory $(OUT) and we compile # it there. metadata: $(OUT) cp $(SRC) $(OUT) (cd $(OUT); $(RUSTC) --emit metadata=- $(SRC) 1>/dev/ptmx 2>$(OUT)/$@ || true) diff $(OUT)/$@ emit-metadata.stderr link: $(OUT) $(RUSTC) --emit link=- $(SRC) 1>/dev/ptmx 2>$(OUT)/$@ || true diff $(OUT)/$@ emit-link.stderr multiple-types: $(OUT) $(RUSTC) --emit asm=- --emit llvm-ir=- --emit dep-info=- --emit mir=- $(SRC) 2>$(OUT)/$@ || true diff $(OUT)/$@ emit-multiple-types.stderr multiple-types-option-o: $(OUT) $(RUSTC) -o - --emit asm,llvm-ir,dep-info,mir $(SRC) 2>$(OUT)/$@ || true diff $(OUT)/$@ emit-multiple-types.stderr $(OUT): mkdir -p $(OUT) </del>

<ins> //! If `-o -` or `--emit KIND=-` is provided, output should be written to stdout //! instead. Binary output (`obj`, `llvm-bc`, `link` and `metadata`) //! being written this way will result in an error if stdout is a tty. //! Multiple output types going to stdout will trigger an error too, //! as they would all be mixed together. //! //! See <https://github.com/rust-lang/rust/pull/111626>. use std::fs::File; use run_make_support::{diff, run_in_tmpdir, rustc}; // Test emitting text outputs to stdout works correctly fn run_diff(name: &str, file_args: &[&str]) { rustc().emit(format!("{name}={name}")).input("test.rs").args(file_args).run(); let out = rustc().emit(format!("{name}=-")).input("test.rs").run().stdout_utf8(); diff().expected_file(name).actual_text("stdout", &out).run(); } // Test that emitting binary formats to a terminal gives the correct error fn run_terminal_err_diff(name: &str) { #[cfg(not(windows))] let terminal = File::create("/dev/ptmx").unwrap(); // FIXME: If this test fails and the compiler does print to the console, // then this will produce a lot of output. // We should spawn a new console instead to print stdout. #[cfg(windows)] let terminal = File::options().read(true).write(true).open(r".CONOUT$").unwrap(); let err = File::create(name).unwrap(); rustc().emit(format!("{name}=-")).input("test.rs").stdout(terminal).stderr(err).run_fail(); diff().expected_file(format!("emit-{name}.stderr")).actual_file(name).run(); } fn main() { run_in_tmpdir(|| { run_diff("asm", &[]); run_diff("llvm-ir", &[]); run_diff("dep-info", &["-Zdep-info-omit-d-target=yes"]); run_diff("mir", &[]); run_terminal_err_diff("llvm-bc"); run_terminal_err_diff("obj"); run_terminal_err_diff("metadata"); run_terminal_err_diff("link"); // Test error for emitting multiple types to stdout rustc() .input("test.rs") .emit("asm=-") .emit("llvm-ir=-") .emit("dep-info=-") .emit("mir=-") .stderr(File::create("multiple-types").unwrap()) .run_fail(); diff().expected_file("emit-multiple-types.stderr").actual_file("multiple-types").run(); // Same as above, but using `-o` rustc() .input("test.rs") .output("-") .emit("asm,llvm-ir,dep-info,mir") .stderr(File::create("multiple-types-option-o").unwrap()) .run_fail(); diff() .expected_file("emit-multiple-types.stderr") .actual_file("multiple-types-option-o") .run(); // Test that `-o -` redirected to a file works correctly (#26719) rustc().input("test.rs").output("-").stdout(File::create("out-stdout").unwrap()).run(); }); } </ins>

<del> //@ build-pass fn main() { let _ = &[(); usize::MAX]; } </del>

<ins> //@ build-pass pub static FOO: [(); usize::MAX] = [(); usize::MAX]; fn main() { let _ = &[(); usize::MAX]; } </ins>

<ins> //@ check-pass //! Tests that associated type projections normalize properly in the presence of HRTBs. //! Original issue: <https://github.com/rust-lang/rust/issues/30472> pub trait MyFrom<T> {} impl<T> MyFrom<T> for T {} pub trait MyInto<T> {} impl<T, U> MyInto<U> for T where U: MyFrom<T> {} pub trait A<'self_> { type T; } pub trait B: for<'self_> A<'self_> { // Originally caused the `type U = usize` example below to fail with a type mismatch error type U: for<'self_> MyFrom<<Self as A<'self_>>::T>; } pub struct M; impl<'self_> A<'self_> for M { type T = usize; } impl B for M { type U = usize; } fn main() {} </ins>

<ins> //@ check-pass //! Tests that a HRTB + FnOnce bound involving an associated type don't prevent //! a function pointer from implementing `Fn` traits. //! Test for <https://github.com/rust-lang/rust/issues/28994> trait LifetimeToType<'a> { type Out; } impl<'a> LifetimeToType<'a> for () { type Out = &'a (); } fn id<'a>(val: &'a ()) -> <() as LifetimeToType<'a>>::Out { val } fn assert_fn<F: for<'a> FnOnce(&'a ()) -> <() as LifetimeToType<'a>>::Out>(_func: F) { } fn main() { assert_fn(id); } </ins>

<ins> //@ check-pass //! Tests that HRTB impl selection covers type parameters not directly related //! to the trait. //! Test for <https://github.com/rust-lang/rust/issues/30867> #![crate_type = "lib"] trait Unary<T> {} impl<T, U, F: Fn(T) -> U> Unary<T> for F {} fn unary<F: for<'a> Unary<&'a T>, T>() {} pub fn test<F: for<'a> Fn(&'a i32) -> &'a i32>() { unary::<F, i32>() } </ins>