Should `sequential_indexes` support descend order when generating `dimElement`?

[duskmoon314]

Brief Intro

When generating field with dim, now we only support numeric dimIndex in the ascent order. For example, 0,1,2,3. Should we support the descent order, like 3,2,1,0?

A Real Problem

Today I came across a register description like this:

field	bitRange
f1	[20:20]
f2	[19:19]
f3	[18:18]

So I think maybe the SVD file could be like this:

<register>
  ...
  <fields>
    <field>
      <dim>3</dim>
      <dimIncrement>1</dimIncrement>
      <dimIndex>3,2,1</dimIndex>
      <name>field_name%s</name>
      <bitRange>[18:18]</bitRange>
    </field>
  </fields>
</register>

But currently, svd2rust will treat this as an error:

// src/generate/register.rs    fn fields    line 404-410

let sequential_indexes = dim_index
    .iter()
    .map(|element| element.parse::<u32>())
    .eq((first..de.dim + first).map(Ok));
if !sequential_indexes {
    return Err(anyhow!("unsupported array indexes in {}", f.name));
}

Note

1. This seems useful, and it seems spec doesn't forbid this way. But is it common or rare?
2. Haven't considered register, cluster, and other elements that could have dim. Do they need this too? Or they are already supported? I think peripheral support this usage because in #592, %s is simply replaced by index and no check of its order.

[burrbull]

As since 0.24.1 field writers are generic over field offset I don't see big issue to support arrays with non-sequential indices.

[Emilgardis]

svdconv doesn't complain either about reversed order, nor non-sequential ordering