-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Nightly rustc crashes with "unexpected region in query response" #57464
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Works fine with stable and Steps to repro: git clone https://github.com/graphql-rust/juniper.git;
cd juniper/juniper_hyper;
cargo test; |
I bisected: $ cargo-bisect-rustc --test-dir=./juniper/juniper_hyper/ --start=b2b7a063af39455d7362524da3123c34c3f4842e --end=f381a9625 --script ./juniper/juniper_hyper/test.sh
regression in c0bbc3927e28c22edefe6a1353b5ecc95ea9a104 So the regression was caused by c0bbc39. |
Which was this PR: #55517. /cc @nikomatsakis |
triage: P-high. assigning to self for initial investigation. |
@LegNeato thanks for bisecting |
@nikomatsakis friendly ping since this is now a |
I have narrowed this down to a single file test case that depends solely on Code (play): #![allow(unreachable_code)]
extern crate futures;
use futures::future::{join_all, poll_fn, done, ok};
use futures::future::Future;
use futures::future::Either;
use futures::Async;
fn main() {
let _b: Box<Future<Item = _, Error = _> + Send>;
_b = Box::new(graphql());
}
struct BlockingError;
struct Request;
struct RequestError;
struct RootNode2<'a> { _schema: &'a (), }
fn graphql() -> impl Future<Item = Vec<()>, Error = BlockingError>
{
match () {
_ if false => Either::A(done(Err(RequestError)).or_else(|_| ok(vec![]))),
_ => Either::B(
done(Err(RequestError))
.and_then(|_: Request| join_all(Some(&unimplemented!()).into_iter()
.map(|root_node: &RootNode2<'static>| {
poll_fn(|| {
&root_node;
Ok(Async::Ready(()))
})
})))
.or_else(|_| ok(vec![]))),
}
} |
(my planned next step is to remove the dependence on the |
Okay I've now reduced it to a single file that only depends on Code (play): pub struct AndThen<B, F>(B, F);
fn and_then<F, B>(_: F) -> AndThen<B, F> where F: FnOnce() -> B { unimplemented!() }
pub trait Trait { }
impl<B, F> Trait for AndThen<B, F> { }
pub struct JoinAll<I> where I: Iterator { _elem: std::marker::PhantomData<I::Item> }
pub fn join_all<I>(_i: I) -> JoinAll<I> where I: Iterator { unimplemented!() }
pub struct PollFn<F, T>(F, std::marker::PhantomData<fn () -> T>);
pub fn poll_fn<T, F>(_f: F) -> PollFn<F, T> where F: FnMut() -> T { unimplemented!() }
impl<B, I: Iterator, F> Iterator for Map<I, F> where F: FnMut(I::Item) -> B {
type Item = B;
fn next(&mut self) -> Option<B> { unimplemented!() }
}
struct Map<I, F> { iter: I, f: F }
fn main() { let _b: Box<Trait + Send> = Box::new(graphql()); }
fn graphql() -> impl Trait
{
let local = ();
let m = |_: ()| poll_fn(|| { local; });
let v = Map { iter: std::iter::once(()), f: m };
let f = || join_all(v);
and_then(f)
} Its pretty hard to reduce it past this point though. There's a lot of inter-depedencies; I assume the bug is arising from some nasty interactions between normalizing the various associated items above along with the But in any case a standalone file gives us a much better place to work from now. |
There is a comment above the ICE in question: rust/src/librustc/infer/canonical/canonicalizer.rs Lines 190 to 194 in 1349c84
Looking at the RUST_LOG output here, I wonder if there are any obvious counter-examples to that claim that we should never see any names apart from In particular, I see: DEBUG 2019-02-21T14:05:41Z: rustc::infer::region_constraints: RegionConstraintCollector: add_constraint(VarSubReg('_#2r, ReScope(CallSite(16)))) Does the presence of that constraint provide a hint as to how not-exactly-named regions are leaking into the canonicalization... (or maybe we should be cleaning out such regions before they leak out into the |
…aks-into-impl-trait, r=pnkfelix avoid ICE when region sneaks into impl trait Addresses non-NLL instances of #57464
With the latest nightly I now get:
Which seems suspect as the first fix for this was adding Config:
Will that be fixed with the newest PR? |
Self contained example that still ICEs with AST borrowck on nightly: use std::{iter, slice};
struct A<T>(T);
unsafe impl<'a, 'b, F, G> Send for A<iter::Map<iter::Map<slice::Iter<'_, usize>, F>, G>>
where
F: FnOnce(&'a usize) -> &'b usize
{}
fn iter<'a>(data: &'a [usize]) -> impl Sized + 'a {
A(data.iter()
.map(
|x| x // FnMut(&'a usize) -> &'(ReScope) usize
)
.map(
|x| *x // FnMut(&'(ReScope) usize) -> usize
))
}
fn main() {
let x: Box<dyn Send> = Box::new(iter(&[1, 2, 3]));
} |
A smaller case: struct A<F>(F);
unsafe impl <'a, 'b, F: Fn(&'a i32) -> &'b i32> Send for A<F> {}
fn wrapped_closure() -> impl Sized {
let z = 0;
let f = |x| x;
f(&z);
A(f)
}
fn main() {
let x: Box<dyn Send> = Box::new(wrapped_closure());
} |
(I've closed PR #58839 since @matthewjasper found cases that it did not address. I will attempt to look into the root problem.) |
[DO NOT MERGE] Forbid closures that outlive their signature * This prevents the AST borrow checker from incorrectly accepting closures that return references to local variables and that are never called. Note: NLL already fixes this. * This also ensures that existential types don't end up containing any `ReScope`s. This is the principled solution to #57464. Opening this for a crater run to see how much code this affects. The second issue occurs twice in this repo: * `src/librustc_metadata/decoder.rs` * `src/test/run-pass/regions/regions-relate-bound-regions-on-closures-to-inference-variables.rs`
…r=pnkfelix Constrain all regions in the concrete type for an opaque type `push_outlives_components` skips some regions in a type, notably the signature of a closure is ignored. Most of the time this is OK, but for opaque types the concrete type is used when checking auto-trait bounds in other functions. cc @nikomatsakis @pnkfelix Closes rust-lang#57464 Closes rust-lang#60127
…r=pnkfelix Constrain all regions in the concrete type for an opaque type `push_outlives_components` skips some regions in a type, notably the signature of a closure is ignored. Most of the time this is OK, but for opaque types the concrete type is used when checking auto-trait bounds in other functions. cc @nikomatsakis @pnkfelix Closes rust-lang#57464 Closes rust-lang#60127
…r=pnkfelix Constrain all regions in the concrete type for an opaque type `push_outlives_components` skips some regions in a type, notably the signature of a closure is ignored. Most of the time this is OK, but for opaque types the concrete type is used when checking auto-trait bounds in other functions. cc @nikomatsakis @pnkfelix Closes rust-lang#57464 Closes rust-lang#60127
…r=pnkfelix Constrain all regions in the concrete type for an opaque type `push_outlives_components` skips some regions in a type, notably the signature of a closure is ignored. Most of the time this is OK, but for opaque types the concrete type is used when checking auto-trait bounds in other functions. cc @nikomatsakis @pnkfelix Closes rust-lang#57464 Closes rust-lang#60127
Hi, I really need this fix to compile an |
@z0mbie42 I don't think anyone felt the bug was widespread enough to justify a backport of PR #60449 to the beta/stable channels. Or at least, no one nominated it for such. PR #60449 landed on nightly 13 days ago, and the beta->stable and nightly->beta rollovers will occur next week. We do not have enough time between now and next week to backport PR #60449 to beta before the beta->stable rollover. But I also don't want to dismiss the idea of trying to get the fix backported all the way to the stable channel. (I don't think a backport is terribly likely, but the team should at least discuss it at the meeting next Thursday.) I'll go ahead and nominate PR #60449 for the backport. |
I'm voicing my support for backporting to beta. This has broken juniper_hyper for many months on stable. With a beta backport at least it will be fixed quite a bit earlier. |
Update: Reduced test case in below comment
Just got this rustc crash in
juniper_hyper
in CI runningcargo test
:Full Backtrace:
The text was updated successfully, but these errors were encountered: