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
