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.mo...@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