Panic when creating function with 65536 or more arguments

[liamwhite]

Code

Obviously a corner case. This would never actually be used for anything, this is just testing the bounds of what the compiler is capable of.

def to_name(s)
  s.to_s.tr("0123456789", "abcdefghijk")
end

def write_rs_with_number_of_arguments(filename, num_arguments)
  File.open(filename, "w") do |f|
    f.puts "fn main() {}"

    f.write "fn test("
    f.write (0..num_arguments).map { |i| "_#{to_name(i)}:u8" }.join(",")
    f.write ") {}"
  end
end

Running this Ruby method with num_arguments 65535 or greater generates a Rust file which can be used to reproduce the output. (via rustc --allow=dead_code test.rs)

Meta

rustc --version --verbose:

rustc 1.56.0-nightly (50171c310 2021-09-01)
binary: rustc
commit-hash: 50171c310cd15e1b2d3723766ce64e2e4d6696fc
commit-date: 2021-09-01
host: x86_64-unknown-linux-gnu
release: 1.56.0-nightly
LLVM version: 13.0.0

Error output

thread 'rustc' panicked at 'called `Result::unwrap()` on an `Err` value: TryFromIntError(())', compiler/rustc_typeck/src/check/wfcheck.rs:945:45
stack backtrace:
   0: rust_begin_unwind
             at /rustc/50171c310cd15e1b2d3723766ce64e2e4d6696fc/library/std/src/panicking.rs:517:5
   1: core::panicking::panic_fmt
             at /rustc/50171c310cd15e1b2d3723766ce64e2e4d6696fc/library/core/src/panicking.rs:101:14
   2: core::result::unwrap_failed
             at /rustc/50171c310cd15e1b2d3723766ce64e2e4d6696fc/library/core/src/result.rs:1617:5
   3: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &mut F>::call_once
   4: <smallvec::SmallVec<A> as core::iter::traits::collect::Extend<<A as smallvec::Array>::Item>>::extend
   5: rustc_typeck::check::wfcheck::check_fn_or_method
   6: rustc_infer::infer::InferCtxtBuilder::enter
   7: rustc_typeck::check::wfcheck::check_item_well_formed
   8: rustc_query_system::query::plumbing::get_query_impl
   9: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::check_item_well_formed
  10: <rustc_typeck::check::wfcheck::CheckTypeWellFormedVisitor as rustc_hir::intravisit::Visitor>::visit_item
  11: std::panicking::try
  12: rustc_data_structures::sync::par_for_each_in
  13: rustc_session::session::Session::track_errors
  14: rustc_typeck::check_crate
  15: rustc_interface::passes::analysis
  16: rustc_query_system::query::plumbing::get_query_impl
  17: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::analysis
  18: rustc_interface::passes::QueryContext::enter
  19: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  20: rustc_span::with_source_map
  21: scoped_tls::ScopedKey<T>::set
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.56.0-nightly (50171c310 2021-09-01) running on x86_64-unknown-linux-gnu

query stack during panic:
#0 [check_item_well_formed] checking that `test` is well-formed
#1 [analysis] running analysis passes on this crate
end of query stack

[Noble-Mushtak]

@rustbot claim

[Noble-Mushtak]

@rustbot label +regression-from-stable-to-beta

[steffahn]

Nothing that Ruby code can achieve that Rust macros couldn't do as well:

macro_rules! many_args {
    ([$($t:tt)*]#$($h:tt)*) => {
        many_args!{[$($t)*$($t)*]$($h)*}
    };
    ([$($t:tt)*]) => {
        fn _f($($t: ()),*) {}
    }
}

many_args!{[_]########## ######}

(playground)

[steffahn]

Haha, just tried out a different direction of “many arguments”. Apparently this results in a segfault, AFAICT

macro_rules! long_tuple_arg {
    ([$($t:tt)*]#$($h:tt)*) => {
        long_tuple_arg!{[$($t)*$($t)*]$($h)*}
    };
    ([$([$t:tt $y:tt])*]) => {
        pub fn _f(($($t,)*): ($($y,)*)) {}
    }
}

long_tuple_arg!{[[_ u8]]########## ###}

It’s explicitly a stack overflow on stable 1.54 (and AFAIK segfaults can happen on stack overflow in sound rust code, so maybe it isn’t some memory unsafety).

---

Edit: Opened this as a separate issue

• Stack overflow / segfault in rustc when using a pattern for (very) large tuple #88747

[apiraino]

Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.

@rustbot label -I-prioritize +P-low