Joerg Henrichs

The locations mentioned in #1920 are also useful here - at this stage the tree is still intact and has precision split into a separate element, which is only then...

As discussed in the telco, root cause is that in Fortran a signed real number is actually a unary-operation on the (positive) real number, and along the way to PSyclone...

> If this uses the reference_access method, this could be the same issue as #2271 I had a look, and I am not sure about the full scope of #2271,...

> > if I add a reference_access method to the symbol table > > I was expecting it to be all implemented in ScopedNode, since Node has the reference_access method...

> Another thought, `ModuleInfo` currently offers caching of the fparser2 parse tree. It might also be good if it offered caching of the PSyIR of that tree? (Although it's the...

A suggestion for a different approach (caused by me trying to kernel extract LFRic with UM physics ... which do not follow LFRic coding style, so in order to avoid...

> I'd be a bit worried that a user would have to make sure that the config file was setup to match the API they are using (unless we allow...

> As an aside, it would be really useful if fparser could serialise its parse tree to file and read it back in again. That way we can cache the...

Interestingly, I could get um-physics+lfric to work when just assuming that any file `XX.f90` contains a module names `XX`. That worked for the LFRic coding style (`XX_mod.f90` contains `XX_mod`), and...

I just realise that there is a bad assumption in #2296 - originally, `ModuleInfo.get_psyir()` would return a FileContainer. That does not make any sense in case of multiple modules in...