-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enum pretty-printing #559
Enum pretty-printing #559
Conversation
When we switched from representing enums as Rust enums to representing them as newtypes around numbers, the derived Debug implementation followed and instead of printing pretty names, we got just numbers. This commit stops deriving a Debug implementation and instead one is implemented manually. The new Debug impl uses the alternate() flag to decide between UPPER_CASE and CamelCase. By default, the UPPER_CASE representation that is now also used in the source is used. With the alternate() flag, CamelCase is used instead. This also prints bitmasks as combinations of the individual values. For example, ModMask::SHIFT | ModMask::LOCK actually is represented as "SHIFT | LOCK". This was not possible before when we used a Rust enum to represent these. Signed-off-by: Uli Schlachter <[email protected]>
Rebased on master |
a073437
to
a3d0b4a
Compare
let variants = [ | ||
(Self::RAW_RECTANGLES.0.into(), "RAW_RECTANGLES", "RawRectangles"), | ||
(Self::DELTA_RECTANGLES.0.into(), "DELTA_RECTANGLES", "DeltaRectangles"), | ||
(Self::BOUNDING_BOX.0.into(), "BOUNDING_BOX", "BoundingBox"), | ||
(Self::NON_EMPTY.0.into(), "NON_EMPTY", "NonEmpty"), | ||
]; | ||
pretty_print_enum(fmt, self.0.into(), &variants) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not a match
(or two depending on fmt
)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bad reason: I started writing the bit
variant and then made the other version similar.
Slightly better reason, but I am not sure if this is true: #488. I hope that we only end up with one implementation of the code in the binary that just searches through some lookup table. With a match
, I fear that the binary size would be larger. However, I didn't test this and it is just a theory.
Also: Two match
es would mean more lines of code. :-)
Signed-off-by: Uli Schlachter <[email protected]>
Clippy complained about: useless conversion to the same type: `u32` Signed-off-by: Uli Schlachter <[email protected]>
error: very complex type used. Consider factoring parts into `type` definitions --> src/utils.rs:286:14 | 286 | ) -> CallbackFormating<'a, 'b, fn(&mut Formatter<'_>, u32, &[(u32, &str, &str)]) -> Result> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: `-D clippy::type-complexity` implied by `-D warnings` = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#type_complexity Signed-off-by: Uli Schlachter <[email protected]>
d3cb811
to
cf46b9a
Compare
In commit 7e4ea9c, I only fixed one of the two cases of "useless identity conversion". This commit also fixes the other half of the problem. Signed-off-by: Uli Schlachter <[email protected]>
Yay, I have just tested this and it works just as I wanted it 🙂 |
This supersedes #555 and depends on #556 (the commit from that PR is included in this one).
CC #554 and @andrewshadura