public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Malcolm <dmalcolm@redhat.com>
To: "Richard Biener" <richard.guenther@gmail.com>,
	"Frédéric Marchal" <fmarchal@perso.be>
Cc: GCC Development <gcc@gcc.gnu.org>
Subject: Re: Translation breaks IDE
Date: Fri, 17 Mar 2017 13:30:00 -0000	[thread overview]
Message-ID: <1489757440.28956.61.camel@redhat.com> (raw)
In-Reply-To: <CAFiYyc2rjxjgvghsKtiNV-PmRPoSzuFOcDPCu8QJ1FLwSSEOPQ@mail.gmail.com>

On Fri, 2017-03-17 at 12:20 +0100, Richard Biener wrote:
> On Fri, Mar 17, 2017 at 9:48 AM, Frédéric Marchal <fmarchal@perso.be>
> wrote:
> > Hi,
> > 
> > I gave my partial French translation a field trial this week and it
> > didn't went
> > well. QtCreator can't see error messages any more if they are
> > translated.
> > 
> > QtCreator identifies errors and warnings by parsing gcc output:
> > 
> > file.c:24:5: error: …
> > file.c:25:3: warning: …
> > 
> > But if "error" and "warning" are translated it becomes impossible
> > to sort out
> > the messages.
> > 
> > What can be done to help IDEs with translated messages?
> > 
> > Is it possible to add some --ide-mode flag or some environment
> > variable that
> > would prefix every message with untranslated hard coded tags that
> > could be used
> > by IDEs? I'm thinking about something along the line:
> > 
> > (E):file.c:24:5: <same message as now for errors, with translation>
> > (W): for warnings
> > 
> > These two could be put to use immediately because QtCreator already
> > do
> > something similar with MSVC. It just lacks something as the above
> > mechanism to
> > do it with gcc.
> > 
> > And it might be possibly to add other categories that could be used
> > later such
> > as:
> > 
> > (F): for fatal errors
> > (N): for notifications and informations
> > (I): included by
> > (C): candidates for overloaded functions
> > (H): "called from here" or "in this context"
> > (!): internal error
> > 
> > This list certainly needs more thinking and IDE folks could give
> > more insight
> > but you see were I'm heading.
> 
> I think a IDE mode ("machine interface") would be fine.  We already
> have
> -fdiagnostics-parseable-fixits for example, generalizing this to sth
> like
> -fdiagnostics-mi would be nice.

This all sounds a lot like:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79423

Paraphrasing myself from that RFE: given that many IDEs can already
parse LANG=C output, presumably you'd want a command-line flag that
suppresses just the translation of "error" and "warning" etc, so that
instead of output of the form:

[with LANG=ja_JP.utf-8]

/tmp/test.cc: 関数 ‘int x2()’ 内:
/tmp/test.cc:3:4: エラー: some translated message here
 x0 x3 = x3.
    ^~
/tmp/test.cc:1:7: 備考: some other translated message here
 class x0;
       ^~

you get:

/tmp/test.cc: In function ‘int x2()’:
/tmp/test.cc:3:4: error: the same *translated* message here
 x0 x3 = x3.
    ^~
/tmp/test.cc:1:7: note: again, the message is still translated here
 class x0;
       ^~

i.e. that the content of the messages themselves should still be
translated, even when in some kind of IDE mode; it's just the
"error"/"warning" etc boilerplate that shouldn't be.

I can implement this for gcc 8.

What should the diagnostic be called?

  -fdiagnostics-output-format=VALUE
  -fdiagnostics-mi
  -fide

etc

Dave

  reply	other threads:[~2017-03-17 13:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-17  8:48 Frédéric Marchal
2017-03-17 11:20 ` Richard Biener
2017-03-17 13:30   ` David Malcolm [this message]
2017-03-17 16:36     ` Frédéric Marchal
2017-03-17 19:58       ` Andreas Schwab
2017-03-21  9:57     ` Florian Weimer
2017-03-21 10:55       ` Frédéric Marchal
2017-03-17 11:32 ` Janne Blomqvist
2017-03-17 12:17   ` Frédéric Marchal
2017-03-17 12:28     ` Jonathan Wakely
2017-03-17 16:36       ` Frédéric Marchal
2017-03-17 17:09       ` Gabriel Paubert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1489757440.28956.61.camel@redhat.com \
    --to=dmalcolm@redhat.com \
    --cc=fmarchal@perso.be \
    --cc=gcc@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).