Andy Porter

Now that you say this, I remember hitting it too (but had forgotten). I think the LFRic compiler settings might be such that importing something but never using it will...

I think I meant that if we import *all* possible precision symbols every time, then some might not be used. However, as discussed at the telco today, it seems unlikely...

If I just run PSyclone on lfric_xios_setup_mod.x90 then the generated PSy layer does have: ``` MODULE lfric_xios_setup_mod_psy USE constants_mod, ONLY: r_def, i_def USE field_mod, ONLY: field_type, field_proxy_type IMPLICIT NONE CONTAINS...

If I apply the 'standard' `global.py` used by the MO then the generated PSy layer does still have the required USE statement.

Ah, OK. I was just testing with lfric_core (which is where the file lives) @r50758. I've just tried with 'everything-everywhere-all-at-once' and that looked OK too. (With latest master of PSyclone.)...

Yes, the `clean` target always hangs for me too - the `rm` that it does is missing a `-f` and some of the files are protected.

As implemented, LFRicTypes is a singleton - when its constructor is called the first time it populates a dict and then those values are used for subsequent calls. If I...

Note that it is only the `_create_precision_from_const_module()` that creates new symbols and thus needs access to a table.

Another part of the problem is that LFRic types creates everything, all in one go, while in general, we only create/add Symbols to a table as they are actually required....

Since the types are inextricably linked to the precision symbols that they use, I've moved the required LFRicTypes functionality into the LFRicSymbolTable class instead. This has removed some duplication (of...