ICE !ty.needs_infer() && !ty.has_placeholders() from boxing closure of type dyn for<'a> _
#57843
Comments
sfackler
added
the
I-ICE
|
Happens on 1.33.0-beta.3 (!) and 1.33.0-nightly (4c2be9c 2019-01-22), but not on stable. The ICE does not occur, if you change the line to Was introduced with nightly-2019-01-04, so somewhere between ec19464...c0bbc39 |
|
Based on the commits I guess @nikomatsakis should be able to say something about it |
Centril
added
A-type-system
|
triage. Confirm P-high. Assigning to self for initial investigation. |
|
I have confirmed that this was injected by #55517 |
|
(We've been asserting Also, something potentially of note: #50197 changed the definition of
|
|
@nick-fischer I don't know if this is of interest to you, but I did find that if you use this slightly different variant with an explicit type on the closure parameter, the code compiles (play): trait ClonableFn<T> {
fn clone(&self) -> Box<dyn Fn(T)>;
}
impl<T, F: 'static> ClonableFn<T> for F
where F: Fn(T) + Clone {
fn clone(&self) -> Box<dyn Fn(T)> {
Box::new(self.clone())
}
}
struct Foo(Box<dyn for<'a> ClonableFn<&'a bool>>);
fn main() {
Foo(Box::new(|_: &bool| ()));
// ~~~~~~~ this is what changed
} |
|
Interesting ... Thank you! |
pnkfelix
changed the title
!ty.needs_infer() && !ty.has_placeholders() from box of closure with dyn for<'a> type.
pnkfelix
changed the title
!ty.needs_infer() && !ty.has_placeholders() from box of closure with dyn for<'a> type.!ty.needs_infer() && !ty.has_placeholders() from boxing closure of type dyn for<'a> _
…elix make generalization code create new variables in correct universe In our type inference system, when we "generalize" a type T to become a suitable value for a type variable V, we sometimes wind up creating new inference variables. So, for example, if we are making V be some subtype of `&'X u32`, then we might instantiate V with `&'Y u32`. This generalized type is then related `&'Y u32 <: &'X u32`, resulting in a region constriant `'Y: 'X`. Previously, however, we were making these fresh variables like `'Y` in the "current universe", but they should be created in the universe of V. Moreover, we sometimes cheat in an invariant context and avoid creating fresh variables if we know the result must be equal -- we can only do that when the universes work out. Fixes #57843 r? @pnkfelix
While experimenting with clonable closures (and encountering like a thousand
one type is more general than the othererrors), I eventually discovered a scenario which crashes rustc.I tried this code (play:
I expected to see this happen: Actually, I am not sure ... Anyways, I guess I expected to see rustc surviving the input ...
Meta
rustc --version --verbose:rustc 1.33.0-nightly (c0bbc39 2019-01-03)
binary: rustc
commit-hash: c0bbc39
commit-date: 2019-01-03
host: x86_64-unknown-linux-gnu
release: 1.33.0-nightly
LLVM version: 8.0
Backtrace:
The text was updated successfully, but these errors were encountered: