[Bug c/85664] Don't ask questions if tere's no way to answer

2018-05-06 Thread gcc at mailed dot e4ward.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85664

--- Comment #4 from Mysha  ---
> The suggestions are eminently useful...

Which is why I said I would prefer to have a --terse option. After all, having
such an option implies that you can choose not to use them.


> If you don't like getting too many errors or verbose output, you can use
> -fmax-errors=1 -fno-diagnostics-show-caret -fno-diagnostics-show-option. ...

Great. It turns out the impression I got from the reactions to the two reports,
that there was no option to be terse, was mistaken. My trust in GCC is
restored. Thank you. (You know why I didn't know.)


> ... we have also bug reports asking for messages to be more verbose. ..."

It's OK to feel attacked. It's the same I feel for getting a reply about
something I didn't say, on a topic that wasn't even the focus of the report. I
wrote I would have "--terse" (or words to that effect), and only because I
understood that these informative extras were the only way, currently. I did
not write "I want GCC to be different for everybody because something the
developers considered a good thing doesn't always suit my particular
situation."

Right, we've now both defended ourselves. Let's continue on what I did write.
(And if you happen to be part of the European Youth Music Festival, let me know
where you are and we'll have a drink together.)


> Removing the questions do not save lines.

Indeed, which is why these two reports are related, but not duplicates.

[Bug c/85664] Don't ask questions if tere's no way to answer

2018-05-06 Thread manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85664

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Manuel López-Ibáñez  ---
(In reply to Mysha from comment #2)
> I don't know how many more unanswerable questions there are in GCC, but
> reactions suggest that these informative messages with questions are not an
> option, but rather the normal output. In that case, I'd rather have --terse;
> just the error messages, not the informative additions. (I get a lot of
> these, and with four lines per error I run our of console lines after some
> 17 typos.)

Removing the questions do not save lines.

The suggestions are eminently useful when one cannot immediately see the typo,
remember the right wording of a type, the right header and many other cases.

If you don't like getting too many errors or verbose output, you can use
-fmax-errors=1 -fno-diagnostics-show-caret -fno-diagnostics-show-option.

However, we have also bug reports asking for messages to be more verbose. One
of the often-repeated selling points of the "competition" is that they have
"expressive diagnostics", while GCC diagnostics are (were!) terse and cryptic.
There are many bug reports about making them even more verbose:
https://gcc.gnu.org/wiki/VerboseDiagnostics

If using the console for software development is too cumbersome, a better
alternative is to invoke gcc from an IDE such as Emacs, where you can jump from
error to error, jump to the code in question, and maybe apply the suggested fix
if you agree with it.

> But for the direct case: While the other one also would like to see the
> wording changed, that one is about the verbosity; what I'm after are the
> questions. If there's no checksum in those files, I figure I can just
> hexedit them, but I'd prefer a proper solution to that.

I would suggest that it would be easier to create a wrapper for gcc and use sed
or perl to filter the questions from the output. A simple regex should do the
job beautifully.

In any case, if you think a diagnostic could be better worded but no one else
seems interested in putting the effort to do it, then
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

*** This bug has been marked as a duplicate of bug 84890 ***

[Bug c/85664] Don't ask questions if tere's no way to answer

2018-05-05 Thread gcc at mailed dot e4ward.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85664

--- Comment #2 from Mysha  ---
Well,  Jonathan Wakely, I hear there's not enough love to go round.

But other than that: Yes, that is indeed one case of the compiler asking a
question where it shouldn't. And I like the approach of replacing it with
something like:
  #include  defines std::foo.
Indeed, I do have the impression that messages aren't as terse as they used to
be. Informative, but not really terse. And this would seem a nice short
alternative.


Another one case is the result from compiling program test.c:
inf main(){}

"
test.c:1:1: error: unknown type name ‘inf’; did you mean ‘int’?
 inf main(){}
 ^~~
 int
"

I don't know how many more unanswerable questions there are in GCC, but
reactions suggest that these informative messages with questions are not an
option, but rather the normal output. In that case, I'd rather have --terse;
just the error messages, not the informative additions. (I get a lot of these,
and with four lines per error I run our of console lines after some 17 typos.)

But for the direct case: While the other one also would like to see the wording
changed, that one is about the verbosity; what I'm after are the questions. If
there's no checksum in those files, I figure I can just hexedit them, but I'd
prefer a proper solution to that.

Bye
Mysha

[Bug c/85664] Don't ask questions if tere's no way to answer

2018-05-05 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85664

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Jonathan Wakely  ---
See also PR 84890 (I think this could be considered a duplicate of that one).