Currently, there are bugs in Clang's intrinsics for type traits when
handling Objective-C++ id (e.g. in add_pointer). As a temporary
workaround, don't use these intrinsics in the Objective-C++ mode.
Details
- Reviewers
ldionne - Group Reviewers
Restricted Project - Commits
- rG87cf39aa349b: [libc++] Temporarily not use compiler intrinsics for some type traits in…
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
libcxx/include/__config | ||
---|---|---|
1265 | You'll need to clang-format this bit | |
1265 | Let's rename this to e.g. _LIBCPP_WORKAROUND_OBJCXX_COMPILER_INTRINSICS -- this is going to be really short lived until Clang is fixed. | |
libcxx/include/__type_traits/remove_volatile.h | ||
20 ↗ | (On Diff #501972) | All type traits that work fine with the intrinsics should keep using the intrinsics IMO. I think we only need to carve out __remove_pointer and` __add_pointer` for now. |
libcxx/test/std/utilities/meta/meta.trans/objc_support.pass.mm | ||
66 | ||
66–67 | We should also test that !is_same<remove_ptr<id>::type, id>. Otherwise, people could get ambiguous overloads (for instance). | |
68 | Let's also add a test like this: static_assert(std::is_same<std::add_pointer<std::remove_pointer<id>::type>::type, id>::value, ""); static_assert(std::is_same<std::remove_pointer<std::add_pointer<id>::type>::type, id>::value, ""); // this one is kinda paranoid, but just to be sure |
libcxx/include/__config | ||
---|---|---|
1262 | FWIW I'd just drop the name from TODOs. If you want to know who wrote it you can just look at the git blame, so I don't really see an upside. They will just get out of date as people stop working on libc++. (We still have a few TODO(EricWF) in the code base and I have the feeling he won't resolve them.) | |
libcxx/test/std/utilities/meta/meta.trans/objc_support.pass.mm | ||
101–103 | Maybe make this a .compile.pass.mm instead? Or do we not have that? |
libcxx/include/__config | ||
---|---|---|
1262 | Personally, I find it useful. "TODO(name)" just means "'name' is the best person to ask about this issue", not "'name' is the person who will necessarily fix this issue". It's true that you can find it via blame, but a) it saves a context switch; and b) it's robust to copy-pasting, moving code between files, etc., all at essentially no cost. I find TODO(EricWF) useful regardless of whether Eric will work on those issues or not. | |
libcxx/test/std/utilities/meta/meta.trans/objc_support.pass.mm | ||
101–103 | It doesn't work -- the linker complains about missing _main. |
FWIW I'd just drop the name from TODOs. If you want to know who wrote it you can just look at the git blame, so I don't really see an upside. They will just get out of date as people stop working on libc++. (We still have a few TODO(EricWF) in the code base and I have the feeling he won't resolve them.)