https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #19 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #14)
> As for std::experimental::source_location, could we change ABI of those?
Yes, we don't promise stability between major releases for the experimental
stuff (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #18 from Peter Dimov ---
I would use it like this: https://godbolt.org/z/1eqEx6678
#include
struct error_category
{
};
error_category const& system_category();
struct error_code
{
error_code( int v, error_category const& cat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #17 from Jakub Jelinek ---
You'd need a different builtin (so that you know the presence of the builtin
means the new behavior), ideally tell the builtin some way the type it should
construct objects in (as opposed to std::source_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #16 from Peter Dimov ---
(In reply to Jakub Jelinek from comment #14)
> But we haven't done that that way and how would headers know if the
> __builtin_source_location that is available is the old or new one?
The header could do
na
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #15 from Peter Dimov ---
(In reply to Jonathan Wakely from comment #13)
> It wouldn't work correctly in all cases, as Jakub points out, because
> std::source_location::current() is part of the magic.
>
> And I'm not convinced we wan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #14 from Jakub Jelinek ---
But we haven't done that that way and how would headers know if the
__builtin_source_location that is available is the old or new one?
As for std::experimental::source_location, could we change ABI of those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #13 from Jonathan Wakely ---
It wouldn't work correctly in all cases, as Jakub points out, because
std::source_location::current() is part of the magic.
And I'm not convinced we want/need to support those uses.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #12 from Jonathan Wakely ---
We could have added std::__source_location_impl as the type that the built-in
returns and used that instead of making it a private member of
std::source_location. That would also have allowed it to be use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #11 from Jakub Jelinek ---
That is not possible, because std::source_location::current() should be
consteval and it can't be in C++ < 20, and without consteval it will behave
significantly differently. Note, the C++ FE knows
std::so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #10 from Peter Dimov ---
(In reply to Jakub Jelinek from comment #9)
> That would be an aliasing violation.
> The artificial vars created by __builtin_source_location have the
> std::source_location::__impl type, so accessing those u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #9 from Jakub Jelinek ---
That would be an aliasing violation.
The artificial vars created by __builtin_source_location have the
std::source_location::__impl type, so accessing those using some other dynamic
type is invalid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #8 from Peter Dimov ---
(In reply to Jakub Jelinek from comment #6)
> Note, having the struct somewhere else isn't that useful unless you know
> exactly how its non-static data members are named and what they mean, so
> ideally a cla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #7 from Peter Dimov ---
(In reply to Jonathan Wakely from comment #5)
> Sure. It's just a question of whether we're trying to provide a general
> purpose extension available for users, or an internal helper for the
> std::lib. IIRC w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #6 from Jakub Jelinek ---
Note, having the struct somewhere else isn't that useful unless you know
exactly how its non-static data members are named and what they mean, so
ideally a class with accessor methods, which is what std::sou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #5 from Jonathan Wakely ---
Sure. It's just a question of whether we're trying to provide a general purpose
extension available for users, or an internal helper for the std::lib. IIRC we
explicitly decided we only cared about support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #4 from Peter Dimov ---
On the surface this looks not hard to fix - use ::__source_location_impl (or
std::__source_location_impl) instead of std::source_location:__impl as the
layout struct - but I'm not sure whether this would pose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #3 from Jonathan Wakely ---
That would be non-conforming though, because source_location isn't a reserved
name in C++17, so programs can use that as a (really dumb) macro name, which
would then break the header.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #2 from Peter Dimov ---
(In reply to Jakub Jelinek from comment #1)
> __builtin_source_location doesn't require -std=c++20, but indeed does
> require or some compatible definition of
> std::source_location::__impl class, and as it d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
19 matches
Mail list logo
