- User Since
- Jul 16 2012, 3:06 PM (378 w, 2 d)
Fri, Oct 11
I'm fine with incremental changes.
It would be nice to have a test case for a allocator that throws on move-assignment, though.
Thinking about this some more, I agree with your analysis about the move assignment throwing.
Thu, Oct 10
Nice use of __libcpp_is_constant_evaluated(), but how will that play for C++03?
This looks ok to me. If you're concerned about performance, you might want to split this into two routines, one for the case were the allocators are equal, and one for the case where they're not (and skip the whole allocator dance for the equal case.)
Mon, Oct 7
I'm wondering where you are seeing getting this codegen from.
A couple of things:
- Can you give your patches a better title? "Optimize copy constructor" is not very informative. Which copy constructor?
- What does this do it the dylib - where basic_string<char> and basic_string<wchar_t> are externally instantiated?
Thu, Oct 3
Thanks for doing this, Richard.
A few things:
- Needs tests (as you said)
- The config macro stuff is all wrong (we build that file from a template)
- Use __libcpp_is_constant_evaluated instead of __builtin_is_constant_evaluated because it doesn't have to be #ifdefed. (see r364873 and r364884)
- If we're in a consteval block, we shouldn't be testing for exceptions being disabled, right?
If the Android and FreeBSD folks are ok with this, I'm fine with it
Thu, Sep 26
This is unfortunate and unnecessary. In particular, this breaks two clang tests if clang is configured to use libcxx as the default C++ standard library.
Wed, Sep 25
Committed as revision 372896
Tue, Sep 24
this looks fine to me now (with a nit).
Mon, Sep 23
Sun, Sep 22
Sep 13 2019
Sep 12 2019
This has been landed, and the breakage has been fixed.
This looks fine to me; please update www/cxx2a_status.html when you commit.
Sep 11 2019
It would be nice to have a test (in test/libcxx) to check that these annotations are in the expected places.
With the comment change I suggested, I am fine with this.
zoecarver accepted this revision
@zoecarver is not an approver for libc++.
I'm not a big fan of duplicated code; but especially in this case, since in D62453 you edit the duplicated code to add a throw; but you have to do it twice - once in __parse_backref and once in the new code. Why is that preferable?
Sep 10 2019
Maybe I'm missing something, but I don't see any synchronization between two syncstreams wrapping the same stream.
A general comment about the tests: You've got a bunch of methods marked "noexcept", but nowhere to I see ASSERT_NOEXCEPT or ASSERT_NOT_NOEXCEPT in the tests to check that.
Sep 7 2019
LGTM with the one change I suggested.
I'm wondering if this has become complicated enough that we should define a _LIBCPP_C_HAS_NO_GETS config macro.
Sep 5 2019
Sep 4 2019
I see maintaining an explicit list of exports as an ongoing time sink - are you sure this is the the direction that we want to take?
Sep 3 2019
If you're going to do __add__lvalue_reference, __add_rvalue_reference, and __remove_reference, why not go all the way and add __is_reference, __is_lvalue_reference and __is_rvalue_reference?
Aug 26 2019
Aug 23 2019
The templates basic_streambuf<char> and basic_streambuf<wchar> are externally instantiated in the libc++.dylib.
Marking them as inline would remove them from the dylib, breaking any existing binaries that refer to them.
Aug 21 2019
This seems to work for me (pthreads and nothreads).
In general, I think we're playing "whack-a-mole' with this chunk of code, and I've become fairly unhappy with it.
Aug 20 2019
Committed as revision 369399.
This is an alternative to D66301
I put an alternate solution up as D66480
Aug 19 2019
Yes. Because then it would be in the global namespace.
Aug 16 2019
Aug 15 2019
Aug 14 2019
Committed as revision 368867. I made Louis' suggested change (reset --> __reset) but somehow that didn't make it into the commit. I will fix that.
Aug 13 2019
Aug 8 2019
Re-gen diff with more context. No other changes.
Committed as revision 368299
Aug 7 2019
Aug 6 2019
rotate and a bunch of other algorithms were made constexpr in P0202, adopted in ABQ.
Hubert - I'm not following what you're saying.
Where did error_code come from? As far as I can tell, your comment is the first mention of error_code in this conversation.
Aug 5 2019
More tests, also removed a couple tabs.
The __pow10 and __width routines are only called at compile-time; no run-time code at all.
We have a "power of 10" table in charconv, but I don't think that coupling <chrono> and <charconv> is worth the benefit of removing this small routine.
The good news is that the constructor of the singleton object in libc++ is under your control. It can be constructed whenever you choose, just by calling generic_category().
When a handle to an error_category singleton object is used during the termination phase of a program, the destruction of the error_category object may have occurred prior to execution of the current destructor or function registered with atexit, because the singleton object may have been constructed after the corresponding initialization or call to atexit.
Aug 3 2019
Jul 29 2019
@EricWF asked me:
Can you restate your concern over bypassing char_traits?
Jul 26 2019
Jul 24 2019
Jul 22 2019
Jul 18 2019
The first three removals are fine.
I don't remember why I put the last two in, but I guess I'm OK with them.
Jul 11 2019
Jul 10 2019
Jul 8 2019
None of these calls (__libcpp_tls_create, for instance) are templates, or marked as inline candidates.
Should they be in a source file, and baked into the dylib instead of a header file?
(like we do in support/win32/thread_win32.cpp, for example)