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

[Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>]

Dear Mikael,

This looks good to me.  The two week delay to back-porting is a good idea.

Thanks for the patch

Paul

On 10 January 2013 15:57, Mikael Morin <mikael.morin@sfr.fr> wrote:
> 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
>
>
>



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy