Details
- Reviewers
ldionne Mordante var-const huixie90 - Group Reviewers
Restricted Project Restricted Project - Commits
- rGd5e26775d089: [libc++] Granularize the rest of memory
rG30adaa730c47: [libc++] Granularize the rest of memory
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
LGTM, thanks for the cleanup! I would also remove the "and remove transitive includes" from the commit message, since it does not really remove any user visible transitive includes.
libcxx/include/__memory/destruct_n.h | ||
---|---|---|
24 | Side comment -- in a separate patch, let's investigate this. There really shouldn't be any logic in here, we should just call std::destroy_n. That should handle trivially destructible types and all. This seems to be used as a RAII cleanup in some algorithms. | |
libcxx/include/algorithm | ||
1900–1901 | I think this needs to be rebased, since I would expect a check for && C++ <= 20 here (or something like that). | |
libcxx/include/memory | ||
880–884 | && C++ <= 20? |
Hi, I'm pretty sure we see a breakage in the llvm-libc++-static.cfg.in :: libcxx/transitive_includes.sh.cpp test due to this patch in Fuchsia's Clang CI.
Is it possible to take a look? I don't see an obvious reason we see this on x64 linux, but not other platforms, so maybe there's just something missed in the preprocessor directives?
The failing bot can be found here: https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8804103688804713457/overview
Reverting, breaks:
https://lab.llvm.org/buildbot/#/builders/238/builds/76
https://lab.llvm.org/buildbot/#/builders/237/builds/67
https://lab.llvm.org/buildbot/#/builders/236/builds/162
https://lab.llvm.org/buildbot/#/builders/239/builds/105
https://lab.llvm.org/buildbot/#/builders/5/builds/27199
https://lab.llvm.org/buildbot/#/builders/85/builds/10437
https://lab.llvm.org/buildbot/#/builders/74/builds/13281
Side comment -- in a separate patch, let's investigate this. There really shouldn't be any logic in here, we should just call std::destroy_n. That should handle trivially destructible types and all.
This seems to be used as a RAII cleanup in some algorithms.