This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, Fortran] gfc_notify_std cleanup


Hi Tobias,

>> here is a patch which makes 'gfc_notify_std' print the relevant
>> version of the Fortran standard automatically when issuing
>> errors/warnings. Up to now this had to be done manually and was
>> forgotten (or inconsistent)
>
>
> I think the patch is a good idea. Some comments from glancing at the patch.

thanks for your comments!


>> -    error_print (_("Error:"), _(gmsgid), argp);
>> +    strcpy (buffer, "Error:");
>
>
> This seems to break internationalization.

Ah, very good point. In fact I haven't touched this aspect of gfortran
very much yet, and so I completely failed to remember that those
_(...) decorations are related to native language support.

But: Even if the string is not being translated in the line shown
above, the complete buffer will be translated later:

+  error_print (_(buffer), _(gmsgid), argp);

However, it would certainly be better to translate the two parts
separately, and not the buffer as a whole. I have updated the patch in
this respect.


>> +    case GFC_STD_F2008_TS:
>> +      strcat (buffer, " TS 29113:");
>> +      break;
>
>
> That's currently correct. However, there is another post-Fortran 2008
> Technical Specification in preparation. (Coarray extensions.)* How should be
> handled? "TS 29113 or TS 12345:"?

Good question. As long as this upcoming TR is not finalized, we
probably don't have to handle it at all. Maybe this question can just
be deferred until it becomes acute?

For now, the patch maintains the current wording in all those error
messages (also in order not to get into a hell of testsuite failures).
But certainly it simplifies the act of changing the wording (in case
it may that be necessary in the future).


>> +    case GFC_STD_LEGACY:
>> +      strcat (buffer, " Extension:");
>
>
> I'd prefer something like "Legacy extension:" (Or "Legacy:"). "Extension"
> makes it very hard to find the flag in the compiler to enable this feature
> (-std=legacy). Recall that the default -std=gnu doesn't include legacy.

Ok. As noted above, I was just sticking to the present wording, but I
agree that "Legacy extension" would make more sense. I have adjusted
the patch, and will re-check if it triggers any testsuite failures.
Btw, I'm using upper case in "Extension" for now, since it will surely
reduce the risk of generating failures. This could still be changed in
a follow-up patch.


>> +      strcat (buffer, " Fortran 2008 obsolescent feature:");
>>
>
> I'd rather have something like "Obsolescent since Fortran 2008:". Especially
> when using -std=f2015,* the wording seems to be not ideal.

Again: Maintaining the wording to avoid testsuite conflicts. Can we
handle that in a follow-up, where also the wording of some of the
others could be adjusted? The patch is big enough as it is (without
having to touch the testsuite) ...


> Additionally, your patch won't work with internationalization. For "Fortran
> 2008" that's probably okay, but for this one, I think it should be
> translatable.

I'm now separately translating all strings except "Fortran 2003",
"Fortran 2008" and "TS 29113".

New patch attached. Ok for trunk after regtesting?

Cheers,
Janus

Attachment: pr51081_v3.diff
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]