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

[Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>]

Paul Thomas wrote:
> 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?

I think an error message should preferably point to the place where the error
occurs.

EQUIVALENCE(i,j)
! <--- code perfectly valid until here
integer, target :: i   ! <--- this line tries to do something wrong

whereas

integer, target :: i
! <--- code perfectly valid until here
EQUIVALENCE(i,j)   ! <--- this line tries to do something wrong

I can see why one could like to have the error associated with the EQUIVALENCE
-- after all, the constraint that is violated is given together with the
syntax of EQUIVALENCE in the standard, but given the fact that adding new
conflicts is really easy, and keeps this code in one place without adding new
passes to resolution, I like this better.

Cheers,
- Tobi