[RFC, patch] Extended types in namelists

[Jerry DeLisle]

Hi all,

The attached patch will eventually resolve pr55117.  It provides a way to
identify extended type variable names in namelists that use a parent%child
format, but internally these are represented as parent%extended%child. (Forgive
me if I have my nomenclature inaccurate).

The patch has two parts, front-end and library.  The front-end patch was
provided by Tobias and substitutes a '+' symbol in the namelist variable name
strings so that we can tell if the variable being searched is an extended type.
The library part modifies the search for the variable names to first look for a
match to a non extended type and then if not found, looks for an extended type
match.

I have been running Tobias front-end patch for months without any failures so
that tells me we don't have too many code examples to exercise this, none in the
testsuite for sure.

The patch is preliminary in that I have tested with some test cases I have.  I
am not convinced that a recursive approach is not needed depending on how the
variable names get nested. With that said, I would appreciate some examples that
are not handled yet by the patch. (I hate it when I ask for it because usually I
will then get a bundle of examples, ha ha)

Testing and comments much appreciated.

Regards,

Jerry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: extended_type_nml.diff
Type: text/x-patch
Size: 2486 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20140323/cf536308/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: deep.f90
Type: text/x-fortran
Size: 1212 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20140323/cf536308/attachment-0001.bin>
-------------- next part --------------
&TEST_NML
 TKE%X=  3.14    ,
 TKE%STRING="kf7rcc",
 ANSWER=          42,
 /

***** replace the above chunk with the following for no error*******
&TEST_NML
 TKE%TK_T%X=  3.14    ,
 TKE%STRING="kf7rcc54",
 ANSWER=          42,
 /
****************************
type tk_t
   real :: x
end type tk_t

type, extends(tk_t) :: tke_t
   character(8) :: string
end type tke_t

type, extends(tke_t) :: deep
  integer :: int1
  real :: y
  character(10) :: the_name
end type deep

type(tke_t) :: tke
type(deep) :: trouble

integer :: answer
namelist /test_NML/ tke, answer, trouble

Note to self:

To fix this bug we need to modify the search algorythm in find_nml_node

Consider searching for matching first name and matching last name
Create a test case with multiple extended/nested types
Tobias patch is applied

var_name = tke%x  << We have this
t.var_name = tke
t.next.var_name = tke%tk_t
t.next.next.var_name = tke%tk_t%x    <<  The one we are looking for
t.next.next.next.var_name = tke%string
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tc55117-2.f90
Type: text/x-fortran
Size: 899 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20140323/cf536308/attachment-0002.bin>