stfc
Reference2ArrayReference should support structure components
The Reference2ArrayRangeTrans transformation replaces a reference to an array with an array reference. For example:
a = b
becomes
a(:) = b(:)
However this transformation raises an exception if we have a reference to an array within a structure i.e.
struct%a = b
@arporter I started looking at #717 as I wanted to fix the "where" limitations next, but realised that for this we need a proper way to decide if a plain reference or structure is an scalar, an array (with implicit (:)) or it cannot be guaranteed. This is more than looking at the type because as in ArrayAssignment2Loop we can also infer what it is by looking at the syntax and knowing that it comes from a valid Fortran statement. And this is important because it means we can convert them to loops more often and provide more parallelism.
I was thinking where this logic should live as it can be complex and I want to reuse it, and I believe the Reference2ArrayReference is the right place (because we end up applying this transformation everytime we have this question as it resolves it in the syntax - after it Arrays are ArrayMixins and scalar are References), the only current problem is the "scalar" vs "cannot be guaranteed" is inconsistent.
But I think we can modify "validate" behaviour to let scalars pass the validation (and the apply unmodified), but guarantee that ALL cases that we cannot guarantee consistently fail the validation. So:
a = 1
struct%b = 1
If they are scalars the validate passes and the apply returns the references unmodified. If they are arrays the validate pass and the apply returns:
a(:) = 1
struct(:)%b = 1 ! or "struct%b(:) = 1" depending of what is an array
If we don't have enough syntactic or type information to guarantee which one it is the validate produces a TransformationError: so other transformations (ArrayAssignment2Loop, ...) can validate during their own validation and fail if necessary or the where produce a CodeBlock. But if the validation passes, we can continue this transformation/where logic knowing that all arrays are now ArrayMixins (which often already assume).
I will try to do this change as part of this issue and then go back to the "where" issues.
