-
Notifications
You must be signed in to change notification settings - Fork 124
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
## Synopsis The problem, as reported in the issue, is that code like the following ```rust #[derive(derive_more::Debug)] struct Item { next: Option<Box<Item>>, } ``` expands into something like ```rust 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. Co-authored-by: Jelte Fennema-Nio <github-tech@jeltef.nl> Co-authored-by: Kai Ren <tyranron@gmail.com>
- Loading branch information
1 parent
af823ea
commit 162535e
Showing
3 changed files
with
276 additions
and
6 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters