This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [4.5] [RFC] Move line-map.* to its own library (libloc)


>>>>> "Joseph" == Joseph S Myers <joseph@codesourcery.com> writes:

Joseph> By giving a roadmap for your vision of the future of location
Joseph> handling you make it easier for other people to patch this
Joseph> code and implement parts of this vision.

I thought I'd address this a bit, from my POV of course.

My impression is that line-map is basically adequate for ordinary gcc
use.  The API is weird, but not fatally so.

There are a few ways we might consider changing it, though, that would
help out gcc projects or users:

* There was some talk about putting block information into locations.
  That may imply changing the encoding to make it suitable for this.

* If we recorded macro expansion information in a source_location, we
  could emit better diagnostics.  This may also be helpful to plugins
  and static analysis applications.

I don't have a concrete plan for implementing either of these.  The
bulk of my time right now is spent on gdb...

Joseph> [...] the existence of both source_location
Joseph> and location_t as typedefs for the same thing is an obvious
Joseph> incomplete transition and wart in the interface

I didn't bother with this since it seemed noisy and not very important
-- the current state is not all that confusing.  But, we could
certainly do it... aside from c-format.c and the ChangeLog, it is a
couple seconds of perl.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]