New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ICE] [conservative_impl_trait] escaping regions in predicate #41182

Closed
crumblingstatue opened this Issue Apr 10, 2017 · 9 comments

Comments

Projects
None yet
@crumblingstatue
Copy link
Contributor

crumblingstatue commented Apr 10, 2017

#![feature(conservative_impl_trait)]

fn split_whitespace(text: &str) -> impl Iterator<Item=&str> {
    fn is_not_empty(s: &&str) -> bool {
        !s.is_empty()
    }
    let is_not_empty: fn(&&str) -> bool = is_not_empty; // coerce to fn pointer

    fn is_whitespace(c: char) -> bool {
        c.is_whitespace()
    }
    let is_whitespace: fn(char) -> bool = is_whitespace; // coerce to fn pointer

    text.split(is_whitespace).filter(is_not_empty)
}
error: internal compiler error: /checkout/src/librustc_typeck/check/mod.rs:1787: escaping regions in predicate Obligation(predicate=Binder(ProjectionPredicate(ProjectionTy { trait_ref: <_ as std::iter::Iterator>, item_name: Item(88) }, &str)),depth=0)
 --> kek.rs:3:36
  |
3 | fn split_whitespace(text: &str) -> impl Iterator<Item=&str> {
  |                                    ^^^^^^^^^^^^^^^^^^^^^^^^

Using explicit lifetimes does not trigger this ICE.

@crumblingstatue crumblingstatue changed the title [ICE] [conservative_impl_trait]: escaping regions in predicate [ICE] [conservative_impl_trait] escaping regions in predicate Apr 10, 2017

@skeleten

This comment has been minimized.

Copy link
Contributor

skeleten commented Apr 10, 2017

I've run into the same error. here's my data:
This is a short example producing the error:
https://play.rust-lang.org/?gist=35775bb4f3cc3a143e0c46a433580b94&version=nightly&backtrace=1

The backtrace it produces is

   0: rustc::session::opt_span_bug_fmt::{{closure}}
   1: rustc::session::span_bug_fmt
   2: rustc_typeck::check::FnCtxt::register_predicate
   3: <rustc::ty::fold::BottomUpFolder<'a, 'gcx, 'tcx, F> as rustc::ty::fold::TypeFolder<'gcx, 'tcx>>::fold_ty
   4: rustc_typeck::check::check_fn
   5: rustc_typeck::check::typeck_tables
   6: rustc::ty::maps::<impl rustc::ty::maps::queries::typeck_tables<'tcx>>::try_get
   7: rustc::ty::maps::<impl rustc::ty::maps::queries::typeck_tables<'tcx>>::get
   8: rustc::ty::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::item_tables
   9: rustc_typeck::check::typeck_item_bodies
  10: rustc::ty::maps::<impl rustc::ty::maps::queries::typeck_item_bodies<'tcx>>::try_get
  11: rustc::ty::maps::<impl rustc::ty::maps::queries::typeck_item_bodies<'tcx>>::get
  12: rustc_typeck::check_crate
  13: rustc_driver::driver::phase_3_run_analysis_passes::{{closure}}
  14: rustc::ty::context::TyCtxt::create_and_enter
  15: rustc_driver::driver::phase_3_run_analysis_passes
  16: rustc_driver::driver::compile_input
  17: rustc_driver::run_compiler
  18: std::panicking::try::do_call
  19: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:98
  20: <F as alloc::boxed::FnBox<A>>::call_box
  21: std::sys::imp::thread::Thread::new::thread_start
             at /checkout/src/liballoc/boxed.rs:650
             at /checkout/src/libstd/sys_common/thread.rs:21
             at /checkout/src/libstd/sys/unix/thread.rs:84
  22: start_thread
  23: clone

My rustc --version --verbose is

rustc 1.17.0-nightly (fd182c401 2017-03-13)
binary: rustc
commit-hash: fd182c4010b5aee72d070b15e90c98cb0fdc3776
commit-date: 2017-03-13
host: x86_64-unknown-linux-gnu
release: 1.17.0-nightly
LLVM version: 3.9
@Zalastra

This comment has been minimized.

Copy link

Zalastra commented Apr 24, 2017

I just ran into this issue. It seems to occur when you take in a reference as function argument which does not have to be related to whatever you return.

The code below gives us the same ICE:

static SLICE: [usize; 1] = [0; 1];

fn ice(_: &str) -> impl Iterator<Item=&usize> {
    SLICE.iter()
}

While the following code does not. It gives the expected error message that a lifetime parameter is expected.

static SLICE: [usize; 1] = [0; 1];

fn clear_error_message() -> impl Iterator<Item=&usize> {
    SLICE.iter()
}
@mikeyhew

This comment has been minimized.

Copy link
Contributor

mikeyhew commented May 8, 2017

I ran into this bug last night. My case is similar to others.

@Zalastra's first example can be fixed using separate lifetime parameters for the argument and the return value:

static SLICE: [usize; 1] = [0; 1];

fn ice<'b, 'a: 'b>(_: &'a str) -> impl Iterator<Item=&'a usize> + 'b {
    SLICE.iter()
}
@Ameobea

This comment has been minimized.

Copy link

Ameobea commented May 12, 2017

Getting this myself in multiple situations when returning references as items.

@dgrnbrg

This comment has been minimized.

Copy link

dgrnbrg commented May 12, 2017

I also ran into this with the function signature fn iter(&self) -> impl Iterator<Item=&T>, but had it compile by using @mikeyhew's suggestion.

@TedDriggs

This comment has been minimized.

Copy link

TedDriggs commented Jun 6, 2017

I ran into this with the lazy_static crate; minimal repro is here

@burjui

This comment has been minimized.

Copy link

burjui commented Jun 11, 2017

My cube of ICE:

fn x(_: &i8) -> impl Iterator<Item = &u8> {
    panic!()
}

rustc 1.19.0-nightly (4bf5c99 2017-06-10)

@chyvonomys

This comment has been minimized.

Copy link

chyvonomys commented Oct 4, 2017

Got same internal compiler error on this:

#![feature(conservative_impl_trait)]

struct S {
    v: Vec<u32>,
}

impl S {
    //fn all<'a>(&'a self) -> impl Iterator<Item=&'a u32> {
    fn all(&self) -> impl Iterator<Item=&u32> {
        self.v.iter()
    }
}

fn main() {
    let s = S { v: Vec::new() };
    s.all().count();
}

Specifying lifetimes (as in comment) fixes the problem.
rustc 1.22.0-nightly (4502e2aa9 2017-10-03) running on x86_64-pc-windows-msvc

@cramertj

This comment has been minimized.

Copy link
Member

cramertj commented Jan 5, 2018

This is fixed on the current nightly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment