Only put Debug-like bounds on type variables #371
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
expands into something like
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 markedas
#[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 forevery 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
overHashSet
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