>>> without any regressions. Can anybody think of a case where the names can
>>> be
>>> > identical, but the variables different? (I can't).
>>
>> Well, I'd say this can only happen if both variables reside in
>> different namespaces (i.e. different modules or procedures).
>>
>
> gfc_are_identical variables is only called from within gfc_dep_compare_expr.
> It makes no sense to call this function
> to compare expressions from different statements, unless one has carefully
> analyzed that no intervening assignment to the variables has taken place.
> Comparing across namespaces makes even less sense.
>
> So yes, I think it is enough if we compare the variable names, and
> document this in a commtent.
Actually, on second thought, I disagree.
For the original usage cases of gfc_dep_compare_expr, I'm not sure if
one can guarantee the expressions to be in the same namespace.
However, for the overriding checks, both expressions are guaranteed to
be in *different* namespaces (namely: two different procedures). And
as Mikael noted, it is crucial wether the symbols in the expressions
are dummy arguments or not:
1) Dummies are guaranteed to have equal names in overridden
procedures, so we can just compare names.
2) Non-dummies could have the same name, but still sit in different
namespaces, so for them we really have to check for equal symbols!
Here is a variant of the original test case from the PR, which will be
accepted if we only check for names (but it should actually be
rejected):
module world
implicit none
type :: world_1
contains
procedure, nopass :: string => w1_string
end type
type, extends(world_1) :: world_2
contains
procedure, nopass :: string => w2_string
end type
contains
function w1_string (m)
integer, parameter :: n = 5
integer, intent(in) :: m
character(n+m) :: w1_string
w1_string = "world"
end function
function w2_string (m)
integer, parameter :: n = 6
integer, intent(in) :: m
character(n+m) :: w2_string
w2_string = "world2"
end function
end module
Cheers,
Janus
