__vector_base exists for historical reasons and cannot be eliminated
entirely without breaking the ABI. Member variables are left
untouched -- this patch only does changes that clearly cannot affect the
ABI.
Details
- Reviewers
ldionne - Group Reviewers
Restricted Project - Commits
- rG12b55821a578: [libc++][NFC] Inline most of `__vector_base` into `vector`.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
libcxx/include/vector | ||
---|---|---|
322–324 | My understanding is that it's probably okay to move the member variables as well (from the ABI perspective), but I'd rather do that change in a follow-up. | |
436–439 | It seemed that newer code in vector tends to use 2 spaces for indentation, so I reindented the older code I was moving around to be consistent with that. |
libcxx/include/vector | ||
---|---|---|
813 | Since you are moving this around, could you reformat to the LLVM style instead of keeping the old style? |
libcxx/include/vector | ||
---|---|---|
322–324 | Yes, I think it's OK to move them as long as we keep the order and we keep the same base classes. |
libcxx/include/vector | ||
---|---|---|
813 | I'll see if I can get clang-format to work on this file. If that goes well, I'd rather do a separate patch for reformatting the whole file. |
libcxx/include/vector | ||
---|---|---|
813 | I think we should be wary about formatting the entire file. It may cause merge conflicts for patches under review. I'd rather see a separate patch to format only the new lines new part in this file. When you do that can you directly do s/_LIBCPP_INLINE_VISIBILITY/_LIBCPP_HIDE_FROM_ABI/ for that part? |
LGTM mod kinda-pre-existing comments.
libcxx/include/vector | ||
---|---|---|
845–847 | FWIW, this manual noexcept-specification scares me. Nobody actually checks whether this function is noexcept, do they? If so, then all we're doing via this specification is asking the compiler to insert a call to std::terminate in the more-or-less-likely case that we got the condition wrong. I'd rather just remove lines 845–847. | |
885–895 | I'd prefer to see these tag-dispatch helpers moved up directly under the single-argument __move_assign_alloc that uses them. Ditto for __copy_assign_alloc. Bonus points if we can find a better function name for the helper, e.g. __move_assign_alloc_impl, so that we don't have one- and two-argument overloads of the same name. |
Hello,
Just a reminder when we change underlying structure of types in libc++ it is important to run the LLDB test suite. We have many formatters for libc++ and the rely on a lot of internals for the formatting. This case did not break a formatter it did change the type being returned by several member functions.
I had to track down this break using bisect and I just applied a fix: 0d62e31c458526e1db37d11da947e61768c7b522
Thank you
Just a reminder when we change underlying structure of types in libc++ it is important to run the LLDB test suite. We have many formatters for libc++ and the rely on a lot of internals for the formatting. This case did not break a formatter it did change the type being returned by several member functions.
@shafik Thanks for the fix, and sorry about the trouble. I plan some related follow-ups and will keep the LLDB tests in mind in the future. Thanks!
We have to find a solution for this. Depending on what you mean by the "structure" of things, I suspect we are changing that all the time.
How long does it take to run the LLDB formatters? Could we add a CI job that does exactly that? If we don't implement a systematic way of catching these bugs, we will keep breaking you without intending to. Can you provide a minimal CMake + Lit invocation to run the LLDB formatters (and ideally just that to save time)? I'll look into adding a CI job for it.
My understanding is that it's probably okay to move the member variables as well (from the ABI perspective), but I'd rather do that change in a follow-up.