| Message ID | CAKwh3qgaiXOFrjNXijPBcJ8SWsc5ET0LbTknBiQ8iSD6va+p7w@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
Am 02.02.2016 um 21:26 schrieb Janus Weil: > Hi all, > > here is a diagnostics patch, which makes sure that the responsible > flag is printed in several warning messages (for which this was still > missing). > > The only case that I'm not completely sure about is the hunk in > intrinsic.c. In particular I was not able to trigger this warning and > found no occurrence of it in the testsuite. Could someone check if the > flag that I'm using there is correct, please? > > As a small extra the patch also mentions the -Wpedantic flag in the > gfortran documentation. > > It regtests cleanly on x86_64-linux-gnu. Ok for trunk? > > Cheers, > Janus > if (source_size < result_size) - gfc_warning (0, "Intrinsic TRANSFER at %L has partly undefined result: " - "source size %ld < result size %ld", &source->where, - (long) source_size, (long) result_size); + gfc_warning (OPT_Wsurprising, "Intrinsic TRANSFER at %L has partly " + "undefined result: source size %ld < result size %ld", + &source->where, (long) source_size, (long) result_size); Breaking apart of these strings will probably hamper translation. Cheers, Manfred
Hi, 2016-02-03 10:21 GMT+01:00 Manfred Schwarb <manfred99@gmx.ch>: >> here is a diagnostics patch, which makes sure that the responsible >> flag is printed in several warning messages (for which this was still >> missing). >> > > if (source_size < result_size) > - gfc_warning (0, "Intrinsic TRANSFER at %L has partly undefined result: > " > - "source size %ld < result size %ld", &source->where, > - (long) source_size, (long) result_size); > + gfc_warning (OPT_Wsurprising, "Intrinsic TRANSFER at %L has partly " > + "undefined result: source size %ld < result size %ld", > + &source->where, (long) source_size, (long) result_size); > > Breaking apart of these strings will probably hamper translation. thanks for the comment, I was not aware that this is a problem (in fact I'm rather ignorant of the translation process as a whole). I was just trying to comply with the GNU coding standards by avoiding overlong lines. So, I assume the problem is that the strings are being broken *differently* than before, right? (Obviously the were broken already ...) I guess I will just move the start of the warning message to a new line in order to avoid this. Btw, if anyone notices any further cases where the flag is missing in the warning message, please let me know. (I haven't searched through the whole gfortran code for more such cases and I'm not planning on doing so, but I'll be happy to include further cases in the patch if pointed out to me ...) Also I guess I should mention Manuel and Dominique in the Changelog (for their supportive comments in the PR). Cheers, Janus
Am 03.02.2016 um 19:18 schrieb Janus Weil: > Hi, > > 2016-02-03 10:21 GMT+01:00 Manfred Schwarb <manfred99@gmx.ch>: >>> here is a diagnostics patch, which makes sure that the responsible >>> flag is printed in several warning messages (for which this was still >>> missing). >>> >> >> if (source_size < result_size) >> - gfc_warning (0, "Intrinsic TRANSFER at %L has partly undefined result: >> " >> - "source size %ld < result size %ld", &source->where, >> - (long) source_size, (long) result_size); >> + gfc_warning (OPT_Wsurprising, "Intrinsic TRANSFER at %L has partly " >> + "undefined result: source size %ld < result size %ld", >> + &source->where, (long) source_size, (long) result_size); >> >> Breaking apart of these strings will probably hamper translation. > > thanks for the comment, I was not aware that this is a problem (in > fact I'm rather ignorant of the translation process as a whole). I was > just trying to comply with the GNU coding standards by avoiding > overlong lines. > > So, I assume the problem is that the strings are being broken > *differently* than before, right? (Obviously the were broken already > ...) I guess I will just move the start of the warning message to a > new line in order to avoid this. > There are 2 things with translation, and there is a third issue: - As you noticed, breaking things differently means translation has to be done again. - Normally, each string is translated independently, and depending on the language there may be lack of context (e.g. adjectives get different suffixes depending on the noun). - grep'ability: you got such an error message, then you want to look for the corresponding code and do a grep for e.g. "partly undefined result". GOTCHA! So IMHO strings should be left intact, irrespective of some arbitrary 80 char limits. Other projects, e.g. the linux kernel, do deliberately violate the 80 char limit if it is needed, and do not always break strings. I do not know how it is handled in the GCC project, but I guess common sense is always a good recipe. Of course it is no problem to split at natural boundaries, e.g. at ":", ";" or "." characters. Cheers, Manfred > Btw, if anyone notices any further cases where the flag is missing in > the warning message, please let me know. (I haven't searched through > the whole gfortran code for more such cases and I'm not planning on > doing so, but I'll be happy to include further cases in the patch if > pointed out to me ...) > > Also I guess I should mention Manuel and Dominique in the Changelog > (for their supportive comments in the PR). > > Cheers, > Janus >
On Wed, 3 Feb 2016, Manfred Schwarb wrote: > There are 2 things with translation, and there is a third issue: > - As you noticed, breaking things differently means translation has to be > done again. > - Normally, each string is translated independently, and depending on the > language there may be lack of context (e.g. adjectives get different > suffixes > depending on the noun). I believe gettext works fine with (compile-time) string constant concatenation - that is, extracts the whole concatenated string for translation, so these are non-issues. What doesn't work includes: * Runtime concatenation of strings or otherwise putting English fragments together at runtime. * String constant concatenation where one of the concatenated pieces comes from a macro expansion. * The argument for translation being a conditional expression: error (cond ? "message 1" : "message 2"); (in this case, only one of the messages may be extracted for translation, so you need to mark both of them up with appropriate macros such as G_).
Index: gcc/fortran/check.c =================================================================== --- gcc/fortran/check.c (Revision 233091) +++ gcc/fortran/check.c (Arbeitskopie) @@ -5180,9 +5180,9 @@ gfc_check_transfer (gfc_expr *source, gfc_expr *mo return true; if (source_size < result_size) - gfc_warning (0, "Intrinsic TRANSFER at %L has partly undefined result: " - "source size %ld < result size %ld", &source->where, - (long) source_size, (long) result_size); + gfc_warning (OPT_Wsurprising, "Intrinsic TRANSFER at %L has partly " + "undefined result: source size %ld < result size %ld", + &source->where, (long) source_size, (long) result_size); return true; } Index: gcc/fortran/frontend-passes.c =================================================================== --- gcc/fortran/frontend-passes.c (Revision 233091) +++ gcc/fortran/frontend-passes.c (Arbeitskopie) @@ -715,11 +715,11 @@ do_warn_function_elimination (gfc_expr *e) if (e->expr_type != EXPR_FUNCTION) return; if (e->value.function.esym) - gfc_warning (0, "Removing call to function %qs at %L", - e->value.function.esym->name, &(e->where)); + gfc_warning (OPT_Wfunction_elimination, "Removing call to function %qs " + "at %L", e->value.function.esym->name, &(e->where)); else if (e->value.function.isym) - gfc_warning (0, "Removing call to function %qs at %L", - e->value.function.isym->name, &(e->where)); + gfc_warning (OPT_Wfunction_elimination, "Removing call to function %qs " + "at %L", e->value.function.isym->name, &(e->where)); } /* Callback function for the code walker for doing common function elimination. This builds up the list of functions in the expression Index: gcc/fortran/intrinsic.c =================================================================== --- gcc/fortran/intrinsic.c (Revision 233091) +++ gcc/fortran/intrinsic.c (Arbeitskopie) @@ -4369,7 +4369,7 @@ gfc_check_intrinsic_standard (const gfc_intrinsic_ { /* Do only print a warning if not a GNU extension. */ if (!silent && isym->standard != GFC_STD_GNU) - gfc_warning (0, "Intrinsic %qs (is %s) is used at %L", + gfc_warning (OPT_Wintrinsics_std, "Intrinsic %qs (is %s) is used at %L", isym->name, _(symstd_msg), &where); return true; Index: gcc/fortran/invoke.texi =================================================================== --- gcc/fortran/invoke.texi (Revision 233091) +++ gcc/fortran/invoke.texi (Arbeitskopie) @@ -709,8 +709,10 @@ Check the code for syntax errors, but do not actua will generate module files for each module present in the code, but no other output file. -@item -pedantic +@item -Wpedantic +@itemx -pedantic @opindex @code{pedantic} +@opindex @code{Wpedantic} Issue warnings for uses of extensions to Fortran 95. @option{-pedantic} also applies to C-language constructs where they occur in GNU Fortran source files, such as use of @samp{\e} in a Index: gcc/fortran/resolve.c =================================================================== --- gcc/fortran/resolve.c (Revision 233091) +++ gcc/fortran/resolve.c (Arbeitskopie) @@ -2127,9 +2127,9 @@ resolve_elemental_actual (gfc_expr *expr, gfc_code && (set_by_optional || arg->expr->rank != rank) && !(isym && isym->id == GFC_ISYM_CONVERSION)) { - gfc_warning (0, "%qs at %L is an array and OPTIONAL; IF IT IS " - "MISSING, it cannot be the actual argument of an " - "ELEMENTAL procedure unless there is a non-optional " + gfc_warning (OPT_Wpedantic, "%qs at %L is an array and OPTIONAL; " + "IF IT IS MISSING, it cannot be the actual argument of " + "an ELEMENTAL procedure unless there is a non-optional " "argument with the same rank (12.4.1.5)", arg->expr->symtree->n.sym->name, &arg->expr->where); } @@ -3685,7 +3685,8 @@ resolve_operator (gfc_expr *e) else msg = "Inequality comparison for %s at %L"; - gfc_warning (0, msg, gfc_typename (&op1->ts), &op1->where); + gfc_warning (OPT_Wcompare_reals, msg, + gfc_typename (&op1->ts), &op1->where); } } @@ -14890,12 +14891,13 @@ warn_unused_fortran_label (gfc_st_label *label) switch (label->referenced) { case ST_LABEL_UNKNOWN: - gfc_warning (0, "Label %d at %L defined but not used", label->value, - &label->where); + gfc_warning (OPT_Wunused_label, "Label %d at %L defined but not used", + label->value, &label->where); break; case ST_LABEL_BAD_TARGET: - gfc_warning (0, "Label %d at %L defined but cannot be used", + gfc_warning (OPT_Wunused_label, + "Label %d at %L defined but cannot be used", label->value, &label->where); break; Index: gcc/fortran/trans-common.c =================================================================== --- gcc/fortran/trans-common.c (Revision 233091) +++ gcc/fortran/trans-common.c (Arbeitskopie) @@ -1138,13 +1138,13 @@ translate_common (gfc_common_head *common, gfc_sym if (warn_align_commons) { if (strcmp (common->name, BLANK_COMMON_NAME)) - gfc_warning (0, + gfc_warning (OPT_Walign_commons, "Padding of %d bytes required before %qs in " "COMMON %qs at %L; reorder elements or use " "-fno-align-commons", (int)offset, s->sym->name, common->name, &common->where); else - gfc_warning (0, + gfc_warning (OPT_Walign_commons, "Padding of %d bytes required before %qs in " "COMMON at %L; reorder elements or use " "-fno-align-commons", (int)offset, Index: gcc/testsuite/gfortran.dg/elemental_optional_args_6.f90 =================================================================== --- gcc/testsuite/gfortran.dg/elemental_optional_args_6.f90 (Revision 233091) +++ gcc/testsuite/gfortran.dg/elemental_optional_args_6.f90 (Arbeitskopie) @@ -1,4 +1,5 @@ ! { dg-do run } +! { dg-options "-Wpedantic" } ! ! PR fortran/53692 !
Hi all, here is a diagnostics patch, which makes sure that the responsible flag is printed in several warning messages (for which this was still missing). The only case that I'm not completely sure about is the hunk in intrinsic.c. In particular I was not able to trigger this warning and found no occurrence of it in the testsuite. Could someone check if the flag that I'm using there is correct, please? As a small extra the patch also mentions the -Wpedantic flag in the gfortran documentation. It regtests cleanly on x86_64-linux-gnu. Ok for trunk? Cheers, Janus 2016-02-01 Janus Weil <janus@gcc.gnu.org> PR fortran/69495 * invoke.texi: Mention -Wpedantic as an alias of -pedantic. * check.c (gfc_check_transfer): Mention responsible flag in warning message. * frontend-passes.c (do_warn_function_elimination): Ditto. * intrinsic.c (gfc_check_intrinsic_standard): Ditto. * resolve.c (resolve_elemental_actual): Ditto. (resolve_operator): Ditto. (warn_unused_fortran_label): Ditto. * trans-common.c (translate_common): Ditto. 2016-02-01 Janus Weil <janus@gcc.gnu.org> PR fortran/69495 * gfortran.dg/elemental_optional_args_6.f90: Use -Wpedantic flag.