* Request for better syntax checking in lang.opt @ 2020-02-20 7:29 Thomas Koenig 2020-02-20 8:16 ` Martin Liška 0 siblings, 1 reply; 6+ messages in thread From: Thomas Koenig @ 2020-02-20 7:29 UTC (permalink / raw) To: gcc mailing list; +Cc: fortran Hi, having just lost a few hours on a space in lang.opt where there was supposed to be none, leading to a new option being silently ignored, a request: Would it be possible to improve the syntax checking for lang.opt? It's a file that people touch only rarely, so it is likely that they will have no experience or will already have forgotten the gotchas they encountered the last time. Regards Thomas ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Request for better syntax checking in lang.opt 2020-02-20 7:29 Request for better syntax checking in lang.opt Thomas Koenig @ 2020-02-20 8:16 ` Martin Liška 2020-02-20 18:08 ` Thomas Koenig 0 siblings, 1 reply; 6+ messages in thread From: Martin Liška @ 2020-02-20 8:16 UTC (permalink / raw) To: Thomas Koenig, gcc mailing list; +Cc: fortran On 2/20/20 8:29 AM, Thomas Koenig wrote: > Hi, > > having just lost a few hours on a space in lang.opt where > there was supposed to be none, leading to a new option > being silently ignored, a request: Hello. Sure, I can improve sanity checking. What exactly have you screwed up? > > Would it be possible to improve the syntax checking for lang.opt? > It's a file that people touch only rarely, so it is likely that > they will have no experience or will already have forgotten the > gotchas they encountered the last time. Fully agree with that! Martin > > Regards > > Â Â Â Â Thomas ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Request for better syntax checking in lang.opt 2020-02-20 8:16 ` Martin Liška @ 2020-02-20 18:08 ` Thomas Koenig 2020-02-21 9:43 ` Martin Liška 0 siblings, 1 reply; 6+ messages in thread From: Thomas Koenig @ 2020-02-20 18:08 UTC (permalink / raw) To: Martin Liška, gcc mailing list; +Cc: fortran Hi Martin, > Sure, I can improve sanity checking. Thanks! > What exactly have you screwed up? I had, in lang.opt EnumValue Enum (gfc_fcoarray) String (native) Value (GFC_FCOARRAY_NATIVE) It was a bit non-obvious to me that this led to the whole sub-option being ignored due to *drum roll* the space between the keywords and the opening parenthesis. I have internalized the GNU style guides to such an extent that I hardly ever see the space there :-) Regards Thomas ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Request for better syntax checking in lang.opt 2020-02-20 18:08 ` Thomas Koenig @ 2020-02-21 9:43 ` Martin Liška 2020-02-23 9:48 ` Thomas Koenig 0 siblings, 1 reply; 6+ messages in thread From: Martin Liška @ 2020-02-21 9:43 UTC (permalink / raw) To: Thomas Koenig, gcc mailing list; +Cc: fortran [-- Attachment #1: Type: text/plain, Size: 750 bytes --] On 2/20/20 7:08 PM, Thomas Koenig wrote: > Hi Martin, > >> Sure, I can improve sanity checking. > > Thanks! > >> What exactly have you screwed up? > I had, in lang.opt > > EnumValue > Enum (gfc_fcoarray) String (native) Value (GFC_FCOARRAY_NATIVE) > > It was a bit non-obvious to me that this led to the whole sub-option > being ignored due to > > *drum roll* > > the space between the keywords and the opening parenthesis. I have > internalized the GNU style guides to such an extent that I hardly > ever see the space there :-) Hello. I was able to write a sanity check for these kind of issues, but it does not resolve all similar issues for other keywords. It's not easy to do it. Martin > > Regards > >     Thomas [-- Attachment #2: 0001-Make-more-sanity-checks-for-enums.patch --] [-- Type: text/x-patch, Size: 1984 bytes --] From 440fda0ccd2211cfd0478f50cc20d0969fe8bce0 Mon Sep 17 00:00:00 2001 From: Martin Liska <mliska@suse.cz> Date: Fri, 21 Feb 2020 10:40:57 +0100 Subject: [PATCH] Make more sanity checks for enums. --- gcc/opt-functions.awk | 13 +++++++++++++ gcc/opt-read.awk | 10 +++++----- 2 files changed, 18 insertions(+), 5 deletions(-) diff --git a/gcc/opt-functions.awk b/gcc/opt-functions.awk index 2f0442dc563..be4b9e66165 100644 --- a/gcc/opt-functions.awk +++ b/gcc/opt-functions.awk @@ -72,6 +72,19 @@ function opt_args(name, flags) return flags } +# If FLAGS contains a "NAME(...argument...)" flag, return the value +# of the argument. Print error message otherwise. +function opt_args_non_empty(name, flags, description) +{ + args = opt_args(name, flags) + if (args == "") + { + print "Empty option argument '" name "' during parsing of: " flags >> "/dev/stderr" + exit 1 + } + return args +} + # Return the Nth comma-separated element of S. Return the empty string # if S does not contain N elements. function nth_arg(n, s) diff --git a/gcc/opt-read.awk b/gcc/opt-read.awk index a2e16f29aff..9bb9dfcf6ca 100644 --- a/gcc/opt-read.awk +++ b/gcc/opt-read.awk @@ -81,8 +81,8 @@ BEGIN { } else if ($1 == "Enum") { props = $2 - name = opt_args("Name", props) - type = opt_args("Type", props) + name = opt_args_non_empty("Name", props) + type = opt_args_non_empty("Type", props) unknown_error = opt_args("UnknownError", props) enum_names[n_enums] = name enum_type[name] = type @@ -93,9 +93,9 @@ BEGIN { } else if ($1 == "EnumValue") { props = $2 - enum_name = opt_args("Enum", props) - string = opt_args("String", props) - value = opt_args("Value", props) + enum_name = opt_args_non_empty("Enum", props) + string = opt_args_non_empty("String", props) + value = opt_args_non_empty("Value", props) val_flags = "0" val_flags = val_flags \ test_flag("Canonical", props, "| CL_ENUM_CANONICAL") \ -- 2.25.0 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Request for better syntax checking in lang.opt 2020-02-21 9:43 ` Martin Liška @ 2020-02-23 9:48 ` Thomas Koenig 2020-03-02 9:49 ` Martin Liška 0 siblings, 1 reply; 6+ messages in thread From: Thomas Koenig @ 2020-02-23 9:48 UTC (permalink / raw) To: Martin Liška, gcc mailing list; +Cc: fortran Hi Martin, > I was able to write a sanity check for these kind of issues, but it does > not resolve all similar issues for other keywords. It's not easy to do it. Having looked at the origina awk code, I agree. Maybe, in the long term, a lex/yacc grammar with a monolithic C program to write out the headers wold be more suitable. Having said that, I think what you did is already quite valuable and will save some gcc developers from a few prmature grey hairs :-) So, I would recommend to commit as is. Sanity checks do not have to be perfect. Thanks for taking this on! Regards Thomas ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Request for better syntax checking in lang.opt 2020-02-23 9:48 ` Thomas Koenig @ 2020-03-02 9:49 ` Martin Liška 0 siblings, 0 replies; 6+ messages in thread From: Martin Liška @ 2020-03-02 9:49 UTC (permalink / raw) To: Thomas Koenig, gcc mailing list; +Cc: fortran On 2/23/20 10:47 AM, Thomas Koenig wrote: > Hi Martin, > >> I was able to write a sanity check for these kind of issues, but it does >> not resolve all similar issues for other keywords. It's not easy to do it. > > Having looked at the origina awk code, I agree. Maybe, in the long > term, a lex/yacc grammar with a monolithic C program to write out > the headers wold be more suitable. ... or as I suggested, we could use Python. But that was not welcomed by the community as unnecessary dependency. > > Having said that, I think what you did is already quite valuable > and will save some gcc developers from a few prmature grey hairs :-) Anyway, I'll send the patch in the next stage1. Martin > > So, I would recommend to commit as is. Sanity checks do not have > to be perfect. > > Thanks for taking this on! > > Regards > > Thomas > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-03-02 9:49 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-02-20 7:29 Request for better syntax checking in lang.opt Thomas Koenig 2020-02-20 8:16 ` Martin Liška 2020-02-20 18:08 ` Thomas Koenig 2020-02-21 9:43 ` Martin Liška 2020-02-23 9:48 ` Thomas Koenig 2020-03-02 9:49 ` Martin Liška
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).