ReSkolemized can leak into error messages

examples/examples.rs:46:26: 46:34 error: lifetime of function argument does not outlive the function call
examples/examples.rs:46     let f = SlotAny::new(two_args);
                                                 ^~~~~~~~
note: the function argument is only valid for lifetime ReInfer(ReSkolemized(0u, BrAnon(0u)))
error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug.
note: we would appreciate a bug report: http://static.rust-lang.org/doc/master/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
task 'rustc' failed at 'assertion failed: !ty::type_needs_infer(ty)', /Users/rustbuild/src/rust-buildbot/slave/nightly-mac/build/src/librustc/middle/typeck/mod.rs:251
stack backtrace:
   1:        0x10c3c9a64 - rt::backtrace::imp::write::habc56a229da3d9445Ea::v0.11.pre
   2:        0x10c31e00e - rt::unwind::begin_unwind_inner::he30d2051ed995551bfa::v0.11.pre
   3:        0x10c31d4c7 - rt::unwind::begin_unwind_fmt::h6e44c556d6cd8deelea::v0.11.pre
   4:        0x109914c56 - middle::typeck::write_ty_to_tcx::h2b827da2c5dd52b30fu::v0.11.pre
   5:        0x10991135e - middle::typeck::check::writeback::resolve_type_vars_for_node::h56adc403301d71a1TS1::v0.11.pre
   6:        0x10991583a - middle::typeck::check::writeback::visit_expr::hf20f6553222bc96ft51::v0.11.pre
   7:        0x109915b3d - middle::typeck::check::writeback::visit_expr::hf20f6553222bc96ft51::v0.11.pre
   8:        0x109917a6e - middle::typeck::check::writeback::visit_local::h60d5d5890d438f00Ja2::v0.11.pre
   9:        0x109915570 - middle::typeck::check::writeback::visit_stmt::h57274c9f7367d7c8T41::v0.11.pre
   10:        0x109917023 - visit::walk_block::h4813911114547969337::v0.11.pre
  11:        0x10991a312 - middle::typeck::check::writeback::resolve_type_vars_in_fn::h648841adac5a5f12yn2::v0.11.pre
  12:        0x10996ae17 - middle::typeck::check::check_bare_fn::h727d76d1a8c0577cx36::v0.11.pre
  13:        0x109962d4e - middle::typeck::check::check_item::hb3e06af45cad1763Uz7::v0.11.pre
  14:        0x10996ab2d - middle::typeck::check::check_item_types::h4794d86cd018c594P26::v0.11.pre
  15:        0x109aad54f - util::common::time::h13076619411820452536::v0.11.pre
  16:        0x109aac47d - middle::typeck::check_crate::h979c5052f97482abIzu::v0.11.pre
  17:        0x109eb5b21 - driver::driver::phase_3_run_analysis_passes::ha118c3d47f9c07e1Ssf::v0.11.pre
  18:        0x109ebb572 - driver::driver::compile_input::h09b012d109a97ff53Rf::v0.11.pre
  19:        0x109ee1ba7 - run_compiler::h1896b068d115fa30akn::v0.11.pre
  20:        0x109ef9afd - main_args::closure.91270
  21:        0x109ef7e92 - monitor::closure.91145
  22:        0x109ef2a7b - task::TaskBuilder::try::closure.90911
  23:        0x109665d6c - task::spawn_opts::closure.7135
  24:        0x10c3bfa68 - rt::task::Task::run::closure.40347
  25:        0x10c3cec4c - rust_try
  26:        0x10c3bf8e7 - rt::task::Task::run::ha1efa04543646d12L57::v0.11.pre
  27:        0x109665bef - task::spawn_opts::closure.7107
  28:        0x10c3c8436 - rt::thread::thread_start::h2d864941e9d800a8YK8::v0.11.pre
  29:     0x7fff8ce75899 - _pthread_body
  30:     0x7fff8ce7572a - _pthread_struct_init

Do you have an example of a code snippet to reproduce this ICE?

In the code that caused the error I am importing from a library I am building, but if I copy paste the library code into the file, I get error: cannot determine a type for this local variable: unconstrained type instead.

Basically what I have (This does not reproduce the compiler error):

pub struct Foo<T> {
    listener: fn(&T)
}

impl<T> Foo<T> {
    pub fn new(listener: fn(&T)) -> Foo<T> {
        Foo {
            listener: listener
        }
    }
}

fn hello<T>(args: T) {
    println!("hello");
}

fn main() {
    let f = Foo::new(hello);
}

@jmmk

@jmmk Could you at least link that library then so we can reproduce it?

@luqmana

@luqmana sorry for the slow response, but I finally got around to looking at this again.

I just tested this on the newest nightly and it gives the compiler error:

pub struct Foo<T> {args: T}

impl<T> Foo<T> {
    pub fn new(args: T) -> Foo<T> {
        Foo {args: args}
    }

    pub fn connect(&mut self, slot: Bar<T>) {}
}

pub struct Bar<T> {pub listener: fn(&T)}

impl<T> Bar<T> {
    pub fn new(listener: fn(&T)) -> Bar<T> {
        Bar {listener: listener}
    }
}

fn two_args<T>(args: T) {
}

fn main() {
    let mut changed_args = Foo::new((2i));
    let f = Bar::new(two_args);

    changed_args.connect(f);
}

Stacktrace:

task 'rustc' failed at 'assertion failed: !ty::type_needs_infer(ty)', /Users/rustbuild/src/rust-buildbot/slave/nightly-mac/build/src/librustc/middle/typeck/mod.rs:280

stack backtrace:
   1:        0x104335c88 - rt::backtrace::imp::write::hae692894f5f1f1ebUbq
   2:        0x104339475 - failure::on_fail::h75f9b8d6f426596adsq
   3:        0x1045e5fe9 - unwind::begin_unwind_inner::h54dfeb5a2036a633AXd
   4:        0x1045e5b77 - unwind::begin_unwind_fmt::hadacf5a3687620033Ud
   5:        0x1015df64c - middle::typeck::write_ty_to_tcx::h44d1c821ecaca6a0RUD
   6:        0x1015d8ef5 - middle::typeck::check::writeback::WritebackCx<'cx>::visit_node_id::h151214da46fae4c2Ey8
   7:        0x1015d603e - middle::typeck::check::writeback::WritebackCx<'cx>.Visitor<(*>::visit_expr::hdfef6feeff4c2b95ho8
   8:        0x1015d62fe - middle::typeck::check::writeback::WritebackCx<'cx>.Visitor<(*>::visit_expr::hdfef6feeff4c2b95ho8
   9:        0x1015dba36 - middle::typeck::check::writeback::WritebackCx<'cx>.Visitor<(*>::visit_local::he925f9cb37ed8a8aTt8
  10:        0x1015df0a3 - visit::walk_block::h1604224355725969978
  11:        0x1015d758f - middle::typeck::check::writeback::resolve_type_vars_in_fn::h960409d3de2a563evi8
  12:        0x1016364ef - middle::typeck::check::check_bare_fn::h5b61e7a34e8f1873oVd
  13:        0x10162fae2 - middle::typeck::check::check_item::hd7449b378454e2d6zse
  14:        0x1016361fd - middle::typeck::check::check_item_types::h89c2a47746b27eceGUd
  15:        0x10179b6fe - middle::typeck::check_crate::h86d2524029231b02vfE
  16:        0x101b49599 - driver::driver::phase_3_run_analysis_passes::h858b7dce24b9b32fVEs
  17:        0x101b449c1 - driver::driver::compile_input::h544a5b5acde2ff3bWqs
  18:        0x101bf6a1c - driver::run_compiler::hfcfc73e0e640751fZov
  19:        0x101bf4056 - driver::main_args::closure.Name(134079*
  20:        0x101c074bb - task::TaskBuilder<S>::try_future::closure.Name(135228*
  21:        0x101c073b1 - task::TaskBuilder<S>::spawn_internal::closure.Name(135205*
  22:        0x1012e463c - task::spawn_opts::closure.Name(8249*
  23:        0x1046499ac - rust_try
  24:        0x1045e2d4b - unwind::try::ha8241ded872b0a50ZLd
  25:        0x1045e2ab3 - task::Task::run::hff5823cf81f02aafRXc
  26:        0x1012e44d1 - task::spawn_opts::closure.Name(8194*
  27:        0x1045e4d46 - thread::thread_start::h73513dc0bb2d1001pkd
  28:     0x7fff90266899 - _pthread_body
  29:     0x7fff9026672a - _pthread_struct_init

The error message for this code is looking much nicer:

13998.rs:24:22: 24:30 error: mismatched types:
 expected `fn(&_)`,
    found `fn(_) {two_args}`
(expected concrete lifetime,
    found bound lifetime parameter ) [E0308]
13998.rs:24     let f = Bar::new(two_args);
                                 ^~~~~~~~
13998.rs:24:22: 24:30 help: run `rustc --explain E0308` to see a detailed explanation

I think there's still room for improvement here. Perhaps the E0308 explanation could give an example and explain what the problem is (and what "concrete lifetime" and "bound lifetime parameter" mean, possibly)

crappy error message still possible:

fn foo(f: for<'a,'b> fn(&'a ()) -> &'a &'b ()) {
    bar(f);
}

fn bar(f: for<'a,'b> fn(&'b ()) -> &'a &'b ()) {
}

fn main() {}

gives

<anon>:2:9: 2:10 error: mismatched types:
 expected `fn(&'b ()) -> &'a &'b ()`,
    found `fn(&'a ()) -> &'a &'b ()`
(expected concrete lifetime,
    found bound lifetime parameter 'a) [E0308]
<anon>:2     bar(f);
                 ^
<anon>:2:9: 2:10 help: see the detailed explanation for E0308
note: expected concrete lifetime is lifetime ReSkolemized(0, BrNamed(DefId { krate: 0, node: 31 }, 'b(64)))
error: aborting due to previous error
playpen: application terminated with error code 101

Continuing on to 2016:

struct RunLoop<'a> {
    marker: &'a u8,
}

struct MyContext<'a> {
    rl: &'a mut RunLoop<'a>,
}

fn run<'a>(rl: &'a mut RunLoop<'a>) {
    let mut ctxt = MyContext { rl: rl };
}

fn register(func: fn(&mut RunLoop)) {}

fn main() {
    register(run);
}

error: mismatched types [--explain E0308]
  --> src/main.rs:16:14
16 |>     register(run);
   |>              ^^^ expected concrete lifetime, found bound lifetime parameter
note: expected type `fn(&mut RunLoop<'_>)`
note:    found type `fn(&'a mut RunLoop<'a>) {run}`
note: expected concrete lifetime is lifetime ReSkolemized(0, BrAnon(0))

@estebank

@estebank This happens on master with nll enabled, e.g. this ui test:

rust/src/test/ui/async-await/issues/issue-63388-1.nll.stderr

Lines 1 to 7 in ece4977

    
           error[E0700]: hidden type for `impl Trait` captures lifetime that does not appear in bounds 
        
             --> $DIR/issue-63388-1.rs:12:10 
        
              | 
        
           LL |     ) -> &dyn Foo 
        
              |          ^^^^^^^^ 
        
              | 
        
              = note: hidden type `impl std::future::Future` captures lifetime '_#22r

Notice: captures lifetime '_#22r

I feel that even though the general problem is the same as originally reported, it is different enough that it would have warranted making a new ticket.

That being said, thanks for digging up a relevant test to keep track of the fix.

Triage: this FIXME is still here

rust/compiler/rustc_infer/src/infer/error_reporting/mod.rs

Lines 103 to 110 in 41dc394

    
           // FIXME(#13998) RePlaceholder should probably print like 
        
           // ReFree rather than dumping Debug output on the user. 
        
           // 
        
           // We shouldn't really be having unification failures with ReVar 
        
           // and ReLateBound though. 
        
           ty::ReVar(_) | ty::ReLateBound(..) | ty::ReErased => { 
        
               (format!("lifetime {:?}", region), None) 
        
           }

https://github.com/rust-lang/rust/blob/master/src/test/ui/async-await/issues/issue-63388-1.stderr no longer shows a repro, but https://github.com/rust-lang/rust/blob/8cc87250efc5b5fcec85d43eaa73f7a9acc2198a/src/test/ui/nll/closure-requirements/escape-argument-callee.stderr does

I believe that the only cases where we still show these is when using -Zverbose. Do we have any counter-example? Otherwise I'm tempted at just closing this.

Steve's linked code is still there, but changing it has no effect anywhere in the test suite. This is not positive proof of anything, but I believe it might be code only accessible through -Zverbose. I will go ahead and close this.

Fix up `DescriptionCtx::new`.

added Default impls

Use clearer multipart suggestions for `unnecessary_map_or` lint (rust…

Make `unnecessary_map_or` work with ref and `Deref` to `Option`/`Resu…

Navigation Menu

Repository navigation

ReSkolemized can leak into error messages #13998

9 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	error[E0700]: hidden type for `impl Trait` captures lifetime that does not appear in bounds
	--> $DIR/issue-63388-1.rs:12:10
	\|
	LL \| ) -> &dyn Foo
	\| ^^^^^^^^
	\|
	= note: hidden type `impl std::future::Future` captures lifetime '_#22r

	// FIXME(#13998) RePlaceholder should probably print like
	// ReFree rather than dumping Debug output on the user.
	//
	// We shouldn't really be having unification failures with ReVar
	// and ReLateBound though.
	ty::ReVar(_) \| ty::ReLateBound(..) \| ty::ReErased => {
	(format!("lifetime {:?}", region), None)
	}

ReSkolemized can leak into error messages #13998

Description

Activity

alexcrichton commented on May 6, 2014

jmmk commented on May 6, 2014

luqmana commented on May 7, 2014

jmmk commented on Jul 14, 2014

nham commented on Jun 4, 2015

arielb1 commented on Aug 18, 2015

shepmaster commented on Aug 23, 2016

9 remaining items

mark-i-m commented on Oct 10, 2019

estebank commented on Oct 10, 2019

steveklabnik commented on Sep 18, 2020

estebank commented on Jul 26, 2022

estebank commented on Jan 5, 2023

estebank commented on Jan 19, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions