Move generic.rs contents to other crate

[burrbull]

I don't see sense to built this code in each file that svd2rust generates.

I propose to move it in new crate with will be dependency for pacs.

It should have short name. Maybe (pa or ra as abbreviation of Peripheral Access an Register Access).

I see only advantages, no disadvantages:

• we can simplify svd2rust code, remove some tricks in stm32-rs
• we can use Cargo.toml for optionally enabling features like atomic operations (Support for atomic bitwise operations in MSP430 PAC API #407)
• use "semver" to control that crates have identical API
• avoid potential name conflicts when reexport generic.rs

[burrbull]

cc @therealprof @Disasm @adamgreig

[therealprof]

I can see one disadvantage: We need to keep the generated code and this new crate in lockstep which makes development a tad more complicated. But other than that I agree in principal.

Due to the impact I'm convinced this needs be covered by an RFC, though.

[Disasm]

I agree with @therealprof regarding more complicated development. As an alternative, we may have an option to provide register.rs on demand. For example, in stm32ral such common code exists in repository and is not touched by generator. One can update this file only if generator (svd2rust) version is changed.

[adamgreig]

@Disasm, is having a file that is generated occasionally that much simpler than having a crate that is updated occasionally? We can have the extra crate live in this repository the same as cortex-m-rt-macros for instance, and so the git repository would always be consistent.

[therealprof]

@adamgreig That still adds additional complications on top of the already tedious testing procedure, a lot of changes/improvements need to be tested in the context of a HAL to make sense, e.g. binary size.

Not saying it can't be done or is not worthwhile, just something to consider.

[burrbull]

Unfortunately, I found serious difficulty in implementing the idea. A lot of:

error[E0116]: cannot define inherent `impl` for a type outside of the crate where the type is defined

I apologize for disturbing you.

[burrbull]

We need specialization for this.

[jonas-schievink]

Specialization doesn't cover inherent impls. This does not look implementable by any in-progress language feature.