On 14/11/19 23:39 +0100, Jakub Jelinek wrote:
On Thu, Nov 14, 2019 at 10:15:21PM +0000, Jonathan Wakely wrote:
> namespace std {
> struct source_location {
> struct __impl {
Will this work if the library type is actually in an inline namespace,
such as std::__8::source_location::__impl (as for
--enable-symvers=gnu-versioned-namespace) or
std::__v1::source_location::__impl (as it probably would be in
libc++).
If I'm reading the patch correctly, it would work fine, because
qualified lookup for std::source_location would find that name even if
it's really in some inline namespace.
I'd say so, but the unfinished testsuite coverage would need to cover it of
course.
> const char *__file;
> const char *__function;
> unsigned int __line, __column;
> };
> const void *__ptr;
If the magic type the compiler generates is declared in the header,
then this member might as well be 'const __impl*'.
Yes, with the static_cast on the __builtin_source_location ()
result sure. I can't easily make it return const std::source_location::__impl*
though, because the initialization of the builtins happens early, before
<source_location> is parsed.
And as it is a nested class, I think I can't predeclare it in the compiler.
If it would be std::__source_location_impl instead of
std::source_location::__impl, perhaps I could pretend there is
namespace std { struct __source_location_impl; }
but I bet that wouldn't work well with the inline namespaces.
So, is const void * return from the builtin ok?
Yes, that seems fine. The library can just do the cast once and store
the result, instead of casting it on every use.
