EricWF marked 5 inline comments as done.
EricWF added a comment.
In https://reviews.llvm.org/D37035#1116102, @kunitoki wrote:
> Any news on the status of this ? Would be really nice to have it in.
I think this patch is ready to go; but there is more work to be done, as a
separate patch, to support `std::source_location` in a better manner as
suggested by @rsmith in the inline comments.
================
Comment at: test/SemaCXX/source_location.cpp:10-35
+struct source_location {
+private:
+ unsigned int __m_line = 0;
+ unsigned int __m_col = 0;
+ const char *__m_file = nullptr;
+ const char *__m_func = nullptr;
+public:
----------------
rsmith wrote:
> This seems suboptimal. It would seem better for the compiler to generate a
> global containing the relevant data and to represent a `source_location` as a
> pointer to such a value. We should also try to minimize the number of
> relocations necessary to build a `source_location` object, since such
> constructions are likely to be extremely common in some codebases. We should
> also keep in mind that we're likely to want to add fields to
> `source_location` in future, so designing it in a way that avoids an ABI
> break for such cases would be preferable.
>
> How long has GCC supported this?
@rsmith, I agree with your design for `std::source_location`. However, would it
be acceptable for now to commit this patch as only the builtins, since we need
those for GCC compatibility anyway?
Then the changes for something like `__builtin_source_location()` can be added
afterwards?
https://reviews.llvm.org/D37035
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
