This is an archive of the discontinued LLVM Phabricator instance.

[libc++] [ranges] Replace __function_like inheritance with a macro.
AbandonedPublic

Authored by Quuxplusone on Jul 22 2021, 8:53 AM.

Details

Reviewers
Quuxplusone
ldionne
cjdb
zoecarver
Mordante
Group Reviewers
Restricted Project
Summary

This is an alternative to D105078 which doesn't require exporting anything additional in our modulemaps.

I'm still not sure exactly what the compiler is doing in D105078, but the gist seems to be that if class C (in module M) inherits publicly from class D (in module N), and M doesn't re-export N, then it's as if that inheritance relationship doesn't exist. If a TU that imports M calls a function f(c) that would ordinarily find f(D&), it'll actually unambiguously find f(...) or whatever other less-good candidates exist. In this particular case, a call to &c doesn't find D::operator& but rather prefers the built-in candidate.

The solution adopted by me here is: don't inherit, then. "Inheritance is for sharing an interface"; here we don't want the interface to be shared; so, eliminate the inheritance and the modules problem goes with it.

Diff Detail

Event Timeline

Quuxplusone requested review of this revision.Jul 22 2021, 8:53 AM
Quuxplusone created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptJul 22 2021, 8:53 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript

Having confirmed the "Modular build" step fails with the original patch ( https://buildkite.com/llvm-project/libcxx-ci/builds/4430#9311f9f8-91ca-4465-a9b1-0ca67dd641ca ), now try it with __function_like non-private (to match __hash_table etc).

Quuxplusone retitled this revision from [WIP] poke buildkite, not for review to [libc++] [ranges] Replace __function_like inheritance with a macro..
Quuxplusone edited the summary of this revision. (Show Details)

Note to self: The way to check the troublesome modules test locally, without a full test run, is

./bin/clang++ -std=c++20 ../libcxx/test/std/iterators/iterator.primitives/range.iter.ops/range.iter.ops.advance/special_function.compile.pass.cpp -I ../libcxx/test/support/ "-fmodules" "-Xclang" "-fmodules-local-submodule-visibility" "-fcoroutines-ts" -c

I don't see anything wrong with this patch. However I'm not too fond of macro's so I prefer the approach taken in D105078.
I'm not fond of export __function_like in D105078. However I see that as work-around for a clang bug; once clang has been fixed it's possible to clean this up.

Actually the problem isn't the inheritance. My guess its usage causes the problem. For example D103357 has the same issue. Here std:optional<std::locale> is a function argument. Even when the caller doesn't specify the argument (and thus uses the defaulted value for the argument) the issue occurs.

I think this can be abandoned since we shipped D105078.

Quuxplusone abandoned this revision.Jul 23 2021, 8:51 AM

@ldionne: Okay. Although I look forward to reopening this after the addition of another dozen Ranges algorithms start spaghettifying the modulemap beyond your tolerance for spaghetti. :)