On Wed, 2016-07-27 at 23:41 +0100, Manuel López-Ibáñez wrote: > On 27 July 2016 at 15:30, David Malcolm <dmalc...@redhat.com> wrote: > > > Perhaps it could live for now in c-format.c, since it is the only > > > place using it? > > > > Martin Sebor [CC-ed] wants to use it from the middle-end: > > https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01088.html > > so it's unclear to me that c-format.c would be a better location. > > Fine. He will have to figure out how to get a cpp_reader from the > middle-end, though.
It seems to me that on-demand reconstruction of source locations for STRING_CST nodes is inherently frontend-specific: unless we have the frontend record the information in some fe-independent way (which I assume we *don't* want to do, for space-efficiency), we need to be able to effectively re-run part of the frontend. So maybe this needs to be a langhook; the c-family can use the global cpp_reader * there, and everything else can return a "not supported" code if a diagnostic requests substring location information (and the diagnostic needs to be able to cope with that). > > There are various places it could live; but getting it working took > > a > > lot of effort to achieve - the currently proposed mixture of > > libcpp, > > input.c and c-format.c for the locations of the various pieces > > works > > (for example, auto_vec isn't available in libcpp). > > I don't doubt it. I tried to do something similar in the past and I > failed, this is why I ended up with the poor approximation that was > in > place until now. This is a significant step forward. Thanks (for the current implementation, and for the kind words). > Is libcpp still C? When would be the time to move it to C++ already > and start using common utilities? libcpp is very much C++: I converted the linemap types to use inheritance as part of gcc 6 (and it helped a lot when implementing the range-tracking stuff). > Also, moving vec.h, sbitmap, etc to their own directory/library so > that they can be used by other parts of the compiler (hey! maybe even > by other parts of the toolchain?) is desirable. Richard has said in > the past that he supports such moves. Did I understand correctly > Richard? FWIW, I'd want the selftest framework there too; part of the reason things are in input.c rather than libcpp in the current patch is that selftests aren't yet available from libcpp (and reworking that seems orthogonal). > > Given that both Martin and I have candidate patches that are > > touching > > the same area, I'd prefer to focus on getting this code in to > > trunk, > > rather than rewrite it out-of-tree, so that we can at least have > > the > > improvement to location-handling for Wformat. Once the code is in > > the > > tree, it should be easier to figure out how to access it from the > > middle-end. > > Sure, I think this version is fine. I'm a big proponent of > step-by-step, even if the steps are only approximations to the > optimal > solution :) > It may be enough to motivate someone else more capable to improve > over > my poor approximations ;-) :) > > > [*] In an ideal world, we would have a language-agnostic > > > diagnostics > > > library > > > that would include line-map and that would be used by libcpp and > > > the > > > rest of > > > GCC, so that we can remove all the error-routines in libcpp and > > > the > > > awkward > > > glue code that ties it into diagnostics.c., > > > > Agreed, though that may have to wait until gcc 8 at this point. > > (Given that the proposed diagnostics library would use line maps, > > and > > would be used by libcpp, would it make sense to move the > > diagnostics > > into libcpp itself? Diagnostics would seem to be intimately > > related to > > location-tracking) > > I don't think so. There is nothing in diagnostic.* pretty-print.* > input.* line-map.* that requires libcpp (and only two mentions of > tree > that could be easily abstracted out). This was a deliberate design > goal of Gabriel and followed by most of us later working on > diagnostics. Of course, cpp may make use of the new library, but also > other parts of the toolchain (GAS?). The main obstacle I faced when > trying to do this move was the build machinery to make both libcpp > and > gcc build and statically link with this new library. > > Once that move is done, the main abstraction challenge to remove the > glue is that libcpp has its own flags for options and diagnostics > that > are independent from those of gcc (see c_cpp_error in c-common.c). It > would be great if libcpp used the common flags, but then one would > have to figure out a way to reorder things so that the diagnostic > library, libcpp and gcc can use (or avoid being dependent on) the > same > flags. Thanks. Dave
