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?
Jakub
