I don't know why it was considered bad (and had thought it was simply
never reviewed), but I am happy to review such patches as i18n maintainer
(including in Stage 3 - they are clearly bug fixes) if the front-end
maintainers don't reject them. However, I think they would need splitting
up fo
On Sat, 16 Aug 2008, Paolo Bonzini wrote:
> Chris Lattner wrote:
> > Please don't forget C++.
>
> C++ is a completely lost battle. I had a patch to handle all the %s in the
> source base, but my approach (which basically implied adding translatable
> strings for "a class", "to a class", "with a
Chris Lattner wrote:
On Aug 14, 2008, at 8:47 AM, Joseph S. Myers wrote:
On Thu, 14 Aug 2008, Robert Dewar wrote:
BTW, I am all in favor of caret output, it's not the default in
gnat, the default is more like the C default, but -gnatv gives
output like:
And I'd hope we could keep things th
Gabriel Dos Reis wrote:
I'm in favor of getting -fdiagnostics-show-caret=no by default in this release,
and enable people like you to get useful stuff done. That gives us time
to iron out outstanding bugs for the next release (and making it the default).
That's a good idea regardless of the ev
Gabriel Dos Reis wrote:
On Thu, Aug 14, 2008 at 11:52 AM, Tom Tromey <[EMAIL PROTECTED]> wrote:
"Joseph" == Joseph S Myers <[EMAIL PROTECTED]> writes:
I'd like to see carets on by default as part of a major release -- say
GCC 5.0. (First mention!!)
100% agreed.
-- Gaby
As I have mention
On Thu, Aug 14, 2008 at 11:52 AM, Tom Tromey <[EMAIL PROTECTED]> wrote:
>> "Joseph" == Joseph S Myers <[EMAIL PROTECTED]> writes:
> I'd like to see carets on by default as part of a major release -- say
> GCC 5.0. (First mention!!)
100% agreed.
-- Gaby
On Thu, Aug 14, 2008 at 12:14 PM, Aldy Hernandez <[EMAIL PROTECTED]> wrote:
>> * In the near future, make -fdiagnostics-show-caret the default at
>> least while in experimental mode or at least during stages1 and 2.
>> When making a release -fno-diagnostics-show-caret would be the
>> default. Do th
On Thu, Aug 14, 2008 at 7:39 AM, Joseph S. Myers
<[EMAIL PROTECTED]> wrote:
> On Thu, 14 Aug 2008, Manuel López-Ibáñez wrote:
>
> I don't think the option should necessarily just be boolean; once choice
> that may make sense would be caret diagnostics for the first diagnostic
> from an input file o
Manuel López-Ibáñez wrote:
The locations are as wrong now as they will be after enabling caret
diagnostics. The only difference is that no one pays attention right
now because that would require to enable -fshow-column and count
column numbers. So I am certainly not "breaking the compiler and
ho
2008/8/14 Mark Mitchell <[EMAIL PROTECTED]>:
> Manuel López-Ibáñez wrote:
>
>> My proposal is to enable this while not in release mode (like we
>> enable checks and dump statistics and output from the optimizers), so
>> developers notice wrong locations and open a PR and maybe even fix
>> them.
>
>
Ralf Wildenhues wrote:
* Tom Tromey wrote on Thu, Aug 14, 2008 at 07:39:57PM CEST:
FWIW -- the gcc-output-parsing tools I care most about are actually
usually parsing the output of 'make', which is already full of random
undigestible text that must be ignored. Caret diagnostics are
extremely un
Joseph S. Myers wrote:
On Thu, 14 Aug 2008, Tom Tromey wrote:
Yes, I agree, we need multiple things: accurate locations from the
front ends (ideally macro-expansion-aware), start- and end-locations,
better diagnostic output of various kinds, perhaps smarter location
handling in the optimization
Manuel López-Ibáñez wrote:
My proposal is to enable this while not in release mode (like we
enable checks and dump statistics and output from the optimizers), so
developers notice wrong locations and open a PR and maybe even fix
them.
Manuel --
I think it's great that you're working on caret
* Tom Tromey wrote on Thu, Aug 14, 2008 at 07:39:57PM CEST:
>
> FWIW -- the gcc-output-parsing tools I care most about are actually
> usually parsing the output of 'make', which is already full of random
> undigestible text that must be ignored. Caret diagnostics are
> extremely unlike to break t
> "Ralf" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:
Ralf> If the GCS-style is not powerful enough to meet GCC's needs, then please
Ralf> let's not only improve GCC, but the GCS document also, so that other
Ralf> programs improve compatibly.
Yeah, good idea.
FWIW -- the gcc-output-parsing
On Thu, 14 Aug 2008, Tom Tromey wrote:
> Yes, I agree, we need multiple things: accurate locations from the
> front ends (ideally macro-expansion-aware), start- and end-locations,
> better diagnostic output of various kinds, perhaps smarter location
> handling in the optimizations, and of course f
On Thu, 14 Aug 2008, Ralf Wildenhues wrote:
> * Tom Tromey wrote on Thu, Aug 14, 2008 at 06:52:24PM CEST:
> > I'm sympathetic to the idea that switching to caret output by default
> > will break things. However, I don't think that GCS-style ranges are
> > necessarily any more reality-proof, becau
On Thu, 14 Aug 2008, Tom Tromey wrote:
> Manuel's idea that we should enable column- or caret-output in the
> development (but not release) GCC is worthy of consideration. We
> certainly aren't seeing much progress on this front as-is, maybe this
> change would inspire GCC developers a bit. It w
> * In the near future, make -fdiagnostics-show-caret the default at
> least while in experimental mode or at least during stages1 and 2.
> When making a release -fno-diagnostics-show-caret would be the
> default. Do this through a configure option that sets the default.
>
> * In the far away futu
On Aug 14, 2008, at 8:47 AM, Joseph S. Myers wrote:
On Thu, 14 Aug 2008, Robert Dewar wrote:
BTW, I am all in favor of caret output, it's not the default in
gnat, the default is more like the C default, but -gnatv gives
output like:
And I'd hope we could keep things that way for both C and
* Tom Tromey wrote on Thu, Aug 14, 2008 at 06:52:24PM CEST:
> I'm sympathetic to the idea that switching to caret output by default
> will break things. However, I don't think that GCS-style ranges are
> necessarily any more reality-proof, because I am skeptical that most
> tool developers read th
On Thu, Aug 14, 2008 at 6:52 PM, Tom Tromey <[EMAIL PROTECTED]> wrote:
> I'd like to see carets on by default as part of a major release -- say
> GCC 5.0. (First mention!!)
Whoa, you wish :-)
Honors go to Marc Espie here:
http://gcc.gnu.org/ml/gcc/2000-12/msg00636.html
But there've been several
> "Joseph" == Joseph S Myers <[EMAIL PROTECTED]> writes:
Joseph> (b) to print GCS-compliant ranges in text that IDEs can parse
Joseph> to highlight the relevant text in their editors
Joseph> Caret diagnostics are only one of the styles in which the
Joseph> accurate location information can be
On Thu, 14 Aug 2008, Robert Dewar wrote:
> BTW, I am all in favor of caret output, it's not the default in
> gnat, the default is more like the C default, but -gnatv gives
> output like:
And I'd hope we could keep things that way for both C and Ada, but make
similar modes to the Ada ones availab
2008/8/14 Robert Dewar <[EMAIL PROTECTED]>:
> Manuel López-Ibáñez wrote:
>
>> My proposal is to enable this while not in release mode (like we
>> enable checks and dump statistics and output from the optimizers), so
>> developers notice wrong locations and open a PR and maybe even fix
>> them. Then
2008/8/14 Joseph S. Myers <[EMAIL PROTECTED]>:
>
> The solution is producing accurate location ranges, which can be used (a)
> to print more accurate expressions within the text of diagnostics in the
> existing style, (b) to print GCS-compliant ranges in text that IDEs can
> parse to highlight the
Manuel López-Ibáñez wrote:
My proposal is to enable this while not in release mode (like we
enable checks and dump statistics and output from the optimizers), so
developers notice wrong locations and open a PR and maybe even fix
them. Then maybe let users or distributions configure the default a
2008/8/14 Robert Dewar <[EMAIL PROTECTED]>:
> Manuel López-Ibáñez wrote:
>>
>> 2008/8/14 Joseph S. Myers <[EMAIL PROTECTED]>:
>>>
>>> But in any case the default should be the default with no configure
>>> option, users liking it should find their makefiles work the same
>>> everywhere and users no
Joseph S. Myers wrote:
We certainly do change the *text* of messages to improve them (this
includes putting in more information that can fit within the existing
single-line format), and add new messages following the standard formats,
but I believe we should leave consumers able to rely on cer
2008/8/14 Aldy Hernandez <[EMAIL PROTECTED]>:
>
> I envision the caret diagnostics being disabled for only a short while--
> while we beat some sense into the column information. There's no point
> in attacking everything at once.
Then, I think we are talking past each other. To be crystal clear,
On Thu, 14 Aug 2008, Robert Dewar wrote:
> Manuel López-Ibáñez wrote:
> > 2008/8/14 Joseph S. Myers <[EMAIL PROTECTED]>:
> > > But in any case the default should be the default with no configure
> > > option, users liking it should find their makefiles work the same
> > > everywhere and users not
> Then we are not going to get correct locations ever. New users do not
> read the manual. Neither old users do. New functionality disabled by
> default will be lost for both. I am fairly sure that a significant
> percentage of GCC developers (not just users) do not know about
> -fdiagnostics-show-
On Thu, 14 Aug 2008, Manuel López-Ibáñez wrote:
> 2008/8/14 Joseph S. Myers <[EMAIL PROTECTED]>:
> >
> > But in any case the default should be the default with no configure
> > option, users liking it should find their makefiles work the same
> > everywhere and users not liking it can add the oppo
Manuel López-Ibáñez wrote:
2008/8/14 Joseph S. Myers <[EMAIL PROTECTED]>:
But in any case the default should be the default with no configure
option, users liking it should find their makefiles work the same
everywhere and users not liking it can add the opposite option.
Then we are not going
2008/8/14 Joseph S. Myers <[EMAIL PROTECTED]>:
>
> But in any case the default should be the default with no configure
> option, users liking it should find their makefiles work the same
> everywhere and users not liking it can add the opposite option.
Then we are not going to get correct location
On Thu, 14 Aug 2008, Manuel López-Ibáñez wrote:
> Even if the configure options do not control the compilation of the
> code, they should at least control the default. I think that, at least
No, whatever the default is there should definitely be no configure option
to control it. Configure opti
2008/8/14 Joseph S. Myers <[EMAIL PROTECTED]>:
> On Thu, 14 Aug 2008, Manuel López-Ibáñez wrote:
>
>> It is controlled by -fdiagnostics-show-caret. See the diff for gcc/opts.c.
>>
>> The configure options are meant to enable/disable all code related to
>> caret printing in a similar way as it was d
On Thu, 14 Aug 2008, Manuel López-Ibáñez wrote:
> It is controlled by -fdiagnostics-show-caret. See the diff for gcc/opts.c.
>
> The configure options are meant to enable/disable all code related to
> caret printing in a similar way as it was done with mapped locations.
> This was requested the f
2008/8/14 Joseph S. Myers <[EMAIL PROTECTED]>:
> On Thu, 14 Aug 2008, Manuel López-Ibáñez wrote:
>
>> You can see many examples of the caret output by configuring with
>> --enable-caret-diagnostics, then reverting the changes to
>> gcc/testsuite/lib/gcc.exp and running the testsuite. Check the outp
39 matches
Mail list logo
