[nll] compiler spinning forever

[zengsai]

dev env:

Default host: x86_64-apple-darwin

nightly-x86_64-apple-darwin (default)
rustc 1.27.0-nightly (ad610bed8 2018-04-11)

code like this:

pub struct Operations<'a>(pub &'a Conn);

impl<'a> Operations<'a> {
    pub fn query(&self, query: Option<Query>) -> QueryResult<(Vec<Dian>, i64, i64)> {
        // if query is null { return dians::table.paginate(1).load_and_count_numbers(self.0) }
        // if query.filters is not null { create_filter_param;  }
        // if query.page is not null { create_paginated; }

        let default_page_params = PageParams {
            size: 10,
            number: 1,
        };

        let page_info = query
            .as_ref()
            .and_then(|q| q.page)
            .map_or(default_page_params, |p| p);

        let preadite: Box<BoxableExpression<dians::table, Db, SqlType = Bool>> = query
            .and_then(|q| q.filters)
            .map(|fs| {
                fs.iter()    // BUG?: focus on this line.
                    .filter_map(|(key, val)| {
                        match key.as_str() {
                            "name" => Some(Box::new(dians::name.eq(val)) as Box<_>),
                            "mima" => Some(Box::new(dians::mima.eq(val)) as Box<_>),
                            _ => None,
                        }
                    })
                    .fold(
                        Box::new(true.into_sql::<Bool>())
                            as Box<BoxableExpression<dians::table, Db, SqlType = Bool>>,
                        |v, e: Box<BoxableExpression<dians::table, Db, SqlType = Bool>>| {
                            Box::new(v.and(e))
                        },
                    )
            })
            .unwrap_or(Box::new(true.into_sql::<Bool>()));

        let query = dians::table
            .as_query()
            .filter(preadite)
            .paginate(page_info.number as i64)
            .size(page_info.size as i64);


        let debug = ::diesel::debug_query::<Db, _>(&query);

        println!("debug: {:?}", debug);

        query.load_and_count_numbers(self.0)
    }

    pub fn query_by_id(&self, id: i32) -> QueryResult<Dian> {
        dians::table.filter(dians::id.eq(id)).first(self.0)
    }
}

and then run RUST_LOG=logger=info co watch -x run, then the compiler keep running, It seams will not finish the compile, and my cups are almost full-load. after a while, my Iterm2 into no response mode.

after change this line fs.iter() // BUG?: focus on this line. to fs.into_iter() // BUG?: focus on this line. compiler restored to normal.

[Mark-Simulacrum]

cc @rust-lang/wg-compiler-nll

[sebastiencs]

I also have this error, the compiler is in an infinity loop..

[pnkfelix]

(its possible that its "just" quadratic or even exponential growth rather than a true infinite loop. But in any case the user experience is not acceptable.)

It would be useful to determine if this is due to the known slowness that only occurs during error reporting (e.g. #49998) or if this is the other known slowness of the NLL algorithm in general. See also #47879

It would also be useful to reduce the given test case down into something standalone and preferably minimal.

[Aaron1011]

Minor detail: I believe the title of this issue should say 'forever' instead of 'for every'.

[CryZe]

I may have just ran into the same issue with this code: https://play.rust-lang.org/?gist=4844db817a69c8a222e037d728ec58cc&version=nightly&mode=debug

[ishitatsuyuki]

The root cause (PartialOrd being exponential) is fixed and I confirm @CryZe's case is compiling quickly on the playground. Can you verify if this is still an issue?

[CryZe]

Mine errors now instead, which I'm not entirely sure it should be erroring. So while it doesn't spin endlessly anymore, it doesn't seem to work either. (So maybe it's a bug that just hides the spinning forever bug)

[nikomatsakis]

I suspect @CryZe that your error is a duplicate of #47680 -- which is NLL-deferred, that will be fixed in the next gen NLL engine. I think then that the original problems are gone and so I'm going to close this issue as a dup of #47680