[Bug fortran/106035] New: F2018 allows an IMPORT statement within the BLOCK construct.

[Bug fortran/106035] New: F2018 allows an IMPORT statement within the BLOCK construct.

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035

            Bug ID: 106035
           Summary: F2018 allows an IMPORT statement within the BLOCK
                    construct.
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

% cat a.f90
program bug
   implicit none
   integer i
   i = 42
   block
      import none  ! <-- This is valid Fortran 2018
      integer j
      j = 12
      print *, j
   end block
   print *, i
end program bug

% gfortran -c a.f90
a.f90:6:13:

    6 |       import none
      |             1
Error: IMPORT statement at (1) only permitted in an INTERFACE body

[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035

--- Comment #1 from kargl at gcc dot gnu.org ---
Created attachment 53187
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53187&action=edit
implementation of feature; no testcases

The attach patch has had some minimal testing while it was under development. 
For those test, the patch and gfortran appeared to do the right things.

[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #0)
> % cat a.f90
> program bug
>    implicit none
>    integer i
>    i = 42
>    block
>       import none  ! <-- This is valid Fortran 2018

Note, there is a comma missing after import.  So this isn't valid.
One finds these things while implementing a patch.  The patch
includes a description of all constraints in F2018, but I did not
implement them all.  For example, this is invalid (assuming i and
j are available via host association)

interface
   subroutine foo
      import, only : i
      import
   end subroutine foo
end interface

as is

interface
   subroutine foo
      import, only : i
      import :: j
   end subroutine foo
end interface

To do this correctly, gfortran likely needs IMPORT_NONE, IMPORT_ONLY, and
IMPORT_ALL enumerators and then gfc_current_ns->has_import_set would be
set according to one of these instead of using just 0 and 1 for a namespace.

[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #53187|0                           |1
        is obsolete|                            |

--- Comment #3 from kargl at gcc dot gnu.org ---
Created attachment 55242
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55242&action=edit
New diff

New diff with changes to gfortran.h

[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Boyce at engineer dot com

--- Comment #4 from kargl at gcc dot gnu.org ---
*** Bug 108650 has been marked as a duplicate of this bug. ***

[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.

[jdelia@santafe-conicet.gov.ar]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035

Jorge D'Elia <jdelia@santafe-conicet.gov.ar> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jdelia@santafe-conicet.gov.
                   |                            |ar

--- Comment #5 from Jorge D'Elia <jdelia@santafe-conicet.gov.ar> ---
Hi,

The access restriction is a reason of the use IMPORT statements in the
projects, since it is a very convenient and nifty way to detect any name
collision between local entities and host-associated entities, and well as, in
BLOCK statements, for the same purpose. However, with the test:

$ cat import1.f90
module m_modulo
implicit none (type, external)
contains
  subroutine ss (ii)
    import, all
    implicit none (type, external)
    integer, intent (in) :: ii
    associate (i_loc => ii)
    end associate
  end subroutine ss
end module m_modulo

compiled with, (i)

$ gfortran --version
GNU Fortran (GCC) 12.3.1 20230508 (Red Hat 12.3.1-1)
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gfortran -march=native -mtune=native -m64 -fall-intrinsics -fcheck=all
-fimplicit-none -fmax-errors=4 -fno-finite-math-only -fPIC -pthread -std=f2018
-Wall -Waliasing -Warray-temporaries -Wcharacter-truncation -Werror -Wextra
-Wimplicit-interface -Wimplicit-procedure -Wintrinsic-shadow -Wline-truncation
-Wrealloc-lhs-all -Wsurprising -Wtabs -Wunused-parameter -flto -O2 -o
import1.exe import1.f90

import1.f90:5:11:

5 | import, all
   |             1
Error: IMPORT statement at (1) only permitted in an INTERFACE body
f951: all warnings being treated as errors

and next compiled with (ii):

$ nagfor ../import1.f90 -O3
rm: cannot remove '*.original': No such file or directory
NAG Fortran Compiler Release 7.1(Hanzomon) Build 7115
Error: ../import1.f90, line 2: Syntax error
detected at NONE@(
Error: ../import1.f90, line 5: The IMPORT statement is only allowed in an
INTERFACE body
detected at IMPORT@,
Error: ../import1.f90, line 5: Syntax error
detected at IMPORT@,
Error: ../import1.f90, line 6: Syntax error
detected at NONE@(
[NAG Fortran Compiler pass 1 error termination, 4 errors]


Thus, the errors generated by gfortran and nagfor are consistent with the F2003
constraint: C1210 (R1209) "The IMPORT statement is allowed only in an
interface-body".

However, the use of IMPORT in the previus test is new in F2018, which neither
gfortran nor NAG Fortran support, that is: "The IMPORT statement can appear in
a contained subprogram or BLOCK construct, and can restrict access via host
association; diagnosis of violation of the IMPORT restrictions is required". 

Thus, this example should be valid F2018 but not F2008 or earlier.

For instance, one can have a unit testing framework that relies extensively on
BLOCK constructs, and having the guarantee that any potential conflict (between
a local block entity and an entity of the host procedure) will be flagged by
the compiler (when using an IMPORT statement in each block construct) sould be
a godsend.

[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035

--- Comment #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Fri, Jun 02, 2023 at 05:51:17PM +0000, jdelia@santafe-conicet.gov.ar wrote:
> 
> --- Comment #5 from Jorge D'Elia <jdelia@santafe-conicet.gov.ar> ---
> 
> The access restriction is a reason of the use IMPORT statements in the
> projects, since it is a very convenient and nifty way to detect any name
> collision between local entities and host-associated entities, and well as, in
> BLOCK statements, for the same purpose.

Jorge, I agree with you 100% on the usefulness of IMPORT.

The 2nd patch I attached to this PR is almost complete.
That is, 'import', 'import, none', and 'import, all'
work as defined in F2018.

Unfortunately, 'import, only :: a, b, etc' does not work
and I haven't had time to work out the details.  My first
thought is to create a list of allowed use-associated symbols.
The list would be added to the current namespace after
verifying the symbols are in a parent namespace, but that's
as far as I've gotten.

[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.

[kargls at comcast dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035

--- Comment #7 from kargls at comcast dot net ---
Bummer.  Seems I lost my WIP on this bug.

'import, none' would be handy for block host association in contained
subprograms in my current development.