One enum

[burrbull]

r? @therealprof

[therealprof]

Weird, again I see absolutely not change in the generated files for my test SVDs (except for the _{}W-> {}_W change that is). It strikes me odd that some large SVD files are not even exercising the code you're changing...

[therealprof]

bors try

[burrbull]

It just can not be.

[therealprof]

Well, it is... I reverted {}_W line from your PR just so I am able to see trees in the forrest but after that change the diff is completely empty. I'm using the upstream STM32F042x.svd for my tests, BTW. Because then I can actually see the compiled code and sizes...

[burrbull]

Does your SVD contain <enumeratedValues>?
Try https://stm32.agg.io/rs/stm32f0x2.svd.patched

[therealprof]

I can certainly try other SVD files. Two problems here: I cannot test my code base against patched versions and we do not have test cases on the CI based on those, so if only patched SVDs exercise those features we're basically not testing those which is bad...

[bors]

try

Build succeeded

• continuous-integration/travis-ci/push

[burrbull]

I think this is record.

Previous time:

[therealprof]

Not really, CI times vary quite a bit. We had similar "quick" builds e.g. here: https://travis-ci.org/rust-embedded/svd2rust/builds/564713886

[burrbull]

So is here something blocking merge?
Do you want I revert "{}_W" or something else?

[therealprof]

Well, as I said. I can't see any changes with my set-up infrastructure and I'd definitely like to be sure that this is tested, preferably in CI. So either someone can tell me which currently tested SVD file exercises this change or this will need to wait until I switch my tests to use the stm32-rs svd file.

[burrbull]

cc @adamgreig
cc @Disasm

[Disasm]

Well, seems like the svd2rust output is unable to build on stable.

error: enum variants on type aliases are experimental
  --> src/aes/tag_in_flag.rs:75:22
   |
75 |         self.variant(TAG_IN_FLAG_A::CAN_INPUT)
   |                      ^^^^^^^^^^^^^^^^^^^^^^^^

Checked on this repo: https://github.com/riscv-rust/k210-pac

[therealprof]

Oh, have I mentioned that we definitely should have SVD files in CI which exercises all code in a PR. 🙄

Well probably have to revert the variant changes and work on modernising CI a bit so this doesn't happen again.

[Disasm]

Hmm, why VENDOR=OTHER is checked only on nightly?

[burrbull]

@Disasm I forgot to try on stable. I've reverted. Can you try again.

[Disasm]

@burrbull Checked, the error is still here.

[burrbull]

Try again, please. Now it should be fixed.

[Disasm]

Now it builds. On k210-pac it shows 6.3% build time reduction compared to master. Not bad!

[therealprof]

@Disasm Since it seems to be buildable on stable, would you be willing to move RISC-V out of the OTHER category and make it testable on stable in a new PR?

[Disasm]

@therealprof Yep, working on this.

[therealprof]

@burrbull Would you rebase please?

[burrbull]

Done.

[therealprof]

LGTM.

[therealprof]

bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push

[burrbull]

It's funny:
rust-lang/rust#61682

The problem that was blocking compilation on stable will not be in 1.37.