(Towards #2905) mv lfric symbol creation - #3499
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #3499 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 397 397
Lines 55790 55770 -20
=========================================
- Hits 55790 55770 -20 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
…one into 2905_mv_lfric_symbol_creation
|
A relatively simple PR that modernises some of the PSy-layer generation. |
LonelyCat124
left a comment
There was a problem hiding this comment.
Hi @arporter I think I mostly understand this, have a couple of questions and a couple of small fixes requested, and one I'm not 100% on so I'd like to rerun ITs again after just in case.
| f"integer(kind=i_def), pointer :: {dmap}(:,:) " | ||
| f"=> null()")) | ||
| self.symtab.add(dmap_sym, tag=dmap) | ||
| intrinsic_type = LFRicTypes("LFRicIntegerScalarDataType")() |
There was a problem hiding this comment.
Certainly not one for this PR, but LFRicTypes being dependent on strings feels a bit messy somehow though I think it would require some significant rewriting and object-orientation to do much to.
There was a problem hiding this comment.
Yes, LFRicTypes is a bit of an issue (e.g. #2659).
| intrinsic_type, | ||
| [ArrayType.Extent.DEFERRED, ArrayType.Extent.DEFERRED])) | ||
| dmap_sym = self.symtab.find_or_create_tag( | ||
| dmap, symbol_type=DataSymbol, datatype=dtype) |
There was a problem hiding this comment.
Small thing - if we process code like this through the Frontend:
program x
integer, pointer, dimension(:, :) :: a => null()
end program x
then the symbol we come across has an initial value set:
a: DataSymbol<UnsupportedFortranType('INTEGER, POINTER, DIMENSION(:, :) :: a => null()'), Unknown, initial_value=IntrinsicCall[name='NULL']>
Could you add the initial value into this find_or_create_tag to match? If this causes issues though then we probably don't have to.
There was a problem hiding this comment.
I started doing this (initial_value = IntrinsicCall.create(Intrinsic.NULL)) but then realised that will create a standard assignment rather than a pointer assignment (#2577). Therefore, I don't think we can do it currently but I'll add a TODO. I've also added partial_datatype to the other sorts of dofmap that this method creates since I'm here.
There was a problem hiding this comment.
See comment on Teams, I'd still like this to happen
There was a problem hiding this comment.
Done now - no issues so far.
There was a problem hiding this comment.
Can you still add the TODO so if/when we have support for pointer assignments in declarations we can easily find this code to update it appropriately?
| self, | ||
| loop: Loop, | ||
| test_all_variables: bool = False, | ||
| signatures_to_ignore: Optional[Signature] = None) -> bool: |
There was a problem hiding this comment.
I did a bit of looking at this, and its another thing we'll need to update post-3.9, Optional is a bit of a misnomer, which means "can be None" and not "optional". As of 3.10 we should use Signature | None for typehints like this, I added a comment to #3416
|
Thanks @LonelyCat124, ready for another look now (CI permitting). |
LonelyCat124
left a comment
There was a problem hiding this comment.
I've left a couple of things still to be resolved from last time as I think they are both possible and would improve the code.
| intrinsic_type, | ||
| [ArrayType.Extent.DEFERRED, ArrayType.Extent.DEFERRED])) | ||
| dmap_sym = self.symtab.find_or_create_tag( | ||
| dmap, symbol_type=DataSymbol, datatype=dtype) |
There was a problem hiding this comment.
See comment on Teams, I'd still like this to happen
|
Took me a while to get back to this but should be ready for another look now. |
|
Coverage cleaned up. I've set the ITs going again. Ready for another look @LonelyCat124 :-) |
LonelyCat124
left a comment
There was a problem hiding this comment.
@arporter One more TODO I'd like adding and then we're good to merge (not sure if I can just add it when I update the changelog or whether I have to pass it back to you?) assuming ITs are green.
Move the Symbol creation into the LFRicInvoke constructor. This then affects some tests that were having to pre-populate a table.