- User Since
- Feb 11 2015, 3:26 PM (380 w, 2 d)
Rebase onto main.
This needs a release note to mention that we removed some includes of <functional>, since this may break users. Other than that, LGTM.
Oops, but the CI is failing due to a circular dependency.
As much as I don't like having ugly macros like _LIBCPP_ALIGNOF, I dislike even more defining a keyword as a macro, especially in the library:
- If the compiler ever wants to support alignof as an extension in C++03, we'll need coordination between the library and the compiler.
- This is technically a breaking change for C++03 users because they are allowed to use alignof as a name, and we're not allowed to define identifiers outside of our namespace. Concretely, I do suspect this may break some C-first codebases that try to be clever.
- This breaks the symmetry between _LIBCPP_PREFERRED_ALIGNOF and _LIBCPP_ALIGNOF.
- We have experience that defining compiler stuff in the library isn't a great idea -- for example, we've yet to figure out a way to get rid of our char16_t typedef, and it's not even a macro.
Thu, May 26
Rebase. I will ship this if CI passes, since it's effectively non-breaking. It's just a heads up.
libc++ CI passed.
Remove parent revision and rebase to trigger CI properly.
Remove the -fcoroutines-ts Lit feature
Rebase onto main
@vvereschaka I was going through the CMake caches looking for variables that implied usage of the legacy testing configuration system, and clang/cmake/caches/CrossWinToARMLinux.cmake seems to contain several of those. Just making sure you don't miss this.
I don't think we have any tests that these algorithms are actually function objects that can be e.g. passed as a function argument. Didn't we have a test file that checked all algorithms and views for being niebloids? If so, let's update it. If not, let's create one.
Wed, May 25
We've started having several internal user complaints because their system headers are suddenly triggering a warning for using <stdbool.h>. This seems to be caused by the fact that #warning is surfaced to users even when the #warning is present in a system header (which makes sense, because otherwise there would be no way to issue a #warning from a system header). This ends up causing problems because users have no way to suppress the warning in the system headers they use without also disabling deprecation warnings in their own code. Is this intended? Instead, it seems to me like what we'd want is some way to mark the header as deprecated such that Clang will not flag uses of <stdbool.h> from within system headers, but will flag them from user code. This would be consistent with how the deprecated attributes work for classes and functions.
Let's rebase this, apply my comments and land this if CI is green.
Fix broken sym_diff.
Fix bootstrapping build CI failure.
Tue, May 24
LGTM with comments applied and CI passing.
Rebase onto main -- I'm not seeing the CI issue locally, maybe rebasing will fix it?
Fix CI with bootstrapping build -- hopefully this doesn't break another job.
Try to fix CI.
Hopefully fix CI.
Mon, May 23
LGTM with tests. We have several ADL proofing tests, see for example libcxx/test/std/strings/basic.string/string.modifiers/robust_against_adl.pass.cpp.
Ship it. Please ping me when this is committed and I will cherry-pick to the LLVM 14 release branch.
LGTM, and it would be nice to do the cleanup suggested in https://reviews.llvm.org/D124755#inline-1207727.
I don't understand this review's title in relationship with the diff. Is it an error?
Fri, May 20
The only CI failure is a nit I just fixed, so shipping this.
c218fd3d7d3764eb123c8429bbcd33bacfe2e633 added libcxxabi/test/native/AArch64/ra_sign_state.pass.cpp -- was that intended, or should it have been added to libunwind/test/[...]? It also started failing in the CI in the -fno-exceptions configuration -- I think it is just missing a XFAIL so I'll add it, but please investigate whether the file needs to be moved (I think it does). If so, please make sure to open a code review for that change since it will cause our pre-commit CI to run, and please don't commit the change until it is green :-).
Thu, May 19
Address some comments (but not @phosek's yet).
Try to handle Windows hosts.
Rebase and try to fix CI.
Fix CI issues.