You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
A clear and concise description of what the bug is.
export module a; doesn't work in -pure-cpp2 mode.
#include "cpp2util.h" should be inserted in the GMF.
Additional work might also be necessary.
CPP2_USE_MODULES shouldn't be defined while preprocessing it, as imports can't come from an #include.
With regards to the #ifdef CPP2_USE_MODULES,
its #ifdef __cpp_modules branch of should happen after the GMF, and
its #else branch in the GMF.
No declaration can be exported. It's not part of the grammar, and as such can't happen in the generated code.
I suppose one can also run into an issue due to the lack of support for inline, similar to Fix duplicate symbol of cpp2::args() function #268.
To Reproduce
Steps to reproduce the behavior:
Sample code - distilled down to minimal essentials please
error: declaration of 'operator new' in module main follows declaration in the global module
example.cpp2(2,13): error: missing semicolon at end of declaration (at 'namespace')
example.cpp2(2,1): error: unexpected text at end of Cpp2 code section (at 'ns')
example.cpp2(2,0): error: parse failed for section starting here
Additional context
Add any other context about the problem here.
Timing note for @JohelEGP and @filipsajdak: As you can see I've started the preliminary work to implement UDTs, and I plan to do further major extension and cleanup in the remaining March weekends, plus probably a week of vacation to work on cppfront. So it might make sense to defer new/updated PRs until after March ends as things will quiet down again about three weeks from now, otherwise you'll probably find yourself with conflicts/rebasing.
@JohelEGP Thanks! There's basic modules support in mixed Cpp1/Cpp2 files, and one reason I've put further modules support lower down the design/implementation backlog list is because GCC and Clang don't support them yet (though I know support is in progress). Modules is the only major feature of C++20 (or C++23) that is available on only one of the three major implementations (see Clang status)... even <format> (the other big feature that's been lagging) is further along and on the cusp of wide support being imminent in GCC 13 and being largely supported in Clang if you enable "experimental" ABI-unstable features. Given that modules don't really exist yet for portable code, I've pushed them down the backlog, though I hasten to add that Cpp2 is still a modules-first design... I can't wait for compilers to implement C++20!
I think export would go in the grammar on declaration... possibly as part of access-specifier because if export can't be put on individual class members, then it could share the same grammar production as public/private/protected since it's mutually exclusive with them. I did the same thing with implicit which shares a single this-specifier production with the virtual/override/final specifiers. (In today's Cpp1 grammar, explicit, virtual, override, and final are split up in five productions... function-specifier and base-specifier for the first one, explicit-specifier for the second, and virt-specifier and class-virt-specifier for the last two.)
Activity
gregmarr commentedon Mar 10, 2023
I haven't seen anything about CPP2 having
exportsupport yet.JohelEGP commentedon Mar 10, 2023
That's right. This is partly what this is about. I accidentally submitted it while editing.
gregmarr commentedon Mar 10, 2023
I just meant that I don't see this as a bug but as not yet implemented.
JohelEGP commentedon Mar 10, 2023
I have updated the bug report.
I could try implementing this. Where in the grammar should the
exportfor declarations go?hsutter commentedon Mar 11, 2023
[[meta]]
Timing note for @JohelEGP and @filipsajdak: As you can see I've started the preliminary work to implement UDTs, and I plan to do further major extension and cleanup in the remaining March weekends, plus probably a week of vacation to work on cppfront. So it might make sense to defer new/updated PRs until after March ends as things will quiet down again about three weeks from now, otherwise you'll probably find yourself with conflicts/rebasing.
@JohelEGP Thanks! There's basic modules support in mixed Cpp1/Cpp2 files, and one reason I've put further modules support lower down the design/implementation backlog list is because GCC and Clang don't support them yet (though I know support is in progress). Modules is the only major feature of C++20 (or C++23) that is available on only one of the three major implementations (see Clang status)... even
<format>(the other big feature that's been lagging) is further along and on the cusp of wide support being imminent in GCC 13 and being largely supported in Clang if you enable "experimental" ABI-unstable features. Given that modules don't really exist yet for portable code, I've pushed them down the backlog, though I hasten to add that Cpp2 is still a modules-first design... I can't wait for compilers to implement C++20!I think
exportwould go in the grammar on declaration... possibly as part of access-specifier because ifexportcan't be put on individual class members, then it could share the same grammar production as public/private/protected since it's mutually exclusive with them. I did the same thing withimplicitwhich shares a single this-specifier production with the virtual/override/final specifiers. (In today's Cpp1 grammar,explicit,virtual,override, andfinalare split up in five productions... function-specifier and base-specifier for the first one, explicit-specifier for the second, and virt-specifier and class-virt-specifier for the last two.)JohelEGP commentedon Mar 11, 2023
That makes sense. Thank you. I'm looking forward to your continued work.
filipsajdak commentedon Mar 11, 2023
@hsutter I will continue and will do the rebate.
I will be mainly focusing on bugs and fixes making my project compilable.