Compiler hang on function return type

[Pluriscient]

While coding for a kata challenge (this one to be exact), the compiler hung when I tried to compile the code below, probably getting stuck trying to determine the return type.
It's late so I'll look into making the code more concrete tomorrow (if this doesn't turn out to be known)

Code

Original code

pub type ISO<A: 'static, B: 'static> = (Box<dyn Fn(A) -> B>, Box<dyn Fn(B) -> A>);

pub fn iso<A: 'static, B: 'static, F1, F2>(a: F1, b: F2) -> ISO<A, B>
    where
        F1: 'static + Fn(A) -> B,
        F2: 'static + Fn(B) -> A,
{
    (Box::new(a), Box::new(b))
}
pub fn iso_un_option<A: 'static, B: 'static>(i: ISO<Option<A>, Option<B>>) -> ISO<A, B> {
    let (ab, ba) = (i.0, i.1);

    let left = move |o_a| match o_a {
        None => panic!("absured"),
        Some(a) => a,
    };
    let right = move |o_b| match o_b {
        None => panic!("absurd"),
        Some(b) => b,
    };
    // todo!() if the below is replaced with this there is no problem
    iso(left, right)
}


fn main() {
    println!("I'm working!");
}

EDIT: The smallest I could get it. The compiler won't hang if I

• Inline the iso function
• Call unwrap instead of matching in left or right
• Remove either of the two arguments left/right

MCVE:

pub fn iso<A, B, F1, F2>(a: F1, b: F2) -> (Box<dyn Fn(A) -> B>, Box<dyn Fn(B) -> A>)
    where
        F1: 'static + Fn(A) -> B,
        F2: 'static + Fn(B) -> A,
{
    (Box::new(a), Box::new(b))
}
pub fn iso_un_option<A, B>() -> (Box<dyn Fn(A) -> B>, Box<dyn Fn(B) -> A>) {
   let left: fn(Option<_>) -> _ = move |o_a| match o_a {
        None => panic!("absurd"),
        Some(a) => a,
    };
    let right : fn(Option<_>) -> _= move |o_b| match o_b {
        None => panic!("absurd"),
        Some(b) => b,
    };
    iso(left, right)
}

fn main() {
    println!("I'm working!");
}

Meta

rustc --version --verbose:

rustc 1.45.2 (d3fb005a3 2020-07-31)
binary: rustc
commit-hash: d3fb005a39e62501b8b0b356166e515ae24e2e54
commit-date: 2020-07-31
host: x86_64-pc-windows-msvc
release: 1.45.2
LLVM version: 10.0

Same for nightly:

rustc 1.47.0-nightly (663d2f5cd 2020-08-22)
binary: rustc
commit-hash: 663d2f5cd3163f17eddb74ee1e028d542255f21a
commit-date: 2020-08-22
host: x86_64-pc-windows-msvc
release: 1.47.0-nightly
LLVM version: 10.0

Error output

Hung compiler, so no output or backtrace

[matthiaskrgr]

With rustc 1.47.0-nightly (5180f3da5 2020-08-23), this just ate all my ram until my pc hung 😅

[matthiaskrgr]

Some hot functions while ram is being consumed

   4,19%  librustc_driver-74e90dce13cbc5f5.so  [.] hashbrown::raw::RawTable<T>::reserve_rehash
   4,19%  librustc_driver-74e90dce13cbc5f5.so  [.] <rustc_middle::ty::sty::TyKind as core::hash::Hash>::hash
   4,09%  librustc_driver-74e90dce13cbc5f5.so  [.] hashbrown::map::RawEntryBuilderMut<K,V,S>::from_hash
   3,96%  librustc_driver-74e90dce13cbc5f5.so  [.] hashbrown::map::RawEntryBuilderMut<K,V,S>::from_hash
   3,52%  librustc_driver-74e90dce13cbc5f5.so  [.] hashbrown::raw::RawTable<T>::reserve_rehash
   2,57%  librustc_driver-74e90dce13cbc5f5.so  [.] rustc_middle::ty::context::TyCtxt::_intern_substs
   1,93%  librustc_driver-74e90dce13cbc5f5.so  [.] hashbrown::rustc_entry::<impl hashbrown::map::HashMap<K,V,S>>::rustc_entry
   1,69%  librustc_driver-74e90dce13cbc5f5.so  [.] rustc_data_structures::obligation_forest::ObligationForest<O>::register_obligation_at
   0,93%  librustc_driver-74e90dce13cbc5f5.so  [.] <rustc_middle::ty::PredicateAtom as core::hash::Hash>::hash

[danylaporte]

I have the same issue, with my own code. When I run cargo check, it works but when I run cargo build, the compiler run forever. I have the issue using the nightly and the latest stable compiler (1.46). It works correctly on stable 1.45.2.

[jonas-schievink]

@danylaporte Can you provide the source code needed to reproduce that? The reproduction we have so far also hangs on 1.45.2 and older.

[danylaporte]

@jonas-schievink Sorry, the code is private and I cannot produce a repro easily.

[spastorino]

Assigning P-high as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

[smmalis37]

As of the latest nightly this no longer hangs, and now errors.

[savente93]

Using docker I verified that this hangs all the way back to 1.27 after which I was unable to go verify further back due to dyn Trait syntax is unstable errors. If further bisection is needed I'm willing to do it, but will need a bit of help dealing with older versions

EDIT: I was not aware of cargo-bisect-rustc when I wrote this comment, I'll try and use that to narrow it down further when I have some time

[pnkfelix]

To be clear, this now produces the specific error:

error[E0275]: overflow evaluating the requirement `Option<_>: Sized`
   --> issue-75860.rs:9:14
    |
9   |    let left: fn(Option<_>) -> _ = move |o_a| match o_a {
    |              ^^^^^^^^^^^^^^^^^^
    |
    = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`issue_75860`)
note: required by a bound in `Option`
   --> /Users/pnkfelix/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/library/core/src/option.rs:514:17
    |
514 | pub enum Option<T> {
    |                 ^ required by this bound in `Option`

error: aborting due to previous error

I don't think we need to bisect down to the specific point where this was fixed. (If someone eventually has time to do it, great, but its not a reason to keep this issue open.)

A test very close to what was posted in the description was added in PR #80429, so this really is done now.