Page MenuHomePhabricator

[libcxx][iwyu] ensures we IWYU as prep for modules
ClosedPublic

Authored by cjdb on Jun 11 2021, 11:15 PM.

Details

Summary

This has been broken out of D104170 since it should be merged whether or
not we go ahead with the module map changes.

Diff Detail

Event Timeline

cjdb requested review of this revision.Jun 11 2021, 11:15 PM
cjdb created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptJun 11 2021, 11:16 PM
Herald added a reviewer: Restricted Project. · View Herald Transcript
Quuxplusone added inline comments.Jun 12 2021, 5:46 AM
libcxx/include/__memory/allocator_traits.h
360–368

All the #include changes look fine to me, but I question the wisdom of(*) splitting up the specializations of __is_default_allocator. Generally for a type-trait we want to keep the "true" and "false" branches together in the same file.
So, please don't make this diff. Either leave it as-is, or, if you really can't get the modules build building without a diff here, make the diff to add

template <class _Tp> class allocator;

right above line 360.

(* yes, this is understatement)

cjdb updated this revision to Diff 351680.Jun 12 2021, 12:27 PM
cjdb marked an inline comment as done.
cjdb retitled this revision from [libcxx][iwyu] ensures we IWYU for __iterator, __memory, and __ranges to [libcxx][iwyu] ensures we IWYU as prep for modules.

updates a lot of that were lacking explicit header inclusions (see most recent failures in D104170)

ldionne requested changes to this revision.Jun 14 2021, 5:58 AM

Include changes LGTM, but I don't understand the change to __function_like.

libcxx/include/__function_like.h
40 ↗(On Diff #351680)

Why is this change necessary?

This revision now requires changes to proceed.Jun 14 2021, 5:58 AM
cjdb added inline comments.Jun 14 2021, 9:23 AM
libcxx/include/__function_like.h
40 ↗(On Diff #351680)

The modules build seems to think that types derived from __function_like still have addresses. This sent me round the twist trying to figure out why, and I eventually explicitly deleted the operators in the derived types.

I don't want anyone to need to go through this again, so I think it's best we delete the operator from the base type so people realise they need to add it to the derived type.

Quuxplusone added inline comments.Jun 14 2021, 9:37 AM
libcxx/include/__function_like.h
40 ↗(On Diff #351680)

This explains the many changes in __iterator/advance.h etc.
Since this is absolutely unrelated to IWYU, I think it should be a separate PR. Also, for the record, I'll repeat my usual drumbeat that libc++ does not have to do any of this __function_like stuff, and if it's causing problems, I'd prefer us to just rip it out so that the libc++ code will be as simple as possible.

cjdb added inline comments.Jun 14 2021, 10:43 AM
libcxx/include/__function_like.h
40 ↗(On Diff #351680)

Since this is absolutely unrelated to IWYU, I think it should be a separate PR.

Sure, I can move it into D104170 patch, since it's directly driven by that patch.

This explains the many changes in __iterator/advance.h etc.
Also, for the record, I'll repeat my usual drumbeat that libc++ does not have to do any of this __function_like stuff, and if it's causing problems, I'd prefer us to just rip it out so that the libc++ code will be as simple as possible.

It would be really beneficial if you bothered to understand design decisions instead of wrongly asserting that something isn't necessary ad infinitum.

I'll spell it out for you, even though it's documented directly above this type's definition. Everything derived from this type is supposed to have the properties of a function. Functions cannot be default constructed. Functions cannot be moved. Functions cannot be copied. Standard functions are not allowed to have their addresses taken. It's extremely tempting to use functions that are derived from __function_like as higher-order functions. Hyrum's law dictates that users will eventually treat this as allowed if we don't prevent these things from happening. There was a deliberate decision to not make them function objects in the standard, and I do not want users to start treating them as if they are.

zoecarver accepted this revision as: zoecarver.Jun 14 2021, 10:50 AM

No opinion on what patch the operator change goes in. Thanks for explaining the rational.

Send it :)

ldionne accepted this revision.Jun 14 2021, 10:58 AM

LGTM but can you please move the operator& changes to the other patch? Also, I think this does reduce the usefulness of __function_like by quite a bit, cause now we have to think about adding a declaration in the function objects *and* derive from __function_like. I think we should fix the underlying modules bug (seriously, modules shouldn't have anything to do with this!) and more operator& back into __function_like.

This revision is now accepted and ready to land.Jun 14 2021, 10:58 AM
cjdb updated this revision to Diff 352183.Jun 15 2021, 10:39 AM

removes the addressof operator juggling from this patch

This revision was automatically updated to reflect the committed changes.