(Closes #2721) Add ArrayConstructor to PSyIR

[mn416]

I noticed that reference_accesses() is very conservative on array constructors, e.g. [x, y] leads to both x and y being reported as read/write. This is because array constructors are treated as CodeBlocks and not converted to PSyIR.

This PR adds initial support for array constructors to PSyIR via a new ArrayConstructor node class. Currently, it only supports the most simple form of array constructor

• [<expr>, <expr>, ..., <expr>]

not

• [<type-spec> :: <expr>, <expr>, ..., <expr>] (type spec), or
• [(<expr>, <name> = <expr>, <expr>)] (implied do)

which are still translated to CodeBlock, as before. I'm happy to add support for type specs and/or implied do, but I was wondering if there is any hunger for this PR before spending any more time on it.

I believe this PR addresses #2721.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (d4d4cbc) to head (fc24bca).

Additional details and impacted files

@@            Coverage Diff             @@
##            master     #3458    +/-   ##
==========================================
  Coverage   100.00%   100.00%            
==========================================
  Files          393       395     +2     
  Lines        55067     55199   +132     
==========================================
+ Hits         55067     55199   +132     

☔ View full report in Codecov by Harness.
📢 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.

[arporter]

Thanks @mn416, I think this will be useful - we hit some limitations to do with this sometimes. Does your implementation support the old (/x, y, z/) syntax too?

[mn416]

Hi @arporter, yes the old and new brackets are both supported. They are parsed to almost identical abstract syntax by fparser.

[LonelyCat124]

I know we do hit some implied do in some codes, but I'm not sure we have a reason to need them to not be codeblocks unless we have issues with them so I think that can be skipped for now?

[mn416]

I added support for type specs in the mn416-array-ctr-type-spec branch but I'm slightly less confident in it. I'm therefore inclined to agree with @LonelyCat124 that we may benefit from an incremental approach here, i.e. handle basic array constructors in this PR and add support for type specs and implied do later. An incremental approach should also simplify reviewing (several simple PRs versus one big one).

[arporter]

Absolutely, I'm all in favour of simple PRs 😀

[LonelyCat124]

Happy to review this then.

[LonelyCat124]

@mn416 Have left some initial comments, mostly codestyle related - I didn't go through the tests yet, I'll do that on the next pass through.

[mn416]

Thanks @LonelyCat124. I've addressed all your comments for now and I think it's ready for another pass.

[LonelyCat124]

Hi @mn416 - almost there now - one additional comment I'd liked to be added re: the unknown array size. I'll set any ITs running in the meantime.

[mn416]

Thanks @LonelyCat124. I've added the comment.

[LonelyCat124]

ITs all green, I'll proceed to merge.