(Closes #3087) Handle expressions in the kind attribute of a declaration

[LonelyCat124]

First implementation to handle kinds like kind=2*wp. Not sure if I've missed anything as I'm not super knowledgable about what kinds can be - maybe there's some missing error checking or similar.

Still have a few failing tests to address.

[codecov]

Codecov Report

❌ Patch coverage is 99.55357% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 99.90%. Comparing base (4b61ece) to head (9edd3e8).
⚠️ Report is 37 commits behind head on master.

Files with missing lines	Patch %	Lines
src/psyclone/lfric.py	75.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3110      +/-   ##
==========================================
- Coverage   99.90%   99.90%   -0.01%     
==========================================
  Files         376      376              
  Lines       52816    52887      +71     
==========================================
+ Hits        52766    52835      +69     
- Misses         50       52       +2     

☔ View full report in Codecov by Sentry.
📢 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]

@sergisiso This is ready for a first look.

There is a "logging" message commented out in the old code at backend/fortran.py::342. It appears to not make much sense/not be applied correctly - it would happen for any datatype with a precision specified that isn't a double precision right now - I suspect its meant to handle if precision is specified for non-int/real/char/etc. types? But i'm not sure. I'm in favour of just deleting the message entirely.

[LonelyCat124]

I fixed up the functionality now I think, I need to have a look through the docstrings of the primary changes to check I didn't break anything.

[LonelyCat124]

I'm not sure if this solves something to do with #2659?

[LonelyCat124]

@sergisiso I think this is ready for a first look now, am hoping I didn't miss anything w.r.t docstrings. We can try to update some more to use type hints if you'd like, but since this is already quite large I didn't do anything with that yet (especially as I think I may hit more circular dependency issues)

[LonelyCat124]

Running integration tests to see if #2659 is still an issue there...

[sergisiso]

@LonelyCat124 There is nothing new other than a couple of pylint suggestions, the rest are just the continuation of previous conversations that I brought down here as it was hard to keep track of them having to expand the history.

After this, can you bring it to master and launch the integration tests, as I expect these would be the last comments.

[LonelyCat124]

@sergisiso updated comments for review, going to set integration going and see how it does.

Edit: Hmm I broke lots of things with coverage and docs. I'll keep looking.

[LonelyCat124]

The integration tests were green though, I'll see what i've broken next.

Edit: doctest was link checking failing, can see if thats fixed when i recommit.

[LonelyCat124]

I removed some code that I believe is dead (at least there was no way I could reach it in tests), I think we should rerun integration again to be sure before merging.

[LonelyCat124]

@sergisiso I think this is ready for another look - the only missing coverage is the LFRic code that is untested on master I think.

[sergisiso]

@LonelyCat124 Unfortunately the very last merged PR also touched declarations and has conflicts, can resolve these and launch the integration once again please.

[LonelyCat124]

@sergisiso Ready for review now - I'll set integration running.

[sergisiso]

@LonelyCat124 This is ready to merge, there is a new indirect coverage miss (apart from the lfric one). I was going to propose a solution but its not very nice and I think we should fix the underlaying problem that I explained in #3169, so I defer the fix to that separate issue.