Error generating psoc6_pac

[dioguerra]

Hey,

I'm trying to configure and fiddle with Rust for the psoc6 CPU and I seem to have hit some sort of problem.
I downloaded the original psoc6_pac from this git repo: https://github.com/psoc-rs/psoc6-pac and can generate
the modules without problems straight from the repo cargo build --release --features "rt"

although, if I do regenerate modules files by instantiating the generate.sh script it seems that I am hitting a redefinition error

cargo build --release --features "rt"
   Compiling psoc6-pac v0.0.1 (/tmp/psoc6-pac)
error[E0428]: the name `FM_CTL` is defined multiple times
  --> src/flashc/fm_ctl.rs:75:1
   |
3  | pub struct FM_CTL {
   | ----------------- previous definition of the type `FM_CTL` here
...
75 | pub type FM_CTL = crate::Reg<fm_ctl::FM_CTL_SPEC>;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `FM_CTL` redefined here
   |
   = note: `FM_CTL` must be defined only once in the type namespace of this module

warning: lint `const_err` has been removed: converted into hard error, see issue #71800 <https://github.com/rust-lang/rust/issues/71800> for more information
 --> src/lib.rs:3:9
  |
3 | #![deny(const_err)]
  |         ^^^^^^^^^
  |
  = note: `#[warn(renamed_and_removed_lints)]` on by default

warning: lint `private_in_public` has been removed: replaced with another group of lints, see RFC <https://rust-lang.github.io/rfcs/2145-type-privacy.html> for more information
  --> src/lib.rs:12:9
   |
12 | #![deny(private_in_public)]
   |         ^^^^^^^^^^^^^^^^^

error[E0072]: recursive type `flashc::fm_ctl::FM_CTL` has infinite size
 --> src/flashc/fm_ctl.rs:3:1
  |
3 | pub struct FM_CTL {
  | ^^^^^^^^^^^^^^^^^
4 |     #[doc = "0x00 - Flash macro control"]
5 |     pub fm_ctl: FM_CTL,
  |                 ------ recursive without indirection
  |
help: insert some indirection (e.g., a `Box`, `Rc`, or `&`) to break the cycle
  |
5 |     pub fm_ctl: Box<FM_CTL>,
  |                 ++++      +

Some errors have detailed explanations: E0072, E0428.
For more information about an error, try `rustc --explain E0072`.
warning: `psoc6-pac` (lib) generated 2 warnings
error: could not compile `psoc6-pac` (lib) due to 2 previous errors; 2 warnings emitted

Edit: No It does not fix it...
Not exactly sure what the fix here is and which package is causing this (svg2rust or form), but it seems that removing the redefinition and setting the

FM_CTL: crate::Reg<fm_ctl::FM_CTL_SPEC>

on line 3 seems to fix the error.

It appears to me that the redefinition on line 76 appears to be for documentation purposes only? Pointers would be nice.

[dioguerra]

I also tried with a different svd file (from the module I intend to use) and it seems that the same error occurs
(although no relevant diffs are shown between the 2 files): https://www.google.com/search?channel=fs&client=ubuntu-sn&q=github+VSCode_OnethinxPack_Linux%2F

I tried different versions of form and svd2rust and it seems that error persists, so not exactly sure what is going on,,,

[burrbull]

It is just speculation. But I think it is because cluster and register it contains have identical names.
https://github.com/psoc-rs/psoc6-pac/blob/4332a41692514ec9140d1b5de69ee3c60691b43e/svd/psoc63.svd#L5971-L5975
Fast fix is to rename one of them. Other workaround is to use different identifier formats for registers and clusters. See #805 and #794

[thejpster]

I have a newer PAC here, which might give you fewer issues? https://github.com/ferrous-systems/psoc-experiments

[dioguerra]

I have a newer PAC here, which might give you fewer issues? https://github.com/ferrous-systems/psoc-experiments

Actually I managed to go thru your stuff, quite usefull for my examples, didnt try your PAC. I think the problem might come from the SVD file itself. Something that the original author (or you) might have fixed after generating the src code i suppose?

Still, dosen't really take into account automated full build of every dependency if manual changes need to be made...

I'll check it out tho. Thank you @thejpster