- User Since
- Jun 26 2014, 12:44 PM (301 w, 6 d)
I assume this is a behavioral change? Why are there no new tests?
Committed as 601f7631827ae6ac08117a282c83a62b67dedf48
I have some concerns with how we harden our concepts,
but these can be addressed in follow up commits.
Sat, Apr 4
Fri, Apr 3
I like tests.
Assuming all of them pass;: LGTM.
Tue, Mar 31
Thu, Mar 26
I don't necessarily agree.
Lets not start writing tests like this.
Tue, Mar 24
We don't implement non-standard extensions in libc++.
Only when this trait is proposed for standardization can we consider adding it to the library
Mon, Mar 23
I would like us to be even more aggressive bumping our compiler support,
but that's a conversation for another time.
Sat, Mar 21
Why do we need separate options for each project?
I think that's the wrong direction.
Wed, Mar 18
These tests still require that "arbitrary" warning flag be enabled.
I'm not sure I love this, but I'm OK demoting warnings to errors in the XFAIL tests.
Mon, Mar 16
Sat, Mar 14
Fri, Mar 13
Could we add a .fail.cpp test that ensures when _LIBCPP_HAS_NO_FGETPOS is defined we don't actually have it?
Some of the changes in this patch are not correct. Please revert them in a follow up commit.
Wed, Mar 11
I think there is a bug in the paper, but I think the return type should be difference_type not size_type.
The paper says the return value is equivalent to:
LGTM other than the lack of tests.
Does this really need concepts?
Could you please upload this diff with more context?
Is this just a clean move, or is the class definition changed as well?
I can't tell with all the linter warnings in the way.
Your good to commit.
- This check should suggest fixes. It knows what function is actually being resolved, and it has enough information to create a minimally qualified name that resolves it.
- This check should ignore hidden friends, since their entire purpose is to be called via ADL.
- This check should allow whitelisting namespaces that opt-out of ADL into their namespace. This makes it much easier to roll out the clang-tidy incrementally.
I'll be picking this up seriously this week.
I'm currently getting an internal version of this clang-tidy reviewed,
and my plan was to submit it upstream after because I didn't see this
patch until now (bad email filters).
I've already stated my disapproval of this patch. Libc++ has never and will never provide nor value C++03 conformance.
Moving backwards to C++03 is inconsistent with the libraries general direction.
Why are we declaring this function at all?
Why was this file ever getting built as plain C anyway?
All of the libc++abi source files that use it should be C++.
Mar 9 2020
Abandoning. We went in another direction.
Mar 4 2020
This diff is incorrect, but I see it contains the fix to the previous failures. So it LGTM assuming you apply the correct diff.
I would rather see a patch that only removes the removed interfaces, and doesn't do all the additional cleanup you've done.
Mar 3 2020
Mar 1 2020
LGTM once all of the inline comments are addressed.
Feb 28 2020
Feb 27 2020
I'm find requiring C++17 to build the dylib, but I'm not sure everyone is?
LGTM after addressing @ldionne's comment about other assign methods that might benefit from this.
Feb 26 2020
Can you try simply marking the test with // FLAKY_TEST.?
@mvels Can you look over this diff?
@ldionne Since this has the possibility of breaking existing users of std::max_align_t, can you test this against your c++03 codebases?
Feb 24 2020
Feb 23 2020
This patch should contain the changes to the unstable extern template list.
Feb 19 2020
This seems wrong to me. Discarding value names is the default and has been forever in non-assert builds.
Why is this not a bug in w/e is handling the IR?
My personal preference is to not split the lists, my rational is:
Feb 15 2020
Feb 14 2020
Feb 12 2020
Can we assume that all supported Apple platforms have clock_gettime now? (It was added in 10.12)
I'm not sure why CLOCK_MONOTONIC_RAW wasn't used originally, but that appears to be the correct approach.
Feb 10 2020
LGTM other than the inline comments.
I'll take a second pass at this once they're addressed.
Jan 31 2020
Committed as 0c5102bd939131b27105b74e73fc25b90207ef36.
Jan 29 2020
Committed as: b4c911eccc4cccdd8cb536dc003ff9d4eb3bdc70
LGTM. But I would also like the opinion of Sterling, since they work in this code most often.