Only put Debug-like bounds on type variables

[sornas]

Resolves #363

Well, at least it's a suggestion for a resolution :p

Synopsis

The problem, as reported in the issue, is that code like the following

#[derive(derive_more::Debug)]
struct Item {
    next: Option<Box<Item>>,
}

expands into something like

impl std::fmt::Debug for Item where Item: Debug { /* ... */ }

which does not compile. This PR changes the Debug derive so it does not emit those bounds.

Solution

My understanding of the current code is that we iterate over all fields of the struct/enum and add either a specific
format bound (e.g. : fmt::Binary), a default : fmt::Debug bound or skip it if either it is marked
as #[debug(skip)] or the entire container has a format attribute.

The suggested solution in the issue (if I understood it correctly) was to only add bounds if the type is a type
variable, since rustc already knows if a concrete type is, say, : fmt::Debug. So, instead of adding the bound for
every type, we first check that the type contains one of the container's type variables. Since types can be nested, it
is an unfortunately long recursive function handling the different types of types. This part of Rust syntax is probably
not going to change, so perhaps it is feasible to shorten some of the branches into _ => false.

One drawback of this implementation is that we iterate over the list of type variables every time we find a "leaf type".
I chose Vec over HashSet because in my experience there are only a handful of type variables per container.

Status

I should add more tests, probably? I've at least verified the case mentioned above (for tuple structs, data structs and
enums). I must admit I haven't really looked in the documentation, but I should probably edit that too.

Checklist

• Documentation is updated (not required)
• Tests are added/updated (if required)
• CHANGELOG entry is added (not required)

[sornas]

This is outside my Rust knowledge, but I'm starting to think this is wrong. If the type is a path (like std::vec::Vec), then it cannot contain a type variable, correct? We only care if it is the only segment or itself a type variable (T in std::vec::Vec<T>) at some part of the path.

[JelteF]

Yes, correct. I think an easy way to test that would be:

#[derive(derive_more::Debug)]
struct Vec {
    next: std::vec::Vec<i32>,
}

[JelteF]

Trait objects can contain type parameters:

trait MyTrait<T> {}

struct Test<T>
{
    t: Box<dyn MyTrait<T>>,
}

[JelteF]

This filtering logic should also apply to the Display derive, not just to the Debug one.

[JelteF]

@sornas I have some time to work on derive_more the next ~2 weeks. Since this is one of the last items that's blocking 1.0, I was wondering if you'll have time to work on this during that time. Otherwise I think I might pick it up to get it over the finish line, if I'm able to get the other 1.0 blockers done.

[sornas]

unfortunately i don't think i'll have time, so feel free to take over. but i'll let you know here if it changes.

[link2xt]

This change resulted in a regression, after updating from 1.0.0-beta.6 to 1.0.0-beta.7 compilation fails in deltachat/deltachat-core-rust#5850

[JelteF]

Hmm, that's not great. Can you make a new issue for this that shows some code that now fails compilation?

[link2xt]

Update: seems to be fixed (or worked around?) in n0-computer/iroh#2578

[link2xt]

I opened an issue #392