On Tue, 2018-02-13 at 15:37 -0700, Martin Sebor wrote: > On 02/13/2018 01:59 PM, Manuel López-Ibáñez wrote: > > > > > > On 13 Feb 2018 5:58 pm, "Martin Sebor" <mse...@gmail.com > > <mailto:mse...@gmail.com>> wrote: > > > > > > I wanted to make the _n() functions like warning_n() more > > robust by letting them accept a tree argument (as well as > > offset_int and wide_int) in addition to HOST_WIDE_INT but > > I can't do it if they can't work with these types. > > > > > > There must be a tree-diagnostics.c where you can add those > > functions and > > then call the general diagnostic functions. Same for RTL. > > I don't see how to do that. > > Here's a sketch of what I tried to do: > > struct IntegerConverter > { > union { > tree t; > unsigned HOST_WIDE_INT hwi; > // buffer for offset_int, wide_int, etc. > } value; > > IntegerConverter (tree t) > { > value.t = t; > } > > IntegerConverter (unsigned HOST_WIDE_INT x) > { > value.x = x; > } > > ... > }; > > void error_n (int, const IntegerConverter &, const char*, ...); > ... > > With that, the call > > error_n (loc, t, "%E thing", "%E things", t); > > works when t is a tree, and the call to the same function > > error_n (loc, i, "%wu thing", "%wu things", i); > > also works when i is a HOST_WIDE_INT. I chose this approach > to avoid introducing additional overloads of the error_n() > functions.
Why can't you simply introduce a tree-diagnostic.h and tree- diagnostic.c and put overloads there? In diagnostic.c the various _n all use diagnostic_n_impl, which ultimately calls out to ngettext (singular_gmsgid, plural_gmsgid, n) so there would presumably be an analogous "diagnostic_n_hwi_impl" (or somesuch) function there to do the same thing. That would keep the tree stuff separated from the rest of the diagnostics subsystem. Or am I missing something? Hope this is constructive Dave > > Note that pretty-printer.c works in the same way. > > It works that way for arguments passed through the ellipsis. > I was trying to use tree (indirectly) in the signature of > the _n() functions and for that I need "tree.h" etc. in > diagnostic-core.h and be able to call functions from > the header in diagnostic-core.c. I suppose I could make > the calls indirectly somehow but I can't avoid including > GCC headers in diagnostic-core.h. > > Martin >