Parse error results in invalid declaration in driver

[hiker]

LFRic's log_mod contains:

use constants_mod, only : str_long, str_max_filename
...
character( str_long + str_max_filename ), public :: log_scratch_space

This declaration is not understood, and results in a code block in the symbol table:

   61 = {DataSymbol} log_scratch_space_post: DataSymbol<UnknownFortranType('CHARACTER(LEN = str_long + str_max_filename), PUBLIC :: log_scratch_space'), Automatic>
    DEFAULT_VISIBILITY = {Visibility} Visibility.PUBLIC
    Visibility = {EnumMeta: 2} <enum 'Visibility'>
    datatype = {UnknownFortranType} UnknownFortranType('CHARACTER(LEN = str_long + str_max_filename), PUBLIC :: log_scratch_space')
    initial_value = {NoneType} None
    interface = {AutomaticInterface} Automatic
    is_argument = {bool} False
    is_array = {bool} False
    is_automatic = {bool} True
    is_commonblock = {bool} False
    is_constant = {bool} False
    is_import = {bool} False
    is_modulevar = {bool} False
    is_scalar = {bool} False
    is_static = {bool} False
    is_unknown_interface = {bool} False
    is_unresolved = {bool} False
    name = {str} 'log_scratch_space_post'
    shape = {list: 0} []
    visibility = {Visibility} Visibility.PUBLIC
   __len__ = {int} 62

The end result is that the driver creation creates a variable log_scratch_post, which copies the declaration from log_scratch, as shown in the debug output above.

At code creation time, the plain code block is inserted, and instead of declaring log_scratch_post, it will (try to) declare log_scratch again (which is already imported from the original module).

Is it expected that the declaration ends up in a code block (and if so, should I open a ticket in fparser)?

[arporter]

Hi Joerg, just to be clear, when you say "code block", do you mean UnknownFortranType? If so, yes, this is expected. Currently an UnknownFortranType includes the name of the variable being declared. This isn't ideal and there's an issue (somewhere) to tackle this. I think that in this case we would expect the UnknownFortranType. Usually the onus is then on the code encountering the type to decide whether to stop or attempt to manipulate it.

[hiker]

Sorry, yes, UnknownFortranType (I just noticed that it contained the original string and just the wrong word). This issue is not really urgent for the KernelExtraction. It comes from log_mod, so I will support ignoring this module (and ithis then avoids the issue that additional variables used in the declaration need to be extracted :) ).