Fix SccAnnotate when existing acc pragmas declare a copy category more than once

[reuterbal]

PR #389 introduced a regression in ecphys. There we have an ACC statement like this:

!$acc data copyin(var_a, var_b) &
!$acc &    copyin(var_c) create(var_d)

Now, the ACC statements are checked for existing offload directives. For that, get_pragma_parameters is used to extract offload "categories". However, for situations where a key exists more than once, the values are provided as a list, i.e., for the above we obtain

{'copyin': ['var_a, var_b', 'var_c'], 'create': 'var_d'}

Where previously a simple str.split(',') was used to build a list of variables of each category, we need to be careful to accomodate for the above situation where not a simple string constitutes the value. This PR expands the test to include the above case and fixes the transformation accordingly.

[github-actions]

Documentation for this branch can be viewed at https://sites.ecmwf.int/docs/loki/409/index.html

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.02%. Comparing base (2bbe704) to head (7f7337e).
Report is 9 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #409      +/-   ##
==========================================
+ Coverage   95.57%   96.02%   +0.44%     
==========================================
  Files         201      197       -4     
  Lines       39833    38986     -847     
==========================================
- Hits        38071    37435     -636     
+ Misses       1762     1551     -211     

Flag	Coverage Δ
lint_rules	96.39% <ø> (ø)
loki	96.01% <100.00%> (+0.45%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

[reuterbal]

Build appears to be clean, so this is ready for a look. I haven't run ecphys, yet, though.

[mlange05]

Looks sensible. GTG from me.

[mlange05]

[no action] Curious, why would the ordering go off here? Should this not be deterministic?

[reuterbal]

Well spotted! 🦅 - 👁️
I was wondering the same and I suspect it is here:

loki/loki/transformations/single_column/annotate.py

Line 294 in 7f7337e

private_arrays = ', '.join(set(v.name for v in arrays if not v.name_parts[0].lower() in acc_vars))

We could replace this by

 private_arrays = ', '.join(dict.from_keys(v.name for v in arrays if not v.name_parts[0].lower() in acc_vars))

to have a stable sort but unique list. But didn't want to piggy-back this in this hotfix PR

[mlange05]

Ahhh yes. I think I've fixed this in one of my dev branches. Not urgent now, this will happen one way or another, I think.