[Patch, fortran] PR53537 Explicit import of USE renamed symbol.

[Mikael Morin]

Hello,

for the case:
[...]
        use select_precision, only: wp => dp
        interface
            subroutine ode_derivative(x)
                import   :: wp
[...]

`wp' is currently imported in the subroutine namespace under its 
original name `dp', which leads to an error if one tries to use `wp'.

The core of the fix, which is basically a collection of the patches 
Tobias posted in the PR, uses the matched name instead of the original 
name for the symtree in the subroutine namespace.
Tobias' patches regress on import7.f90 because variable_decl lookups for 
the type in the interface namespace (to check that it has been declared) 
using the original name (which is the only one available there).
The fix I propose for that is to remove the regressing error, and try to 
trigger the existing generic code diagnosing undeclared types. The 
latter doesn't trigger currently because gfc_get_ha_symtree keep going 
up the parent namespace until it finds a symbol, so in an interface 
block, it is guaranteed to find a declared symbol, even if the latter 
hasn't been imported in the interface.
The fix for that checks whether we are in an interface body without 
blank import statement, and aborts the lookup in that case.  A few 
adjustments are then needed where the parent namespace is accessed 
directly, thus bypassing the above check.

The change from the interface-specific error to the more general error 
needs a few test cases to be adjusted, namely import2.f90, import8.f90, 
and interface_derived_type_1.f90
from:

            type(fcnparms) :: fparams ! { dg-error "not been declared 
within the in
                                     1
Error: The type of 'fparams' at (1) has not been declared within the 
interface

to:

            type(fcnparms) :: fparams ! { dg-error "not been declared 
within the in
                          1
Error: Derived type 'fcnparms' at (1) is being used before it is defined


The caret is slightly better, the message is slightly worse.  I think 
it's OK, but could consider trying to issue a better error message.
Otherwise it passes the test suite. OK for trunk?

As the code impacts the name to symbol resolution code, it has a big 
potential for breakage; the bug is a regression however, so I plan to 
backport to 4.7 and 4.6, say, two weeks after trunk at least (if I don't 
forget). Does it sound good?

Mikael



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pr53537.CL
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20130110/d801ce79/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pr53537.diff
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20130110/d801ce79/attachment-0001.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: import10.f90
Type: text/x-fortran
Size: 593 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20130110/d801ce79/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: import11.f90
Type: text/x-fortran
Size: 626 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20130110/d801ce79/attachment-0001.bin>