svd2rust: update to v0.35.0

[tones111]

This is an effort to bridge the gap between #155 and #157.

[tones111]

hmm. The example built ok locally after updating the dependency to use the path. How do I teach the CI how to do that?

Or maybe the trick is to commit the change with the line un-commented, and then re-comment it on a followup commit.

[stappersg]

hmm. The example built ok locally after updating the dependency to use the path. How do I teach the CI how to do that?

Or maybe the trick is to commit the change with the line un-commented, and then re-comment it on a followup commit.

Other idea: Just "svd2rust: update to v0.35.0" in this merge request and the ATmega328P changes in later merge request.

Plus accepting that github CI is an aid and not a goal. I mean: We want to move forward, even stumbling forward. github CI should never block that.

[LuigiPiucco]

CI is failing because the published version of avr-device still has the uppercase identifiers, but you lowercased them in the example (it is a separate crate before #157, so it doesn't sync with your local changes unless you use a path dependency). I think you'll have to update the example only after publishing a new version to avoid the path dependency, if you want that.

[tones111]

The duplication here feels pretty dirty, but maybe there's a better way for the jobs to depend on a separate job that builds the cache.

[Rahix]

For reference, I'm still in preference to holding off on this if at all possible, see #157 (comment).

If we do have to go ahead with the update, we'll need to do another change analysis/documentation like in #155.

[tones111]

I don't understand why we would lump this into #157 if we can break it out separately. By working this here we can handle impacts related to the version change in isolation from the complexity of moving toward the build.rs solution. I'm concerned the level of complexity is too high there (see my comments in that thread about the atdf2svd version regression, missing SPI_MASTER enumeral, and commits not building).

I think it's preferable to land this more concentrated effort first since it needs to be done anyway. If we're taking svd2rust as a dependency then it needs to be kept updated. This improves consistency with the other PACs using this tooling and forking would expend a lot of additional resources.

Landing this upstream makes verification of #157 easier because the resulting diff of the output becomes much smaller.