[C++ PATCH] __builtin_source_location ()

[Jonathan Wakely]

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.