[patch, fortran] PR30681 "obsolescent" vs. "obsolete"

[Jerry DeLisle]

Brooks Moses wrote:
> Jerry DeLisle wrote:
>> This patch changes the word "Obsolete" to "Obsolescent" in the 
>> relevant error messages.  The behavior remains the same.  We throw an 
>> error instead of a warning with -std=f95 or -std=f2003 to discourage 
>> the use of these features which are in the "process of becoming obsolete"
> [...]
>> I will commit to 4.3 shortly and to 4.2 and 4.1 if no one objects.
> 
> I object.  :)
> 
> First, I would very strongly disagree with that behavior for obsolescent 
> features.  Obsolescent features are _permitted_ by the standard; thus 
> giving an error with -std=f95 is simply incorrect.  I would even 
> disagree with having a warning for obsolescent features unless the user 
> specifically and explicitly requested such.
> 
> With that said, however, these are in general DELETED features, not 
> obsolescent ones, and your rewording is incorrect:
> 
>> !           if (gfc_notify_std (GFC_STD_F95_DEL, "Obsolescent: ASSIGNED "
>>                     "variable in FORMAT tag at %L", &e->where)
> [...]
>> !     gfc_notify_std (GFC_STD_F95_DEL, "Obsolescent: REAL DO loop 
>> iterator at %L",
>>               &iter->var->where);
> [...]
>> !     gfc_notify_std (GFC_STD_F95_DEL, "Obsolescent: GOTO at %L jumps 
>> to END "
>>               "of construct at %L", &code->loc, &found->loc);
> 
> All of the error messages that you're rewording are controlled by 
> GFC_STD_F95_DEL.  This flag signals deleted features, which are NOT 
> permitted by the standard, and thus it is appropriate to throw an error.
> 
> There is one exception, though, which is a bug:
>> !   if (gfc_notify_std (GFC_STD_F95_DEL, "Obsolescent: arithmetic IF 
>> statement "
>>                 "at %C") == FAILURE)
> [...]
>> !       if (gfc_notify_std (GFC_STD_F95_DEL, "Obsolescent: arithmetic 
>> IF "
>>                 "statement at %C") == FAILURE)
> 
> Arithmetic IF statements are indeed merely obsolescent.  Here, your 
> rewording would be correct, but we should not be throwing this error, 
> and especially should not be throwing it conditioned on GFC_STD_F95_DEL.
> 
> - Brooks
> 
> 
I am happily corrected.  I will go back and clean this up some more.  I was sort 
of trolling for a response anyway.  It occurred to me as being a bit odd why we 
had errors on that one at all.

Thanks Brooks.

Jerry