[PATCH] PR fortran/91714 -- Mangled type-spec

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH] PR fortran/91714 -- Mangled type-spec

Steve Kargl
The attached patch issues errors for a few mangled type-specs.
It has been regression tested on x86_64-*-freebsd.  OK to commit?

2019-09-28  Steven G. Kargl  <[hidden email]>

        PR fortran/91714
        * decl.c (gfc_match_decl_type_spec):  Issue errors for a few
        mangled types.

2019-09-28  Steven G. Kargl  <[hidden email]>

        PR fortran/91714
        * gfortran.dg/dec_type_print_3.f90: Update dg-error regex.
        * gfortran.dg/pr91714.f90: New test.

A daunting task awaits a brave soul as gfc_match_decl_type_spec
is a minefield for bugs.  This is dues to the fact the the functions
has grown by adding kludge upon kludge upon kludge.  The first
thing to fix is the broken parsing that follows from the
matching of 'type('.

--
Steve

pr91714.diff (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] PR fortran/91714 -- Mangled type-spec

Steve Kargl
On Fri, Oct 11, 2019 at 05:57:04PM +0300, Janne Blomqvist wrote:

> On Sat, Sep 28, 2019 at 10:16 PM Steve Kargl
> <[hidden email]> wrote:
> >
> > The attached patch issues errors for a few mangled type-specs.
> > It has been regression tested on x86_64-*-freebsd.  OK to commit?
> >
> > 2019-09-28  Steven G. Kargl  <[hidden email]>
> >
> >         PR fortran/91714
> >         * decl.c (gfc_match_decl_type_spec):  Issue errors for a few
> >         mangled types.
> >
> > 2019-09-28  Steven G. Kargl  <[hidden email]>
> >
> >         PR fortran/91714
> >         * gfortran.dg/dec_type_print_3.f90: Update dg-error regex.
> >         * gfortran.dg/pr91714.f90: New test.
> >
> > A daunting task awaits a brave soul as gfc_match_decl_type_spec
> > is a minefield for bugs.  This is dues to the fact the the functions
> > has grown by adding kludge upon kludge upon kludge.  The first
> > thing to fix is the broken parsing that follows from the
> > matching of 'type('.
> >
> > --
> > Steve
>
> Ok.
>

This was committed as

r276270 | kargl | 2019-09-29 09:19:58 -0700 (Sun, 29 Sep 2019) | 12 lines

Again, I was getting a backlog of patches, and committed this
as somewhat obvious.

I will repeat that gfc_match_decl_type_spec has become a difficult
nightmare to work through.  The complication comes from the new
TYPE(INTRINSIC-TYPE-SPEC) feature of either F2008 or F2018.  In
developing this patch, I found that something like

   type(character(len=1)

is accepted as valid, but it is missing the closing ')'.  I cannot
find why the closing ')' in character is used twice!

A long range project would be to split the declaration matching into
gfc_match_type_decl_stmt and gfc_match_intrinsic_type_decl.  Then, we
can refactor gfc_match_decl_type_spec as

gfc_match_decl_type_spec
   gfc_match_type_decl_stmt
   gfc_match_intrinsic_type_decl
   <match nonstandard type, e.g., BYTE>

There are complication because TYPE is overloaded via TYPE(*)
TYPE(derive-type), and a nonstandard TYPE for IO.

--
Steve