Regression: overflow while adding drop-check rules

[Manishearth]

https://users.rust-lang.org/t/drop-check-regression-overflow-while-adding-drop-check-rules-for-struct/3617

use std::sync::Arc;

pub struct DescriptorSet<'a> {
    pub slots: Vec<AttachInfo<'a, Resources>>
}

pub trait ResourcesTrait<'r>: Sized {
    type DescriptorSet: 'r;
}

pub struct Resources;

impl<'a> ResourcesTrait<'a> for Resources {
    type DescriptorSet = DescriptorSet<'a>;
}

pub enum AttachInfo<'a, R: ResourcesTrait<'a>> {
    NextDescriptorSet(Arc<R::DescriptorSet>)
}

fn main() {
    let _x = DescriptorSet {slots: Vec::new()};
}

playpen

gives the error

<anon>:22:9: 22:11 error: overflow while adding drop-check rules for DescriptorSet<'_> [E0320]
<anon>:22     let _x = DescriptorSet {slots: Vec::new()};
                  ^~
<anon>:22:9: 22:11 note: overflowed on enum AttachInfo variant NextDescriptorSet field #0 type: alloc::arc::Arc<DescriptorSet<'_>>
<anon>:22     let _x = DescriptorSet {slots: Vec::new()};
                  ^~
<anon>:22:14: 22:47 error: overflow while adding drop-check rules for DescriptorSet<'_> [E0320]
<anon>:22     let _x = DescriptorSet {slots: Vec::new()};
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<anon>:22:14: 22:47 note: overflowed on enum AttachInfo variant NextDescriptorSet field #0 type: alloc::arc::Arc<DescriptorSet<'_>>
<anon>:22     let _x = DescriptorSet {slots: Vec::new()};
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<anon>:22:36: 22:46 error: overflow while adding drop-check rules for collections::vec::Vec<AttachInfo<'_, Resources>> [E0320]
<anon>:22     let _x = DescriptorSet {slots: Vec::new()};
                                             ^~~~~~~~~~
<anon>:22:36: 22:46 note: overflowed on struct alloc::arc::Arc field `_ptr` type: core::ptr::Shared<alloc::arc::ArcInner<DescriptorSet<'_>>>
<anon>:22     let _x = DescriptorSet {slots: Vec::new()};
                                             ^~~~~~~~~~
error: aborting due to 3 previous error

cc @pnkfelix

[arielb1]

Trait matching creates a region that is equated with our current region each time it runs, but our recursion-detection can't handle this. Annoying.

I think we should have a unification system for regions to deal with this (ping @nikomatsakis).

[neon64]

Hi, I discovered this regression as I was fiddling around with one of my projects, and therefore I'm pretty motivated to try and fix it as it currently prevents me from continuing. I took a look at where the error was reported inside dropck.rs and was quickly overwhelmed by the logic and complexity, however I would like to have a crack at some sort of (hacky) fix.

@arielb1 the 'unification system for regions' sounds pretty complex, but if it is possible to explain the workings of that to a mere mortal like me then I'd be happy to do the 'plumbing' work on any implementation.

Also I find I solve problems a lot by visualising the data etc, and I was wondering how you handle debugging. I've recently switched from 'managed' languages like Java and I really miss the complete runtime inspection capabilities of something like the IntelliJ idea debugger. Is it possible to use gdb for that or do you just resort to a bunch of println!("{:?}", foo); statements everywhere?

[Manishearth]

gdb works with rust. You need to compile rust in debug mode (I think make RUSTFLAGS='-g' would work? not sure) though.

[arielb1]

@neon64

A unification system for regions isn't something I would want a beginner to do - either me or @nikomatsakis should do it.

I do most of my rustc debugging by using the logs - RUST_LOG=rustc::middle::traits and look at the output. Debuggers have a tendency of not being useful with the complex data structures and functions rustc uses.

[nikomatsakis]

@arielb1 yes, I've encountered this problem, but I am not sure what answer I prefer. A unification system for regions is one thing I considered, along with an alternate scheme for inferring substitutions. I had the latter up and working (I can't find the branch just now) but was dissatisfied with it in some ways that I don't remember now -- the main thing was that instead of creating fresh type variables for every impl parameter, it would first try to deduce the values for the type variables by looking at the trait reference. e.g., if we had impl<T> Foo<T> for i32, and the trait reference was Foo<u32> for i32, we would not make a variable $T that gets unified with u32, we'd just compute a substitution T=u32 first off. In some cases, we had to fall back to unification variables (e.g., projections).

[arielb1]

@nikomatsakis

I was also thinking of some kind of "trait IR" to speed up trait matching, but the full set of required operations requires some kind of unification, so we will not completely eliminate the problem. Maybe I should be working on region unification?

[nikomatsakis]

triage: P-high

This is a regression, so giving P-high, but given that the fix may involve changing some fundamental infrastructure we have to be a bit wary.