https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114461
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at gcc dot gnu.org,
| |nshead at gcc dot gnu.org,
| |ppalka at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Isn't the newly added http://eel.is/c++draft/cpp.module#2 in conflict with
http://eel.is/c++draft/cpp.module#3 ?
I mean if one is supposed to scan for
export module a.b.c : d.e.f
or similar without worrying about preprocessing, I think it should change the
3rd paragraph to talk about any preprocessing tokens after module and if
present after tokens from pp-module-name and pp-module-partition if any.
Either trhe pp-module-name and pp-module-partition tokens if any have disabled
macro expansion and then one can safely parse it without bothering about it, or
they are macro expanded, but then the "No identifier in the pp-module-name or
pp-module-partition shall currently be defined as an object-like macro."
doesn't make much sense as object-like macros were expanded already.
Things to consider:
#define DOT .
#define COLON :
#define FN(x) x
export module foo DOT bar;
export module baz COLON qux;
export module FN (;)
If the preprocessor should look through following tokens and as long as they
match the pp-module-{name,partition} grammar have disabled expansion
(tok->flags |= NO_EXPAND) it makes perfect sense to check for identifiers which
are
if (_cpp_defined_macro_p (node)
&& _cpp_maybe_notify_macro_use (pfile, node, tok->src_loc)
&& !cpp_fun_like_macro_p (node))
and error on those and perhaps the "shall not begin with a ( preprocessing
token" is about preventing function-like macros in there.
