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