You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
464: Register spec & traits r=therealprof a=couchand
Part 1 of #463.
- Publishes the register spec zero-sized type and moves all relevant register traits to that struct, which fixes#459 and improves generated documentation.
- Removes the extra type parameter on `Reg`, making the register spec the sole authority on the shape of the register (but not its address).
One thing that's changed since the previous PR, this renames the spec struct so that it won't cause a conflict on NXP, Freescale, and possibly other architectures. I've gone with `register::REGISTER_SPEC` since that seems reasonably clear and I can't think of how it would cause a conflict (but I'm ready to be proven wrong since I've tried several ideas only to be stymied by various architectures' oddball register naming patterns).
I'd prefer the spec to be in the parent module, but I can't come up with a way to do that which guarantees that the generated code will be free from naming conflicts. This seems good enough, plus it maintains the rule that when we make up a name it belongs in the child mod (except for `RegisterBlock`).
There is potential for breaking changes here, though the impact seems pretty minimal. Specifically:
- If users referred to the traits in `mod generic`, their usage would break. Writing code referring to those traits was previously pretty awkward (see #463), and this PR makes such usage much more ergonomic, so it would seem to be a net benefit.
- If users named the full reader/writer incantation the reference would break. It doesn't seem users are likely to name the readers/writers at all, but if they do it seems very likely they would use the type alias.
- If users named the previously `#[docs(hidden)] ` spec struct the reference would break. I don't see why they would have done so.
- If users patched something in to the generated module with the same name as our new register spec, it would break. That case seems highly unlikely.
r? @burrbull
Co-authored-by: Andrew Dona-Couch <hi@andrewcou.ch>
0 commit comments