(Towards #3367) def use chain update for assignments.

[LonelyCat124]

I now have this at a stage that it can handle multiple inputs and behave somewhat sensibly. I haven't yet finished, as it currently requires inputs to be members of the same parent, but I think we want them to simply share an ancestor statement.

There are a few remaining FIXMEs for things that I don't know what they were preventing previously and didn't cause any previous test failures, but presumably were things I thought mattered previously (though I did also just find some code that didn't matter so...). I need to do more testing for multi-inputs, but I think I might do that through Statement.next_accesses or some similar option.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (3e99eac) to head (96fb9fb).

Additional details and impacted files

@@            Coverage Diff             @@
##            master     #3399    +/-   ##
==========================================
  Coverage   100.00%   100.00%            
==========================================
  Files          393       393            
  Lines        54918     55024   +106     
==========================================
+ Hits         54918     55024   +106     

☔ 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.

[LonelyCat124]

I resolved the last of the FIXMEs. I need to do some tests with loops and things where I check I get the same results for Assignment.next_accesses/previous_accesses that I would calling it for all of the References individually.

[LonelyCat124]

Having an issue with this code:

subroutine test
    integer :: a, b
    logical :: x
    a = b
    if (x) then
        a = b + a
    else
        b = a * b
    end if
    a = 1
    b = 1
    end subroutine test

For the single reference case, it doesn't find b=1 for a forward check for the original b Reference, and I can't quite work out the issue. There seems to be something with the b = a * b accesses seemingly not belonging to a control flow node, so the DUCs are assuming it must always happens and ends the chain, which is incorrect. I'm trying to sort this out but its a bit confused (as far as I can work out it also doesn't happen for the a access which is super weird.

[LonelyCat124]

Fixed the previous case, but immediately created another non-equivalent case where I do

a = b
b = 2
...

as the def use chains output for b when the full statement is input goes past the b = 2 statement incorrectly.

[LonelyCat124]

I fixed the above case going forwards, so things are looking like they're getting there. I suspect there will be issues going backwards that I'll need to match as well.

[LonelyCat124]

NEMO ITs failing in the async runs. I need to manually look at whats happening - I think barriers are now being missed, which if there's not a simple solution to it might need a full DUC rewrite 😢

[LonelyCat124]

@arporter Ready for another look.

[arporter]

Thanks very much Aidan. I just need clarification on one comment and then this is good to go. I'll re-check the ITs as there's been quite a lot of code under the bridge since I last did it.

[arporter]

Unfortunately the ITs were not happy - please could you take a look?

[LonelyCat124]

I had a quick look and I think the fixes on your branch will resolve most of them. The LFRic extraction ones I'm hoping will be fixed but there were a lot of build system errors there.

[LonelyCat124]

@arporter Fixed up the issues, ready for another look.

[arporter]

All looks good now, thanks Aidan. I also see the ITs are all green so this is ready to go.