From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 82EFC3858D3C; Fri,  2 Jun 2023 18:16:15 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 82EFC3858D3C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1685729775;
	bh=IVNin0ysNbAjgNcDcvM5BKzLKl3qUizvBuYgzxjbF0M=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=l4kPLf4iiaDyqcwel7QcnzIUrM3qdBu6BYZ/9Gikwcgah6s05zc1Nu1U5VU6uiAoa
	 9ehUOCaCzJxqoEdyTYMnswO9j56kbffxjSJ4II9XXi8v1GwJi3Hns7Rw3MJ0zkYC11
	 sqXDto7vSLyn968aEgz7Hx5C3pK/iC97MaabtfQE=
From: "sgk at troutmask dot apl.washington.edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/106035] F2018 allows an IMPORT statement within the
 BLOCK construct.
Date: Fri, 02 Jun 2023 18:16:15 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: sgk at troutmask dot apl.washington.edu
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-106035-4-6eRpzlcaHb@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106035-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106035-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

--- 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 wro=
te:
>=20
> --- Comment #5 from Jorge D'Elia <jdelia@santafe-conicet.gov.ar> ---
>=20
> 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 a=
s, 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.=