__function_like wasn't being exported, so certain properties of the
ranges functions weren't being propagated in modules land.
Details
- Reviewers
ldionne zoecarver Mordante • Quuxplusone - Group Reviewers
Restricted Project - Commits
- rG0cf65382ade2: [libcxx][modularisation] properly modularises advance, next, and prev
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks for the cleanup.
libcxx/include/module.modulemap | ||
---|---|---|
481–484 | I don't like the formatting here. But whatever. | |
libcxx/test/std/iterators/iterator.primitives/range.iter.ops/range.iter.ops.advance/special_function.compile.pass.cpp | ||
17 | Don't we still support clang-13 or am I missing something? Does this patch work around the bug? |
libcxx/include/module.modulemap | ||
---|---|---|
481–484 | There should be no need to export __function_like here. Then it'll all fit on one line, consistent with all the other lines, so there won't be a formatting problem anymore. | |
787 | Probably this private is the original problem. What happens if you remove it? |
libcxx/include/module.modulemap | ||
---|---|---|
481–484 |
Yeah, I didn't notice till after I threw it up on Phab. Will fix before merging.
There is a need to export __function_like. I've gone into this in other patches before, so I'm not going to repeat myself here. | |
787 | Nope. Nothing gets fixed because this isn't the problem. | |
libcxx/test/std/iterators/iterator.primitives/range.iter.ops/range.iter.ops.advance/special_function.compile.pass.cpp | ||
17 | This patch isn't a workaround: it's the correct fix. |
LGTM, but please hold off landing a short time to give @Quuxplusone an opportunity to respond.
libcxx/include/module.modulemap | ||
---|---|---|
481–484 |
I agree, but clang disagrees. I had the same issue in my format series, before we made these headers private. |
libcxx/include/__iterator/advance.h | ||
---|---|---|
73 | Btw, should there be a private here? __next_fn and __prev_fn both use private inheritance here, not public inheritance. At least we should be consistent. | |
libcxx/include/module.modulemap | ||
481–484 | I've looked into it a bit, and uploaded D106567 with a simpler fix. |
Ah-Ah! So that was the issue all along then.
IMO this module-specific fix is cleaner than using a macro just to satisfy the modules build.
Btw, should there be a private here? __next_fn and __prev_fn both use private inheritance here, not public inheritance. At least we should be consistent.
(obsoleted by D106567)