> My point is that if the rest of the compiler extends diagnostics.c to
> handle caret and ranges and all other features, Ada would need carry
> all that around even if gnat has its own diagnostics machinery. But
> perhaps that is OK.
Certainly OK, what possible (noticeable) issue would you forese
Manuel López-Ibáñez wrote:
Again, my point is that even if GNAT has all these features already,
GNAT should be interested in this since it means moving stuff out of
libcpp which will allow to break that dependency. C/C++ could very
well implement caret diagnostics and everything else within libcp
2008/8/25 Paolo Bonzini <[EMAIL PROTECTED]>:
>
> As far as I could see, all the dependency stuff is in mkdeps.c; maybe it
> could use the line-map infrastructure more. Of course, in that case
> moving line-map.c out of libcpp would mean moving mkdeps.c too -- and
> not in gcc/, but rather in its o
Manuel López-Ibáñez wrote:
> 2008/8/25 Paolo Bonzini <[EMAIL PROTECTED]>:
Even if you do not use line-map.o, the middle-end does, so you still
have the duplication.
>>> Right, this is the only part that is indeed shared and for which Ada
>>> requires
>>> libcpp.
>> There are exactly 6 us
2008/8/25 Paolo Bonzini <[EMAIL PROTECTED]>:
>
>>> Even if you do not use line-map.o, the middle-end does, so you still
>>> have the duplication.
>>
>> Right, this is the only part that is indeed shared and for which Ada requires
>> libcpp.
>
> There are exactly 6 uses of linemap functions in libcp
2008/8/25 Arnaud Charlet <[EMAIL PROTECTED]>:
>> Even if you do not use line-map.o, the middle-end does, so you still
>> have the duplication.
>
> Right, this is the only part that is indeed shared and for which Ada requires
> libcpp.
My point is that if the rest of the compiler extends diagnostic
>> Even if you do not use line-map.o, the middle-end does, so you still
>> have the duplication.
>
> Right, this is the only part that is indeed shared and for which Ada requires
> libcpp.
There are exactly 6 uses of linemap functions in libcpp. They could be
replaced with a handful of function
> > Well, clearly, the preprocessor and handling of #include is very
> > C/C++ specific, and not used by Ada or Fortran.
>
> Both Ada and Fortran are linked with libcpp.a.
Sure, because as we've said, libcpp is not modular enough. Clearly Ada does not
need to link with A C preprocessor at all.
>
2008/8/20 Arnaud Charlet <[EMAIL PROTECTED]>:
>> Not just that, probably Fortran/Ada are already duplicating stuff that
>> is in libcpp or they are implementing their own version of stuff that
>> C/C++ are lacking (caret diagnostics? character encodings?).
>
> Well, clearly, the preprocessor and ha
Manuel López-Ibáñez wrote:
2008/8/20 Arnaud Charlet <[EMAIL PROTECTED]>:
If we want to implement re-opening files and reading strings given
locations, then opening/reading files should also be moved out of CCP
to its own module/namespace/object.
Agreed. Other modules may find these APIs very ha
> Not just that, probably Fortran/Ada are already duplicating stuff that
> is in libcpp or they are implementing their own version of stuff that
> C/C++ are lacking (caret diagnostics? character encodings?).
Well, clearly, the preprocessor and handling of #include is very
C/C++ specific, and not u
2008/8/20 Arnaud Charlet <[EMAIL PROTECTED]>:
>> If we want to implement re-opening files and reading strings given
>> locations, then opening/reading files should also be moved out of CCP
>> to its own module/namespace/object.
>
> Agreed. Other modules may find these APIs very handy.
> Currently m
> If we want to implement re-opening files and reading strings given
> locations, then opening/reading files should also be moved out of CCP
> to its own module/namespace/object.
Agreed. Other modules may find these APIs very handy.
Currently many features are only available very deep or hidden in
2008/8/20 Tom Tromey <[EMAIL PROTECTED]>:
>> "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes:
>
> Manuel> If I ever get the time, I would like to abstract our line-map
> Manuel> implementation within a "location_manager" object and API but
> Manuel> I don't think this conflicts direc
> "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes:
Manuel> If I ever get the time, I would like to abstract our line-map
Manuel> implementation within a "location_manager" object and API but
Manuel> I don't think this conflicts directly with your work.
I am curious to know how this
> Would your implementation also handle two locations for tokens that
> come from macro expansion?
macro expansion are tricky to handle as far as I could see, so currently
this is not handled. It's tricky because some locations are "real" in
the source, and some are "virtual" from the macro.
Cons
2008/8/20 Arnaud Charlet <[EMAIL PROTECTED]>:
>
> The way I did it, since I thought that adding a new location_t field in
> the expr struct would likely be a no-no (due to additional memory usage) is to
> use a hash table "on the side", and use macros (SET_EXPR_LOCATION2,
> GET_EXPR_LOCATION2) that
> Oh yes. Well, there is a lot of fine-tunning to do but I think that
> would be covered by A.1 and the binary_op expression would have at
> least two locations begin/end pointing to X and r. If we are able to
> print ({break;}), in the example I gave earlier, then we will be able
> to print nice r
> That is clear. Thanks. I personally would be perfectly happy if the
> compiler said
> bug.c:4.COLUMN: error: called object is not a function
> That is, fixing the compiler to includes parts of the source code in
> the error message itself is, for me, of considerably lower priority
> than fi
On Fri, 15 Aug 2008, Ian Lance Taylor wrote:
> Perhaps I misunderstand what you mean by recording the location in the
> preprocessed token stream. You evidently do not mean getting column
> numbers for the preprocessed code. You mean that when a preprocessor
> macro is expanded, we should record
2008/8/15 Ian Lance Taylor <[EMAIL PROTECTED]>:
>>
>> BTW, Clang takes into account both locations when printing diagnostics.
>
> Perhaps I misunderstand what you mean by recording the location in the
> preprocessed token stream. You evidently do not mean getting column
> numbers for the preproces
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
> 2008/8/15 Ian Lance Taylor <[EMAIL PROTECTED]>:
>> "Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
>>
>>> A) Printing the input expression instead of re-constructing it. As
>>>Joseph explained, this will fix the problems that Aldy mentioned
On Fri, 15 Aug 2008, Manuel López-Ibáñez wrote:
> 5) Handle locations during folding or avoid aggressive folding in
> the front-ends.
I plan to delay folding for C (beyond some folding for expressions of
constants) for 4.5, probably in October. (I do not plan to do anything
for C++, and
2008/8/15 Chris Lattner <[EMAIL PROTECTED]>:
>> D) Printing Ranges. This requires:
>>
>> *) Printing accurate column information. Similar to (B) above.
>>
>> *) A location(s) -> source strings interface and machinery. Similar
>> to (A.3) above.
>
> Ranges also require some way to get the end
D) Printing Ranges. This requires:
*) Printing accurate column information. Similar to (B) above.
*) A location(s) -> source strings interface and machinery. Similar
to (A.3) above.
Ranges also require some way to get the end of a token (in addition to
its beginning). For example,
2008/8/15 Ian Lance Taylor <[EMAIL PROTECTED]>:
> "Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
>
>> A) Printing the input expression instead of re-constructing it. As
>>Joseph explained, this will fix the problems that Aldy mentioned
>>(PR3544[123] and PR35742) and this requires:
>>
>>
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
> Let's try to focus on what needs to be done looking for specific
> features (or fixes) and how we could do it:
Thanks for writing this up.
> A) Printing the input expression instead of re-constructing it. As
>Joseph explained, this will fix
27 matches
Mail list logo
