From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: Ian Lance Taylor <iant@google.com>
Cc: "Lawrence Crowl" <crowl@google.com>,
"Manuel López-Ibáñez" <lopezibanez@gmail.com>,
"Jonathan Wakely" <jwakely.gcc@gmail.com>,
"gcc Mailing List" <gcc@gcc.gnu.org>
Subject: Re: Updated GCC vs Clang diagnostics
Date: Fri, 13 Apr 2012 05:58:00 -0000 [thread overview]
Message-ID: <CAAiZkiCX1VHH8gDoGjHwfYNeCPnoD8gOaC+1tS0Q3E2fYX-scg@mail.gmail.com> (raw)
In-Reply-To: <mcrfwc89pwr.fsf@dhcp-172-18-216-180.mtv.corp.google.com>
On Fri, Apr 13, 2012 at 12:11 AM, Ian Lance Taylor <iant@google.com> wrote:
> I personally think it would be an excellent idea. Even clang's C++
> error messages can be long. A simple use of color is an excellent way
> to draw the eye to the more important parts of the message. If the
> color is not available, then it doesn't help, but the error message can
> be understood without it.
I would expect that an implementation in this direction would transform
error ("there is no operator %E with arguments %T and %T", foo, bar, baz)
into an internal IL rich enough to represent formatting directives
(and "2D" representation) independent of the actual rendering device's
capabilities.
It would then be up to each output device to display the diagnostics based on
their own characteristics (color or not, caret or not, pointing the cursor back
to the source file or not). And indeed, it would be really terrible idea if the
intelligibility of a diagnostic -requires- colors.
-- Gaby
next prev parent reply other threads:[~2012-04-13 5:58 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-12 21:50 Manuel López-Ibáñez
2012-04-12 21:54 ` Gabriel Dos Reis
2012-04-12 22:05 ` Manuel López-Ibáñez
2012-04-12 22:18 ` Lawrence Crowl
2012-04-13 5:12 ` Ian Lance Taylor
2012-04-13 5:58 ` Gabriel Dos Reis [this message]
2012-04-13 6:03 ` Jakub Jelinek
2012-04-13 6:07 ` Gabriel Dos Reis
2012-04-13 8:41 ` Manuel López-Ibáñez
2012-04-13 8:47 ` Gabriel Dos Reis
2012-04-13 9:00 ` Manuel López-Ibáñez
2012-04-13 9:09 ` Gabriel Dos Reis
2012-04-13 14:23 ` Jakub Jelinek
2012-04-13 15:23 ` Gabriel Dos Reis
2012-04-13 15:30 ` NightStrike
2012-04-13 15:36 ` Gabriel Dos Reis
2012-04-13 15:41 ` NightStrike
2012-04-13 15:53 ` Gabriel Dos Reis
2012-04-13 15:59 ` NightStrike
2012-04-13 16:02 ` Gabriel Dos Reis
2012-04-13 20:59 ` Lawrence Crowl
2012-04-14 6:58 ` Marc Glisse
2012-04-12 22:18 ` Gabriel Dos Reis
2012-04-12 22:43 ` Manuel López-Ibáñez
2012-04-13 1:40 ` Joe Buck
2012-04-13 2:27 ` Manuel López-Ibáñez
2012-04-13 3:37 ` Gabriel Dos Reis
2012-04-13 8:27 ` Manuel López-Ibáñez
2012-04-13 8:41 ` Gabriel Dos Reis
2012-04-13 9:08 ` Jonathan Wakely
2012-04-13 8:59 ` Jonathan Wakely
2012-04-13 9:04 ` Gabriel Dos Reis
2012-04-13 10:54 ` Manuel López-Ibáñez
2012-04-13 11:36 ` Richard Guenther
2012-04-13 13:40 ` Gabriel Dos Reis
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=CAAiZkiCX1VHH8gDoGjHwfYNeCPnoD8gOaC+1tS0Q3E2fYX-scg@mail.gmail.com \
--to=gdr@integrable-solutions.net \
--cc=crowl@google.com \
--cc=gcc@gcc.gnu.org \
--cc=iant@google.com \
--cc=jwakely.gcc@gmail.com \
--cc=lopezibanez@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).