ICE "anonymous bound region BrAnon(0) in return but not args"

[SimonSapin]

rustc 1.21.0-nightly (aac223f 2017-07-30) ICEs on https://github.com/rtbo/rust-xcb (full output below), although 1.20.0-beta.1 and some not-much-older nightlies succeed.

Some more context around the line in the error message:

#[repr(C)]
pub struct xcb_depth_iterator_t<'a> {
    pub data:  *mut xcb_depth_t,
    pub rem:   c_int,
    pub index: c_int,
    _phantom:  std::marker::PhantomData<&'a xcb_depth_t>,
}
// […]
#[link(name="xcb")]
extern {
// […]
    pub fn xcb_screen_allowed_depths_iterator (R: *const xcb_screen_t)
            -> xcb_depth_iterator_t;

So the xcb_depth_iterator_t does have lifetime parameter that’s elided in this function declaration’s return type without any elided lifetime in the parameters. Maybe this code should indeed be rejected, but in that case we need a proper error message rather than a compiler panic. Although it used to be accepted, so this is a breaking change. Adding an explicit lifetime parameter to the function fixes this, but that’s not easy to do properly since this is generated code.

Full output:

% RUST_BACKTRACE=1 cargo +nightly build -v
       Fresh log v0.3.8
       Fresh libc v0.2.28
   Compiling xcb v0.8.0 (file:///home/simon/projects/rust-xcb)
     Running `rustc --crate-name xcb src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=f22742bf239db509 -C extra-filename=-f22742bf239db509 --out-dir /home/simon/projects/rust-xcb/target/debug/deps -L dependency=/home/simon/projects/rust-xcb/target/debug/deps --extern log=/home/simon/projects/rust-xcb/target/debug/deps/liblog-2b956ee286098ab8.rlib --extern libc=/home/simon/projects/rust-xcb/target/debug/deps/liblibc-c727996240879c34.rlib`
error: internal compiler error: /checkout/src/librustc_typeck/astconv.rs:1267: anonymous bound region BrAnon(0) in return but not args
    --> src/ffi/xproto.rs:5654:16
     |
5654 |             -> xcb_depth_iterator_t;
     |                ^^^^^^^^^^^^^^^^^^^^

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

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.21.0-nightly (aac223f4f 2017-07-30) running on x86_64-unknown-linux-gnu

note: run with `RUST_BACKTRACE=1` for a backtrace

thread 'rustc' panicked at 'Box<Any>', /checkout/src/librustc_errors/lib.rs:438:8
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:380
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:390
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:610
   5: std::panicking::begin_panic
   6: rustc_errors::Handler::span_bug
   7: rustc::session::opt_span_bug_fmt::{{closure}}
   8: rustc::session::span_bug_fmt
   9: <rustc_typeck::astconv::AstConv<'gcx, 'tcx> + 'o>::ty_of_fn
  10: rustc_typeck::collect::fn_sig
  11: rustc::dep_graph::graph::DepGraph::with_task
  12: rustc::ty::maps::<impl rustc::ty::maps::queries::fn_sig<'tcx>>::try_get
  13: rustc::ty::maps::TyCtxtAt::fn_sig
  14: rustc::ty::maps::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'lcx>>::fn_sig
  15: <rustc_typeck::collect::CollectItemTypesVisitor<'a, 'tcx> as rustc::hir::intravisit::Visitor<'tcx>>::visit_item
  16: rustc_typeck::check_crate::{{closure}}::{{closure}}
  17: rustc_typeck::check_crate
  18: rustc_driver::driver::phase_3_run_analysis_passes::{{closure}}
  19: rustc_driver::driver::phase_3_run_analysis_passes
  20: rustc_driver::driver::compile_input
  21: rustc_driver::run_compiler

error: Could not compile `xcb`.

Caused by:
  process didn't exit successfully: `rustc --crate-name xcb src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=f22742bf239db509 -C extra-filename=-f22742bf239db509 --out-dir /home/simon/projects/rust-xcb/target/debug/deps -L dependency=/home/simon/projects/rust-xcb/target/debug/deps --extern log=/home/simon/projects/rust-xcb/target/debug/deps/liblog-2b956ee286098ab8.rlib --extern libc=/home/simon/projects/rust-xcb/target/debug/deps/liblibc-c727996240879c34.rlib` (exit code: 101)

[petrochenkov]

Must be a regression from #43543

Looks like #32330 wasn't fixed in foreign functions :(
I'll prepare a patch.

[SimonSapin]

@petrochenkov Do you mean a patch that would make xcb compile, or produce a better error message?

[petrochenkov]

@SimonSapin
Don't know yet, need to look closer.
A proper fix may require a warning, deprecation period, etc, but immediate fix for the ICE making xcb compile can always be done by partially reverting #43543.

[SimonSapin]

Ok, thanks for looking into it.

[Mark-Simulacrum]

Performance collection for the style crate is also broken because of this.

[eddyb]

cc @nikomatsakis Should we add elision logic to foreign functions?

[Manishearth]

#43594 has a simpler testcase that also involves elision.

Also, yes, I think elision should work on FFI. Firstly, it used to, and it's a breaking change otherwise.

Secondly, this is extremely useful when paired with bindgen to have a modicum of safety wrt returning non-owners pointers from FFI. Dereferenced raw pointers yield values of arbitrary lifetime, and guarding against this in FFI-heavy code is extremely tedious. In an FFI-heavy project the risk of introducing unsafety in the FFI layer can outweigh the risk of just writing it all in C++, largely due to things like this.

[eddyb]

@Manishearth Elision never worked, what you were getting was an unbound lifetime in the return.