#1312 ScalarArray code generation

[mo-alistairp]

Adding code generation for ScalarArrays (towards #1312 ). The metadata support was added in #2173.

[arporter]

This isn't true I'm afraid - they will need to be added to a data region. However, you could leave this as a TODO as I'm not sure we're ever going to need data regions.

[mo-alistairp]

Thanks for that - it's currently a very rough draft so some of the comments are currently just borrowed from other functions. But, I will definitely note that down!

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.95%. Comparing base (bc9b4db) to head (d2a7ef9).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3101      +/-   ##
==========================================
- Coverage   99.95%   99.95%   -0.01%     
==========================================
  Files         377      378       +1     
  Lines       53667    53766      +99     
==========================================
+ Hits        53645    53743      +98     
- Misses         22       23       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mo-alistairp]

This still isn't working as intended, but is getting closer to correct. As an example, the code gen is now adding the scalar arrays to the generated code, alongside the arrays containing their dimensions. However, it is not adding these dimensions to the generated code (e.g., no dimensions(...) mention). It is also assigning the field as intent(in) right now, which it shouldn't do either.

Furthermore, the stub_gen test is failing because we are currently adding the dimensions array to the psyir layer as an ArgumentInteraface which isn't there as an argument at the call. Need to find a way around this. I'm wondering if we need a dimensions array at all but I'll have to investigate that further.

[mo-alistairp]

I'm having a little trouble getting testkern_scalar_array_mod via lfric_scalar_codegen_test to compile. Currently, it's erroring with
Error: Symbol 'gh_scalar_array' at (1) has no IMPLICIT type; did you mean 'gh_scalar'?

Still trying to find what needs adding to fix this.

[mo-alistairp]

This is now working and passing the tests with and without compilation. I'm not sure why my commits have started coming up as unverified, but I'll try and fix that.

I'll warn you that I've had to do a slightly strange fix to correct the ordering of the declarations in code generation. As mentioned on Monday, there isn't a way of changing the order of declarations - they appear in the order that they are added to the symbol table. Since the ScalarArray is an argument it was always being added before the dimensions array, and this was causing compile time errors as the dimensions array is being used in the ScalarArray declaration. My fix for this is simply finding the ScalarArray in the symbol table and replacing it with itself, so that it is being added after the dimensions array. Hopefully you're happy with this

This should now be ready for review again

[mo-alistairp]

I'm not sure why CodeCov has only just decided that this was a problem. I've looked at the line it's complaining about (line 773 in arg_ordering.py) and I don't see an easy way of avoiding this problem without splitting scalar_args out of the scalar function. The test for this is checking whether the argument isn't is_scalar or is_scalar_array, which I can't think of a way of doing independently without splitting the function into two. I don't think we want to do this from a design perspective.

I still think that this is ready for review, and would be interested if you have any thoughts about this