Handle overrides in element group derivation #293
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I have an SVD file with two instances of a peripheral. The second peripheral contains the same registers, but instead of 128 it only has 64. The SVD file uses
derivedFrom
in the second peripheral to inherit these registers but overrides the<dim>
element. To my surprise,svd2rust
generated arrays with the same number of elements for both instances.Well, after following the trail I ended up here and the reason wasn't hard to find.
I saw #283 and the follow up #286, but there's little to no reasoning attached to these PRs.
Looking at the spec here I really don't see a reason why the fields from
dimElementGroup
shouldn't also be overridden.The
derivedFrom
description readsI can't see a statement about the
dimElementGroup
elements somehow being exempt.