Re: [PATCH, fortran] Constraints for equivalence members and privatetypes - Ping

[Paul Thomas <paulthomas2 at wanadoo dot fr>]

> As a general remark, I had started to implement the constraints in 
> symbol.c(check_conflict) but found that the majority of the 
> equivalence constraints were to be found in resolve.c. I therefore 
> elected to put the rest there too.
>
> >
> In fact it was not just the majority but all those that could not be 
> put in match.c.  ASFAIK the reason is that half of the constraints, 
> which involve more than one symbol, sit most naturally in resolve.c 
> and the single symbol constraints have been put with them for 
> convenience.  I have a version ready to go that puts these latter in 
> check_conflict.

As part of a continuing policy of talking to myself, I have provided 
myself with a partial answer to the question:

WITH ALL THE "SCALAR" CONSTRAINTS in check_conflict

 integer                       :: I
 integer, Target               :: J
 equivalence (i, j)
 end

gives

 equivalence (i, j)
                 1
Error: EQUIVALENCE attribute conflicts with TARGET attribute in 'j' at (1)

whereas

 equivalence (i, j)
 integer                       :: I
 integer, Target               :: J
 end

gives

 integer, Target               :: J
                                  1
Error: EQUIVALENCE attribute conflicts with TARGET attribute at (1)

DOING THE SAME in resolve_equivalence always associates the error with 
the equivalence statement.

I prefer the latter but there are advantages in hitting the 
conflicts/constraints as early as possible. What do the rest of you think?

Paul T