#3041 made sure that we don't process Function Calls and Type Constructors as ArrayReferences but @arporter pointed out that Character Substrings are still ArrayReferences. I did check that this does not mean that we assume the type of the symbol associated, they are UnsupportedType.
My initial though is that they are fine as ArrayReferences (as they support indices or ranges to a subelement of the datatype). Maybe a better name would be IndexedReference, but I don't now if it is worthwile to change the name.
program string_test
use other
! Character substrings
character(8) :: a
character(len=8) :: b
character*8 :: c
! Character array
character, dimension(8) :: d
character :: e(8)
! Both
character*8 :: f(8)
a = "a"
b(:) = "b"
c(2:3) = "c"
d(:) = "d"
write(*,*) a(2:4), b(2:4), c(2:4), d(2:4), e(2:4), f(2:4), other_a(2:4)
! This line is valid
write(*,*) lbound(d), lbound(e), lbound(f)
! This line is invalid and will not compile
write(*,*) lbound(a), lbound(b), lbound(c)
! This line we don't know unless we resolve the imports
write(*,*) lbound(other_a)
end program
But as seen by the last 2 statements these cannot be passed to intrinsics that expect arrays. This won't be in the parsed code but we must make sure that we don't generate such expressions. This could be a problem in some transformantions because we sometimes do a "ininstance(ArrayMixin)" to check if a symbol is an array to validate a transformation. These are wrong and instead we need to do the proper isinstance ref.symbol.is_array or ref.datatype.is_array (depending what we want).
We know that MEDUSA #869 and NEMO have had problems offloading strings that may be related. In theory these should be supported, so we need to test to check that arrays of characters and character substrings (of fixed or variable length) are supported or not.
#3098 and #3054 are also be related.
It also means that ArrayReferences to ScalarType are valid. This is not necessarely wrong, but may look inconsistent.
#3041 made sure that we don't process Function Calls and Type Constructors as ArrayReferences but @arporter pointed out that Character Substrings are still ArrayReferences. I did check that this does not mean that we assume the type of the symbol associated, they are UnsupportedType.
My initial though is that they are fine as ArrayReferences (as they support indices or ranges to a subelement of the datatype). Maybe a better name would be
IndexedReference, but I don't now if it is worthwile to change the name.But as seen by the last 2 statements these cannot be passed to intrinsics that expect arrays. This won't be in the parsed code but we must make sure that we don't generate such expressions. This could be a problem in some transformantions because we sometimes do a "ininstance(ArrayMixin)" to check if a symbol is an array to validate a transformation. These are wrong and instead we need to do the proper isinstance ref.symbol.is_array or ref.datatype.is_array (depending what we want).
We know that MEDUSA #869 and NEMO have had problems offloading strings that may be related. In theory these should be supported, so we need to test to check that arrays of characters and character substrings (of fixed or variable length) are supported or not.
#3098 and #3054 are also be related.
It also means that ArrayReferences to ScalarType are valid. This is not necessarely wrong, but may look inconsistent.