On 15/11/19 13:49 +0100, Jakub Jelinek wrote:
On Fri, Nov 15, 2019 at 12:35:22PM +0000, Jonathan Wakely wrote:
On 15/11/19 13:28 +0100, Jakub Jelinek wrote:
> On Thu, Nov 14, 2019 at 08:34:26PM +0100, Jakub Jelinek wrote:
> > The following WIP patch implements __builtin_source_location (),
> > which returns const void pointer to a std::source_location::__impl
> > struct that is required to contain __file, __function, __line and __column
> > fields, the first two with const char * type, the latter some integral type.
>
> Here is hopefully final version, with the hashing implemented,
> __file renamed to __file_name and __function to __function_name to match
> how the standard names the methods and with testsuite coverage.
The libstdc++ naming convention says the data members should be
_M_file_name, _M_line etc.
Since this is just a normal library type now, not defined by the
compiler, I think we should follow the library convention (sorry for
not noticing that sooner).
I guess it depends on what are the chances other compilers will implement
the same builtin, because doesn't say libc++ use __name rather than
_M_name convention?
Yes, that's what libc++ uses, but I get the impression Clang isn't
going to add this built-in anyway.
Yet another option would be for the builtin to accept either
_M_file_name or __file_name, could be handled by
const char *n = IDENTIFIER_POINTER (DECL_NAME (field));
if (strncmp (n, "_M_", 3) == 0)
n += 3;
else if (strncmp (n, "__", 2) == 0)
n += 2;
else
n = "";
and then do the comparisons without __ in the patch.
My inclination is YAGNI. At this point, a libc++ implementation that
would want to use __builtin_source_location when compiled with GCC is
hypothetical, and would already need various #if conditions around it.
BCCing libc++ maintainers in case they want to request that GCC's
built-in pre-emptively support a std::source_location::__impl type
that uses __ prefixes on its data members. For more context see
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01389.html and the rest
of the thread.
