On Thursday 04 August 2011 15:18:46 Tobias Burnus wrote: > >> 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[*] In that case you wouldn't have this error, but you could still have some other errors coming from other rules.
> > 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. Yes, it was just a thought. > > > 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. My point is we should let the user bump himself into other constraints and figure out what is right. > > 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. My point is we should diagnose the constraints, not the combination of them... > That makes it difficult to spot all the cases which are (in)valid, ...for exactly this reason. > 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 propose some. Mikael
