Manuel López-Ibáñez wrote:
That is a good point. The underlying mechanism can be fine tuned
later. What would be the main problems to get caret diagnostics in
trunk? The most common issue is probably bad locations but I don't see
that as a major problem. On the contrary, the only reliable way to
On Wed, Mar 12, 2008 at 11:00 PM, Chris Lattner <[EMAIL PROTECTED]> wrote:
>
>
> On Mar 12, 2008, at 5:07 PM, Manuel López-Ibáñez wrote:
>
> > On 08/03/2008, Chris Lattner <[EMAIL PROTECTED]> wrote:
> >>
> >> clang points into the original input buffer that was lexed from.
> >> This
> >> requ
On Wed, Mar 12, 2008 at 7:00 PM, Manuel López-Ibáñez
<[EMAIL PROTECTED]> wrote:
> On 07/03/2008, Tom Tromey <[EMAIL PROTECTED]> wrote:
> > > "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes:
>
> > Manuel> The third approach would be to store an offset and when
> > Manuel> generati
On 08 Mar 2008 15:39:20 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote:
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
>
> >Another approach would be to only use the carets for parse errors,
> >which is where they are the most helpful.
>
> And preprocessor if possible
Yes, definitely.
On Fri, Mar 7, 2008 at 9:06 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Tom Tromey <[EMAIL PROTECTED]> writes:
>
> > Ian suggested that we delete this information after the FE is
> > finished. This makes sense, I think, from a memory-saving
> > perspective. But, that means we will get di
On Fri, Mar 7, 2008 at 11:53 AM, Richard Guenther
<[EMAIL PROTECTED]> wrote:
> On Fri, Mar 7, 2008 at 4:54 PM, Tom Tromey <[EMAIL PROTECTED]> wrote:
> > > "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes:
> >
> > Manuel> Here is a patch that give us caret diagnostics in C/C++.
>
On Fri, Mar 7, 2008 at 10:54 AM, Tom Tromey <[EMAIL PROTECTED]> wrote:
> > "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes:
>
> Manuel> Here is a patch that give us caret diagnostics in C/C++.
>
> Nice.
>
> Manuel> The third approach would be to store an offset and when
> Manuel>
On Mar 13, 2008, at 4:58 PM, Manuel López-Ibáñez wrote:
On 13/03/2008, Tom Tromey <[EMAIL PROTECTED]> wrote:
How about -fshow-caret instead of -fdiagnostics-show-caret?
(By analogy with -fshow-column.)
Manuel> Well, we have -fdiagnostics-show-option and
Manuel> -fdiagnostics-show-location.
On 13/03/2008, Tom Tromey <[EMAIL PROTECTED]> wrote:
>
> >> How about -fshow-caret instead of -fdiagnostics-show-caret?
> >> (By analogy with -fshow-column.)
>
> Manuel> Well, we have -fdiagnostics-show-option and
> Manuel> -fdiagnostics-show-location. So 2 versus 1. ;-) That said, I would
> Ma
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
> Anyway, I think we moved slightly off topic here. Getting the
> locations right is in general a much complex task than simply
> providing caret diagnostics that show whatever location we happen to
> have at hand.
But let's start with what we hav
On 13/03/2008, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 13, 2008 at 02:39:25PM -0700, Chris Lattner wrote:
>
> In the case of an unitialized variable, accurate warnings require good
> dataflow analysis that can handle correlated variables; something like
> gated SSA might be needed to pr
On Thu, Mar 13, 2008 at 02:39:25PM -0700, Chris Lattner wrote:
> On Mar 13, 2008, at 11:37 AM, Ian Lance Taylor wrote:
> > As you know the optimizers can pull together information
> >from all over the place. The actual warning can be issued for code
> >which looks very different from anything the
Chris Lattner <[EMAIL PROTECTED]> writes:
> On Mar 13, 2008, at 11:37 AM, Ian Lance Taylor wrote:
>> As you know the optimizers can pull together information
>> from all over the place. The actual warning can be issued for code
>> which looks very different from anything the user actually wrote.
On Mar 13, 2008, at 11:37 AM, Ian Lance Taylor wrote:
As you know the optimizers can pull together information
from all over the place. The actual warning can be issued for code
which looks very different from anything the user actually wrote.
Translating back to the problem in the user code ca
On 13/03/2008, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Tom Tromey <[EMAIL PROTECTED]> writes:
>
>
> > I'm not certain that this is the tradeoff I prefer, but I haven't
> > exactly done a survey of what diagnostics are emitted where. My
> > general worry is that these more distant (from the
Tom Tromey <[EMAIL PROTECTED]> writes:
> I'm not certain that this is the tradeoff I prefer, but I haven't
> exactly done a survey of what diagnostics are emitted where. My
> general worry is that these more distant (from the FE) diagnostics
> will also be the ones where having good location info
> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes:
>> Why? Isn't the operator available at that point?
Ian> The location information, if present, is technically available, but it
Ian> would require some surgery to actually get it.
I think the high-level decision to be made here is wheth
> "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes:
>> I tend to favor this, provided that the performance is not too awful.
>> But maybe this is painful due to iconv translation?
Manuel> How should a file be properly opened within GCC? I find the
Manuel> code in libcpp/files.c pret
On Mar 12, 2008, at 11:21 PM, Manuel López-Ibáñez wrote:
On 13/03/2008, Chris Lattner <[EMAIL PROTECTED]> wrote:
There is no right answer, and this topic has been the subject of much
debate on the GCC list in the past. I really don't care to debate
the
merits of one approach vs the other wit
On 13/03/2008, Chris Lattner <[EMAIL PROTECTED]> wrote:
>
> There is no right answer, and this topic has been the subject of much
> debate on the GCC list in the past. I really don't care to debate the
> merits of one approach vs the other with you, I just answered your
> question about what cl
On Mar 12, 2008, at 9:49 PM, Manuel López-Ibáñez wrote:
The clang front-end generates these warnings. This means that the
set
of warnings produced by the compiler doesn't change as the optimizer
evolves, are generally less mystifying to the user, and have perfect
location info as a side effect
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
>> >> Another approach would be to only use the carets for parse errors,
>> >> which is where they are the most helpful. For a middle-end error like
>> >> "assuming signed overflow does not occur when simplifying
>> >> multiplication" a ca
On 13/03/2008, Chris Lattner <[EMAIL PROTECTED]> wrote:
>
> On Mar 12, 2008, at 5:07 PM, Manuel López-Ibáñez wrote:
>
> > On 08/03/2008, Chris Lattner <[EMAIL PROTECTED]> wrote:
> >>
> >> clang points into the original input buffer that was lexed from.
> >> This
> >> requires keeping the orig
On Mar 12, 2008, at 5:07 PM, Manuel López-Ibáñez wrote:
On 08/03/2008, Chris Lattner <[EMAIL PROTECTED]> wrote:
clang points into the original input buffer that was lexed from.
This
requires keeping the original files mapped into the address space of
the compiler. However, clang only pro
On 13/03/2008, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> "Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
>
>
> > On 08/03/2008, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> >>
> >> Another approach would be to only use the carets for parse errors,
> >> which is where they are the most h
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
> On 08/03/2008, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>>
>> Another approach would be to only use the carets for parse errors,
>> which is where they are the most helpful. For a middle-end error like
>> "assuming signed overflow does not
On 08/03/2008, Tom Tromey <[EMAIL PROTECTED]> wrote:
>
> Perhaps I was mistaken to state an implementation preference this
> early, anyway. It would be fine by me to have an implementation that
> works in any reasonable way. If the "don't free" approach proves too
> costly, with sane API desi
On 08/03/2008, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> Adding support for releasing large buffers from memory and either
> seeking or not displaying carrets if it turns out to be important on the
> top of the in-memory implementation seems straighforward: the line
> location would be anyway so
On 08/03/2008, Chris Lattner <[EMAIL PROTECTED]> wrote:
>
> clang points into the original input buffer that was lexed from. This
> requires keeping the original files mapped into the address space of
> the compiler. However, clang only produces diagnostics from the front-
> end, not from the
On 08/03/2008, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> Another approach would be to only use the carets for parse errors,
> which is where they are the most helpful. For a middle-end error like
> "assuming signed overflow does not occur when simplifying
> multiplication" a caret pointe
On 07/03/2008, Tom Tromey <[EMAIL PROTECTED]> wrote:
> > "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes:
> Manuel> The third approach would be to store an offset and when
> Manuel> generating diagnostics, reopen the file, fseek to the offset
> Manuel> and print that line.
>
> I
> "Andi" == Andi Kleen <[EMAIL PROTECTED]> writes:
Andi> [also sometimes I would love to have an option in gcc to just
Andi> display the preprocessed input when something bad happens inside
Andi> a macro. I usually do that from hand using gcc -E, but it would be cool
Andi> if the compiler coul
Ian> For a middle-end error like
Ian> "assuming signed overflow does not occur when simplifying
Ian> multiplication" a caret pointer might be more misleading than
Ian> otherwise, as one thing we know for sure is that it would not point at
Ian> a multiplication operator.
Chris> An important class o
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
>
> >Another approach would be to only use the carets for parse errors,
> >which is where they are the most helpful.
>
> And preprocessor if possible
>
> [also sometimes I would love to have an option in gcc to just
> display the preprocessed inpu
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
>Another approach would be to only use the carets for parse errors,
>which is where they are the most helpful.
And preprocessor if possible
[also sometimes I would love to have an option in gcc to just
display the preprocessed input when something b
On Mar 7, 2008, at 6:06 PM, Ian Lance Taylor wrote:
Tom Tromey <[EMAIL PROTECTED]> writes:
Ian suggested that we delete this information after the FE is
finished. This makes sense, I think, from a memory-saving
perspective. But, that means we will get different kinds of error
output dependi
Tom Tromey <[EMAIL PROTECTED]> writes:
> Ian suggested that we delete this information after the FE is
> finished. This makes sense, I think, from a memory-saving
> perspective. But, that means we will get different kinds of error
> output depending on when a diagnostic is emitted, which I think
On Fri, Mar 7, 2008 at 4:54 PM, Tom Tromey <[EMAIL PROTECTED]> wrote:
> > "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes:
>
> Manuel> Here is a patch that give us caret diagnostics in C/C++.
>
> Nice.
>
> Manuel> The third approach would be to store an offset and when
> Manuel>
> "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes:
Manuel> Here is a patch that give us caret diagnostics in C/C++.
Nice.
Manuel> The third approach would be to store an offset and when
Manuel> generating diagnostics, reopen the file, fseek to the offset
Manuel> and print that lin
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
> Here is a patch that give us caret diagnostics in C/C++. There a lot
> of things that can be improved but because I wanted to get some
> feedback with my current approach.
>
> Basically, I store a pointer linebuf in the line_map structure to a
>
40 matches
Mail list logo
