Derive common traits for various types in uart and i2c drivers
#2825
Conversation
I opted to manually implement it like https://github.com/esp-rs/esp-hal/pull/2823/files#diff-f2b53d5313d6241262548c66be719b207cf49feadd833841f499ed4afdf1dfe2R441 . What do you think about that? |
|
This PR also closes #2788, as it implements |
jessebraham
force-pushed
the
fixes/c-common-traits
branch
2 times, most recently
from
2e93fec to
79df783
Compare
jessebraham
force-pushed
the
fixes/c-common-traits
branch
from
79df783 to
1a1bfe7
Compare
|
|
||
| impl core::fmt::Display for ConfigError { | ||
| fn fmt(&self, _f: &mut core::fmt::Formatter<'_>) -> core::fmt::Result { | ||
| Ok(()) |
There was a problem hiding this comment.
This looks a little insane, but #2831 will add some variants and so once this is merged, it can be rebased on top of these changes and a proper implementation can be added for this.
There was a problem hiding this comment.
Would strum::Display make sense here, as well?
|
|
jessebraham
force-pushed
the
fixes/c-common-traits
branch
from
1a1bfe7 to
211c38b
Compare
| impl core::fmt::Display for Error { | ||
| fn fmt(&self, f: &mut core::fmt::Formatter<'_>) -> core::fmt::Result { | ||
| match self { | ||
| Error::ExceedingFifo => write!(f, "The transmission exceeded the FIFO size"), |
There was a problem hiding this comment.
There are crates that can turn docstrings into Display output (displaydoc or docsplay). Should we try and use them?
There was a problem hiding this comment.
I guess thiserror does support no_std now, but I'm fairly indifferent.
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
jessebraham
force-pushed
the
fixes/c-common-traits
branch
from
211c38b to
3fb4ec0
Compare
Some notes related to the traits mentioned in the corresponding issues:
Clone,Copy,PartialEqandEqare automatically derived byEnumSetTypealready, and therefore not required foruart::UartInterruptfugit::Ratedoes not implementHash, soi2c::master::Configcannot derive itAtomicWakerimplements no traits, thereforei2c::master::Statecannot eitherRegarding the implementation of
Display:i2c::master::ConfigErrorhas no variants, so implementingDisplayis meaningless for it (i.e. what would we actually display?)strum::Displayon this type if requestedDisplaylook like fori2c::master::ConfigDisplaylook like fori2c::master::I2cHappy to make the
Display-related changes, just would like to come to a consensus with regards to how this should look so we can be consistent across drivers.Closes #2776
Closes #2810
Closes #2788