[Patch, Fortran] (Coarray) Fix constraint checks for LOCK_TYPE

[Tobias Burnus]

On 08/04/2011 02:44 PM, Mikael Morin wrote:
>> and I belief both "var%comp" and
>> "var" are named.
> My reading is that a named variable is a variable that is an object-name.

That's actually my problem with the standard - it never quite tells what 
a "named variable" exactly is. I think at least "ptrfunction()" is not a 
named variable but just a variable.

>> The problem is that
>> diagnosing the problem can get rather difficult. For instance:
>>
>> type t
>> type(lock_type) :: C
>> end type
>> type t2
>> type(t), allocatable :: B
>> end type t2
>> type t3
>> type(t2) :: D
>> end type t3
>>
>> is valid - however, it is invalid to use:
>> type(t) :: x[*], y
>>
>> However, how to write then the error message? "Error: Invalid
>> declaration at (1) as constraint C642 is violated" is probably not very
>> helpful, but should one really re-resolve the derived type?
> I would write:
> Variable at<y>  shall be a coarray/have a codimension attribute as it has a
> non-coarray subcomponent of type LOCK_TYPE at<c>

But that error message would be very surprising for me as a user if I 
had written:

   type(t) :: x[*]

because "x" *is* a coarray - only "x%D%B" is not a coarray, which were 
fine if B weren't an allocatable/pointer or if B%C were not of LOCK_TYPE 
or B%C were itself a coarray.

> Best would be to have the full reference y%d%b%c in the error message.

I think that works not well in the current scheme as one would have to 
store this information somewhere. Either, one resolves from the outside 
to the inside: Resolve "x", which resolves "x%D", which resolves 
"x%D%B"  - and when resolving "B" the "x%D%" part is not available. Or 
one stores that "B" is invalid, then one propagates this information on 
to "D" and then to "x" - at that point one knows that "x" is invalid - 
but the information that it is due to "x%D%B" is lost.

Additionally, for the example above, should it be "x%D%B" or x%D%B%C or ...?

That's not unsolvable but requires quite some restructuring.

> Thus, we should stick closely to the standard, point exactly what is
> prohibited, and not bother too much trying to provide some hints to the users.
> ;-)

Exactly: "ERROR: C642"

Would be the most correct error message, without bothering with the 
error location, variable name - and it also contains the 42. Or even 
better "ERROR: Violating Fortran 2008 standard" ;-)

If we want to really stick close to the standard, I would propose to add 
an attr.lock_c642_violated to the derived types and check for it later 
in resolve_symbol :P.

> OK, it is starting to make sense now.
> I'm not very fond of it, but if you want to keep this diagnostic, at the very
> least put all that information in a comment. Best would be to provide it (or
> some of it) in the error message too.

I made three attempts to get the LOCK_TYPE diagnostics kind of right. I 
can also do a fourth attempt, if it is cleaner or for some other reason 
better. However, I only do it if I get a clear outline how it should be 
done, i.e. which information is stored where, where it is obtained and 
how the error message should roughly look like.

The problem with the wording is that the constraint itself is not 
directly checkable but that one has to do it in a slightly convoluted 
way. Actually, the standard does the same: Certain things are prohibited 
as one bumps into other constraints if one tries to sneak past the 
constraint.

I do not mind having something better, but coming up with some concise 
but still correct - and helpful! - comment is not that simple.

>> Having said that, I just realized that the following program is not
>> rejected but it should:
> That's exactly the reason why I don't like it. It's sufficiently difficult to get it right while sticking closely to the standard that one doesn't want to try picking one rule every 40 pages and see what is left after intersecting them.

Sorry, I cannot follow. The standard does not have constraint C123456789 
saying that it is invalid. The invalidity comes the combination of 
several constrains and definitions. That makes it difficult to spot all 
the cases which are (in)valid, but I do not see how one can prevent it. 
Thus, I claim I am "sticking closely to the standard" by rejecting the 
invalid code.

I agree that the wording could be better - but it is also difficult to 
write it in such a way that it helps a user when debugging a code as 
there might be different reason for the mistake.

Furthermore, I have stared too long at the code to be apt to find good 
wordings, thus, I am happy for suggestions for better comments and error 
messages.

> I'll review the revised patch later today.

Thanks.

Tobias