This is an archive of the discontinued LLVM Phabricator instance.

[libc++][NFC] Inline most of `__vector_base` into `vector`.
ClosedPublic

Authored by var-const on Nov 1 2021, 6:20 PM.

Details

Reviewers
ldionne
Group Reviewers
Restricted Project
Commits
rG12b55821a578: [libc++][NFC] Inline most of `__vector_base` into `vector`.
Summary

__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.

Diff Detail

Event Timeline

var-const requested review of this revision.Nov 1 2021, 6:20 PM
var-const created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptNov 1 2021, 6:20 PM
Herald added a reviewer: Restricted Project. · View Herald Transcript
var-const added inline comments.Nov 1 2021, 6:23 PM
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.

philnik added a subscriber: philnik.Nov 2 2021, 1:49 AM
philnik added inline comments.
libcxx/include/vector
813

Since you are moving this around, could you reformat to the LLVM style instead of keeping the old style?

ldionne accepted this revision.Nov 2 2021, 5:58 AM
ldionne added a subscriber: ldionne.
ldionne added inline comments.
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.

This revision is now accepted and ready to land.Nov 2 2021, 5:58 AM
var-const added inline comments.Nov 2 2021, 5:05 PM
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.

var-const updated this revision to Diff 384280.Nov 2 2021, 5:06 PM

Rebase on main.

Mordante added inline comments.
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.
(Either this removal will make an existing regression test fail; or else it's totally a good idea; or else we need to add a regression test for it. I believe #2 is the right hypothesis.)

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.

var-const updated this revision to Diff 385221.Nov 5 2021, 6:43 PM

Rebase on main.

shafik added a subscriber: shafik.Nov 10 2021, 12:46 PM

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!

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

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.