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
On Wed, Aug 13, 2008 at 2:16 PM, Joseph S. Myers
<[EMAIL PROTECTED]> wrote:
> On Wed, 13 Aug 2008, Aldy Hernandez wrote:
>
> I think it would certainly be reasonable to print for
> anything unsupported instead of broken diagnostics, and to reclassify all
> such bugs as wishlist requests for certai
On Wed, Aug 13, 2008 at 12:52 PM, Aldy Hernandez <[EMAIL PROTECTED]> wrote:
>
> It seems to me that the only approach here would be to provide caret
> diagnostics, because reconstructing the original sources from GENERIC
> seems like a loosing proposition.
Hi Aldy,
I agree with your analysis.
> * 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
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
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,
> 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
2008/8/14 Aldy Hernandez <[EMAIL PROTECTED]>:
>> There are various issues that would need to be addressed to have
>> decent caret diagnostics:
>
> Agreed. I think having caret diagnostics in place is a good first step,
> if only because it'll make debugging of column diagnostics easier.
> After th
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
> There are various issues that would need to be addressed to have
> decent caret diagnostics:
Agreed. I think having caret diagnostics in place is a good first step,
if only because it'll make debugging of column diagnostics easier.
After this, we can modify the testsuite machinery to test colum
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
On Wed, 13 Aug 2008, Aldy Hernandez wrote:
> 1. beginning/ending locations functionality as Joseph suggests.
Note that the GNU Coding Standards specify formats for diagnostics giving
a range of locations; when GCC tracks such a range, it should use those
formats (by default).
source-file-
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
2008/8/13 Tom Tromey <[EMAIL PROTECTED]>:
>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
>
> Tom> As far as I know nobody is actively working on any of this, though
> Tom> Mañuel and I talk about it sporadically.
>
> Crap, I misspelled his name while trying extra to get it right.
> Sorry ab
2008/8/14 Aldy Hernandez <[EMAIL PROTECTED]>:
>> Aldy> 1. beginning/ending locations functionality as Joseph suggests.
>> Aldy> 2. make sure the parsers pick the proper token/location.
>> Aldy> 3. error reporting machinery
>>
>> Aldy> How does this sound?
>>
>> It sounds good to me. #1 might be ha
2008/8/13 Aldy Hernandez <[EMAIL PROTECTED]>:
>
> 1. beginning/ending locations functionality as Joseph suggests.
> 2. make sure the parsers pick the proper token/location.
> 3. error reporting machinery
There are various issues that would need to be addressed to have
decent caret diagnostics:
1)
> Aldy> 1. beginning/ending locations functionality as Joseph suggests.
> Aldy> 2. make sure the parsers pick the proper token/location.
> Aldy> 3. error reporting machinery
>
> Aldy> How does this sound?
>
> It sounds good to me. #1 might be hard, I have not looked into it.
Well, we can alwa
2008/8/14 Tom Tromey <[EMAIL PROTECTED]>:
>
> ISTR Manuel having a patch for caret diagnostic output... ?
>
I was planning to submit it this week to consider it for GCC 4.4
(disabled by default). I am still testing it. Bootstrap and regression
testing with --enable-languages=all,ada,obj-c++ is ver
On Aug 13, 2008, at 12:16 PM, Joseph S. Myers wrote:
On Wed, 13 Aug 2008, Aldy Hernandez wrote:
It seems to me that the only approach here would be to provide caret
diagnostics, because reconstructing the original sources from GENERIC
seems like a loosing proposition.
In some cases the only
Tom> I suspect that there's some work fixing optimization passes. I have
Tom> not looked but I would not be surprised if some of them pick locations
Tom> poorly when rearranging things.
Aldy> But this has nothing to do with error messages. I mean, not initially.
Yeah, it is somewhat indirect.
> If you're interested in working on this, I think one way to do it
> would be to start with a parser and make sure it always picks the
> proper token from which to extract a location. This is a reasonable
> amount of work, and unfortunately much of it would have to be complete
> before we could e
Tom Tromey wrote:
Aldy> Are there any thoughts on this (the PRs, the caret diagnostics, plan of
Aldy> attack, etc?).
Caret diagnostics do seem like the way to go.
Yes, I've advocated that for years. People consistently tell me that
EDG's diagnostics are superior to GCC, in part because of E
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> As far as I know nobody is actively working on any of this, though
Tom> Mañuel and I talk about it sporadically.
Crap, I misspelled his name while trying extra to get it right.
Sorry about that.
Tom
> "Aldy" == Aldy Hernandez <[EMAIL PROTECTED]> writes:
Aldy> The error here is currently:
Aldy> #'goto_expr' not supported by pp_c_expression#'bug.c: In function 'foo':
Aldy> bug.c:4: error: called object is not a function
Aldy> But, is this slew of work even worth it? I for one think t
On Wed, 13 Aug 2008, Aldy Hernandez wrote:
> It seems to me that the only approach here would be to provide caret
> diagnostics, because reconstructing the original sources from GENERIC
> seems like a loosing proposition.
In some cases the only useful place to find the expression is in the
pre
Hi folks.
I'm looking at 3544[123] and 35742, which are all related to
pp_c_expression not handling complex expressions, so we can't display
correct error messages for statement expressions, etc:
({break;})()
The error here is currently:
#'goto_expr' not supported by pp_c_expression#'
30 matches
Mail list logo
