Avoid usage of deprecated Indices class

[romanc]

After a brief discussion subsets.Indices were deprecated last week with PR #2282. Since then, many Dace tests emit warnings because of remaining usage of Indices in the offset member functions of subsets.Range.

This PR suggests to adapt Range.from_indices() to add support for a sequence of (symbolic) numbers or strings (as suggested in Mattermost). This allows to remove the remaining usage of subsets.Indices constructors in the DaCe codebase, which gets rid of a bunch of warnings emitted in test or upstream/user code.

Only hickup that I had doing this was the function _add_read_slice() , called from visit_Subscript() of the ProgramVisitor in newast.py . That function would check for subsets to be either ranges or indices. And if subsets were indices, we'd go another way. That code path separation is apparently loosely tied to some other place in the codebase because we'd get errors if we were going the sub-optimal ranges-path with indices. I do now check if ranges are indices and set the flag accordingly. That seems to fix issues in tests.

I've also checked (manually) all other cases where we'd go a different code path in case subsets are indices. There are some and the remaining ones all "upgrade" indices to ranges. They can be removed once we remove the deprecated Indices class.

[romanc]

I've tracked down the last failure to simplify() in DaceProgram._parse(). Before is on the right and after simplify on the left. The first edge on the left assigns v = A[4].

The SDFG in the end translates to

void __program_copies_and_views_test_set_by_view_3_internal(copies_and_views_test_set_by_view_3_state_t*__state, int64_t * __restrict__ A)
{
    int64_t v;

    v = A[4];
    v = (v + 1);
}

which is why the test fails (because the write-back to A is now missing). Not sure at all where this comes from...

[romanc]

Update: I understand now, it's not simplify() to blame because the SDFG on the right already has no write-back to A anymore. The SDFG only writes back to v (which isn't tied to A in any way).

[romanc]

Update: this all comes back to _add_read_slice() which used Indices / Range as an indication of whether to make a view or not. Ranges get a view whereas indices are translated into a scalarized tmp access (as we see in the SDFGs above). With the changes so far, the access A[4] gets scalarized (because it's a one-element range) and thus no view is created and thus the write-back to A is missing.

In the parsed python this boils down to the difference between

# this is a view
v = A[4:5]
...

and

# this is a copy
v = A[4]
...

[tbennun]

Suggested change

from __future__ import annotations

We are already in the future

[tbennun]

Fixed issue. Will merge if tests pass

[tbennun]

cscs-ci run