This is an archive of the discontinued LLVM Phabricator instance.

[libc++] Fix PR35491 - std::array of zero-size doesn't work with non-default constructible types.
ClosedPublic

Authored by EricWF on Dec 13 2017, 10:45 PM.

Diff Detail

Repository
rL LLVM

Event Timeline

EricWF created this revision.Dec 13 2017, 10:45 PM
EricWF updated this revision to Diff 126898.Dec 13 2017, 11:17 PM

Fix begin/end/data.

lichray added inline comments.
include/array
135 ↗(On Diff #126898)

Just asking: no compiler is dumb enough to not inline this entirely trivial wrapper so that it's okay to not to propagate noexcept here to avoid try...capture...terminate codegen in its caller side?

I'm wondering if it's not a better idea to have an explicit specialization for size == 0

template <class T>
class array<T, 0> {
// and so on.
};

BTW, this is https://cplusplus.github.io/LWG/issue2157 , so please update www accordingly, and also test {{}} cases.

EricWF added a comment.Feb 3 2018, 4:57 PM

I'm wondering if it's not a better idea to have an explicit specialization for size == 0

template <class T>
class array<T, 0> {
// and so on.
};

I think that's probably more work than it's worth. I think we should change the primary template to support the bare minimum number of operations, and then let the rest of the operations blow up if users attempt to use them.

BTW, this is https://cplusplus.github.io/LWG/issue2157 , so please update www accordingly,

The www pages will get updated when the issue is actually accepted, which it currently isn't.
There is no place to put that information now.

and also test {{}} cases.

I don't agree those cases are valid. That initialization syntax suggests there is something in the zero-sized array which is default constructible - or that users should be able to control construction of. I disagree with that.

include/array
135 ↗(On Diff #126898)

_LIBCPP_INLINE_VISIBILITY should force inlining.

EricWF added a comment.Feb 3 2018, 4:58 PM

and also test {{}} cases.

I don't agree those cases are valid. That initialization syntax suggests there is something in the zero-sized array which is default constructible - or that users should be able to control construction of. I disagree with that.

Nevermind, I see STL is insisting that case be handled. I'll add tests and then complain to him later.

EricWF updated this revision to Diff 132758.Feb 3 2018, 5:03 PM
  • Address review comments.
  • Add initialization tests.
EricWF accepted this revision.Feb 3 2018, 5:03 PM
EricWF edited the summary of this revision. (Show Details)
This revision is now accepted and ready to land.Feb 3 2018, 5:03 PM
This revision was automatically updated to reflect the committed changes.
EricWF reopened this revision.Feb 7 2018, 1:04 PM

This was reverted as it caused build failures. Re-opening with new version.

This revision is now accepted and ready to land.Feb 7 2018, 1:04 PM
EricWF updated this revision to Diff 133285.Feb 7 2018, 1:05 PM
  • Update with new, hopefully working, version.
EricWF accepted this revision.Feb 7 2018, 1:07 PM

Accepting new version.

This revision was automatically updated to reflect the committed changes.
This revision was automatically updated to reflect the committed changes.
jtbandes added a subscriber: jtbandes.EditedFeb 28 2020, 10:53 PM

The lack of _LIBCPP_CONSTEXPR_AFTER_CXX14 on the array<T, 0> specialization's begin(), end(), and other methods seems to be a bug: https://stackoverflow.com/questions/60462569/empty-stdarrayt-0-doesnt-have-constexpr-begin

Herald added a project: Restricted Project. · View Herald TranscriptFeb 28 2020, 10:53 PM
EricWF added a comment.Mar 1 2020, 2:29 PM

The lack of _LIBCPP_CONSTEXPR_AFTER_CXX14 on the array<T, 0> specialization's begin(), end(), and other methods seems to be a bug: https://stackoverflow.com/questions/60462569/empty-stdarrayt-0-doesnt-have-constexpr-begin

That bug is llvm.org/PR40124.

There are good reasons why it hasn't been fixed yet.