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.
This is a considerable update of the proc macro which supports optional custom format strings per variant with full access to variant fields via the
#[variant_display(format = "xyz")]
attribute.I recommend reading the code in isolation rather than as a diff.
Summary
EnumAttrs
which handles parsing of the mainenum_display
attributeVariantAttrs
which handles parsing of the newvariant_display
field attributevariant_display
field attribute allows the user to customise each variantformat = "xyz"
argument defines a custom display format (see below for Format Behaviour) - if omitted, the original crate behaviour is usedVariantInfo
holds properties common to all variant typesNamedVariantIR
,UnnamedVariantIR
, andUnitVariantIR
are the intermediate representations of variant typesVariantIR
wraps all of thosesyn
tokens is moved to thefrom_*()
methods ofEnumAttrs
,VariantAttrs
, andVariantIR
VariantIR::gen()
methodFormat Behaviour
Format strings behave almost identically to using
format!()
in normal rust code so it should be very familiar to users. Besides a bit of translation of unnamed fields, the string specified by the user is the string that ends up as the parameter toformat!()
in each match arm.The following considerations apply:
{variant}
placeholderVariant { my_field: u32 }
, you use the{my_field}
placeholderVariant(u32)
, you use the{0}
placeholder (to access the first tuple element){my_field:?}
displaysmy_field
using itsDebug
implementation,{0:5}
displays the first unnamed field with a width of 5 - however - format spec options which depend on extra arguments passed intoformat!()
are not supportedAdditional Notes
format!()
- perhaps instead, we should extern alloc and hide it behind a feature flag?main
- let me know if you want them separated. Otherwise merging Implement generics, lifetimes, bounds and where clause support #4 first or discarding and just merging this would also work.Full examples