VariableAccessInfo can have kind parameters as `READ` instead of `TYPE_INFO`

[LonelyCat124]

In code like

a = REAL(b / c , wp)
c = 1.0_wp

the wp in the REAL intrinsic shows up as a READ, wheras it should be a TYPE_INFO. From a conceptual perspective, the kind parameter passed to these intrinsics has to be a constant, so is known at compile time and thus not an actual READ at runtime.

Not sure how easy this is to fix, so #2967 will have to workaround this problem for now.

[arporter]

The key thing is that the KIND expression is constant so, as you say, it should be TYPE_INFO:

Unfortunately, we only have a single class for IntrinsicCall so we'll have to add an additional branch in its reference_accesses method.

[LonelyCat124]

The other option would be to define a _reference_access lamda or method for each of the intrinsic types and have the reference_accesses call use that, but thats a lot of loc to setup for relatively few variations.

[arporter]

Yes. I think before I went on leave I was already working on just such a change for something else (I can't currently remember what). We may possibly be getting to a stage where we'd be better having separate classes for each of the intrinsics but there are an awful lot of them.

[arporter]

I've just started looking at this and it's not going to be very easy because, in this particular case, kind is an optional argument. We probably need to wait for Martin's #3607 to help us out here.

[sergisiso]

I think these are separate problems:

1. We need to distinguish compile-time-reads (this can happen in a custom function as well):
   a = my_function(b / c , wp)

2. We need Intrinsic argument and return types. I really think that populating a table, with lamdas when the type is not direct and follows some logic is a much better approach that subclasses or if conditions in the method.