Correct symbols after derived type enrichment

[mlange05]

Currently sits on top of PR #448 , so needs rebase once that is merged.

This PR aims to make the state of subroutine/modules after enrichment with derived type info to the a priori provision of type info via definitions. The key difference here is that, after type info has been attached to imports and symbol tables, the expression trees need to be rebuild, so that DeferredTypeSymbol.clone() yields Array or Scalar variable symbols.

For this purpose, I've introduced a base class ExpressionTransformer that takes only the basic expression re-build mechanism from SubstituteExpressions and exposes this generically via a static expr_mapper attribute (similar to the ExpressionFinder base class. This defaults to LokiIdentityMapper, which is enough to rebuild expressions.

Along the way to getting this un-muddled in my head, I also got annoyed by derived-type symbols in Import nodes being typed as ProcedureSymbols, so I implemented a mechanically equivalent DerivedTypeSymbol and added a test that uses it to the frontends, to explicitly test the use of type info viadefinitions to create the right symbol types.

Tow other piggy-backed housekeeping changes:

• Bug fix for FP frontend, where we now add the return-type into the symbol-attrs before recursing on the body, so that any use of the return symbol is scoped correctly.
• Split frontend tests into general frontend test and regex tests (the latter is much longer 😮 )
• Cleaned up the imports at the top of subroutine tests

[github-actions]

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

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.28%. Comparing base (c3aaa57) to head (fa42d02).
Report is 9 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #450      +/-   ##
==========================================
+ Coverage   93.24%   93.28%   +0.03%     
==========================================
  Files         220      220              
  Lines       41137    41202      +65     
==========================================
+ Hits        38360    38436      +76     
+ Misses       2777     2766      -11     

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

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]

Many thanks, this misclassification of imported type names was a bit of a sore point...

Implementation looks good to me. Out of curiosity, how are constructor calls represented now? For example, something like

use some_mod, only: type_name

...
type(type_name) :: obj
...
obj = type_name(arg1, arg2)

Is this an inline call with DerivedTypeSymbol('type_name')?

[reuterbal]

Codecov thinks these lines are never executed, so it looks to me like the test isn't quite doing what it's meant to do.
This isn't related to this PR but maybe you can have a quick look if you don't mind?

[mlange05]

Wow, good spot for codecov! These lines were indeed implicitly skipped, as the test was attempting to check ProcedureDeclaration nodes, but was iterating VariableDeclaration, likely as the former had been introduced much later than the test. I've pushed a fix that should rectify that.

[mlange05]

"mumble, grumble, ... the system works(!), ... grumble"

[mlange05]

Yes, the above example will become an InlineCall with a DerivedTypeSymbol as call.function. At some point I tried to fix this, but had to revert this effort. The problem is that in the symbol table of the enclosing function we would have to store a ProcedureType a DerivedType under the same key - or if we don't, risk any arbitrary clone of the call.function symbol changing the type of the symbol according to what is currently stored in the symbol_attrs.