gcc.git/libcpp/include/cpplib.h, branch trunk Unnamed repository; edit this file 'description' to name the repository. c++: Warn on #undef/#define of remaining cpp.predefined macros [PR120778] 2025-08-15T20:31:27+00:00 Jakub Jelinek jakub@redhat.com 2025-08-15T20:31:27+00:00 cdd015c4ddbb1ae71eea1e44654cee5ca29a6c64 We already warn on #undef or pedwarn on #define (but not on #define after #undef) of some builtin macros mentioned in cpp.predefined. The C++26 P2843R3 paper changes it from (compile time) undefined behavior to ill-formed. The following patch arranges for warning (for #undef) and pedwarn (on #define) for the remaining cpp.predefined macros. __cpp_* feature test macros only for C++20 which added some of them to cpp.predefined, in earlier C++ versions it was just an extension and for pedantic diagnostic I think we don't need to diagnose anything, __STDCPP_* and __cplusplus macros for all C++ versions where they appeared. Like the earlier posted -Wkeyword-macro diagnostics (which is done regardless whether the identifier is defined as a macro or not, obviously most likely none of the keywords are defined as macros initially), this one also warns on #undef when a macro isn't defined or later #define after #undef. 2025-08-15 Jakub Jelinek <jakub@redhat.com> PR preprocessor/120778 PR target/121520 gcc/c-family/ * c-cppbuiltin.cc (c_cpp_builtins): Implement C++26 DR 2581. Add cpp_define_warn lambda and use it as well as cpp_warn where needed. In the if (c_dialect_cxx ()) block with __cpp_* predefinitions add cpp_define lambda. Formatting fixes. gcc/c/ * c-decl.cc (c_init_decl_processing): Use cpp_warn instead of cpp_lookup and NODE_WARN bit setting. gcc/cp/ * lex.cc (cxx_init): Remove warn_on lambda. Use cpp_warn instead of cpp_lookup and NODE_WARN bit setting or warn_on. gcc/testsuite/ * g++.dg/DRs/dr2581-1.C: New test. * g++.dg/DRs/dr2581-2.C: New test. * c-c++-common/cpp/pr92296-2.c: Expect warnings also on defining special macros after undefining them. libcpp/ * include/cpplib.h (struct cpp_options): Add suppress_builtin_macro_warnings member. (cpp_warn): New inline functions. * init.cc (cpp_create_reader): Clear suppress_builtin_macro_warnings. (cpp_init_builtins): Call cpp_warn on __cplusplus, __STDC__, __STDC_VERSION__, __STDC_MB_MIGHT_NEQ_WC__ and __STDCPP_STRICT_POINTER_SAFETY__ when appropriate. * directives.cc (do_undef): Warn on undefining NODE_WARN macros if not cpp_keyword_p. Don't emit any NODE_WARN related diagnostics if CPP_OPTION (pfile, suppress_builtin_macro_warnings). (cpp_define, _cpp_define_builtin, cpp_undef): Temporarily set CPP_OPTION (pfile, suppress_builtin_macro_warnings) around run_directive calls. * macro.cc (_cpp_create_definition): Warn on defining NODE_WARN macros if they weren't previously defined and not cpp_keyword_p. Ignore NODE_WARN for diagnostics if CPP_OPTION (pfile, suppress_builtin_macro_warnings). 
We already warn on #undef or pedwarn on #define (but not on #define
after #undef) of some builtin macros mentioned in cpp.predefined.

The C++26 P2843R3 paper changes it from (compile time) undefined behavior
to ill-formed.  The following patch arranges for warning (for #undef)
and pedwarn (on #define) for the remaining cpp.predefined macros.
__cpp_* feature test macros only for C++20 which added some of them
to cpp.predefined, in earlier C++ versions it was just an extension and
for pedantic diagnostic I think we don't need to diagnose anything,
__STDCPP_* and __cplusplus macros for all C++ versions where they appeared.

Like the earlier posted -Wkeyword-macro diagnostics (which is done
regardless whether the identifier is defined as a macro or not, obviously
most likely none of the keywords are defined as macros initially), this
one also warns on #undef when a macro isn't defined or later #define
after #undef.

2025-08-15  Jakub Jelinek  <jakub@redhat.com>

	PR preprocessor/120778
	PR target/121520
gcc/c-family/
	* c-cppbuiltin.cc (c_cpp_builtins): Implement C++26 DR 2581.  Add
	cpp_define_warn lambda and use it as well as cpp_warn where needed.
	In the if (c_dialect_cxx ()) block with __cpp_* predefinitions add
	cpp_define lambda.  Formatting fixes.
gcc/c/
	* c-decl.cc (c_init_decl_processing): Use cpp_warn instead of
	cpp_lookup and NODE_WARN bit setting.
gcc/cp/
	* lex.cc (cxx_init): Remove warn_on lambda.  Use cpp_warn instead of
	cpp_lookup and NODE_WARN bit setting or warn_on.
gcc/testsuite/
	* g++.dg/DRs/dr2581-1.C: New test.
	* g++.dg/DRs/dr2581-2.C: New test.
	* c-c++-common/cpp/pr92296-2.c: Expect warnings also on defining
	special macros after undefining them.
libcpp/
	* include/cpplib.h (struct cpp_options): Add
	suppress_builtin_macro_warnings member.
	(cpp_warn): New inline functions.
	* init.cc (cpp_create_reader): Clear suppress_builtin_macro_warnings.
	(cpp_init_builtins): Call cpp_warn on __cplusplus, __STDC__,
	__STDC_VERSION__, __STDC_MB_MIGHT_NEQ_WC__ and
	__STDCPP_STRICT_POINTER_SAFETY__ when appropriate.
	* directives.cc (do_undef): Warn on undefining NODE_WARN macros if
	not cpp_keyword_p.  Don't emit any NODE_WARN related diagnostics
	if CPP_OPTION (pfile, suppress_builtin_macro_warnings).
	(cpp_define, _cpp_define_builtin, cpp_undef): Temporarily set
	CPP_OPTION (pfile, suppress_builtin_macro_warnings) around
	run_directive calls.
	* macro.cc (_cpp_create_definition): Warn on defining NODE_WARN
	macros if they weren't previously defined and not cpp_keyword_p.
	Ignore NODE_WARN for diagnostics if
	CPP_OPTION (pfile, suppress_builtin_macro_warnings).
c++, c: Introduce -Wkeyword-macro warning/pedwarn - part of C++26 P2843R3 [PR120778] 2025-08-07T06:47:44+00:00 Jakub Jelinek jakub@redhat.com 2025-08-07T06:47:44+00:00 64859dc6e2948616439b500b5d9ffb2635b45ae8 The following patch introduces a -Wkeyword-macro warning that clang has since 2014 to implement part of C++26 P2843R3 Preprocessing is never undefined paper. The relevant change in the paper is moving [macro.names]/2 paragraph to https://eel.is/c++draft/cpp.replace.general#9 : "A translation unit shall not #define or #undef names lexically identical to keywords, to the identifiers listed in Table 4, or to the attribute-tokens described in [dcl.attr], except that the names likely and unlikely may be defined as function-like macros." Now, my understanding of the paper is that in [macro.names] and surrounding sections the word shall bears different meaning from [cpp.replace.general], where only the latter location implies ill-formed, diagnostic required. The warning in clang when introduced diagnosed all #define/#undef directives on keywords, but shortly after introduction has been changed not to diagnose #undef at all (with "#undef a keyword is generally harmless but used often in configuration scripts" message) and later on even the #define part tweaked - not warn about say #define inline (or const, extern, static), or #define keyword keyword or #define keyword __keyword or #define keyword __keyword__ Later on the warning has been moved to be only pedantic diagnostic unless requested by users. Clearly some code in the wild does e.g. #define private public and similar games, or e.g. Linux kernel (sure, C) does #define inline __inline__ __attribute__((__always_inline__)) etc. Now, I believe at least with the current C++26 wording such exceptions aren't allowed (unless it is changed to IFNDR). But given that this is just pedantic stuff, the following patch makes the warning off by default for C and C++ before C++26 and even for C++26 it enables it by default only if -pedantic/-pedantic-errors (in that case it pedwarns, otherwise it warns). And it diagnoses both #define and #undef without exceptions. From what I can see, all the current NODE_WARN cases are macros starting with __ with one exception (_Pragma). As the NODE_* flags seem to be a limited resource, I chose to just use NODE_WARN as well and differentiate on the node names (if they don't start with __ or _P, they are considered to be -Wkeyword-macro registered ones, otherwise old NODE_WARN cases, typically builtin macros or __STDC* macros). 2025-08-07 Jakub Jelinek <jakub@redhat.com> PR preprocessor/120778 gcc/ * doc/invoke.texi (Wkeyword-macro): Document. gcc/c-family/ * c.opt (Wkeyword-macro): New option. * c.opt.urls: Regenerate. * c-common.h (cxx_dialect): Comment formatting fix. * c-opts.cc (c_common_post_options): Default to -Wkeyword-macro for C++26 if pedantic. gcc/c/ * c-decl.cc (c_init_decl_processing): Mark cpp nodes corresponding to keywords as NODE_WARN if warn_keyword_macro. gcc/cp/ * lex.cc (cxx_init): Mark cpp nodes corresponding to keywords, identifiers with special meaning and standard attribute identifiers as NODE_WARN if warn_keyword_macro. gcc/testsuite/ * gcc.dg/Wkeyword-macro-1.c: New test. * gcc.dg/Wkeyword-macro-2.c: New test. * gcc.dg/Wkeyword-macro-3.c: New test. * gcc.dg/Wkeyword-macro-4.c: New test. * gcc.dg/Wkeyword-macro-5.c: New test. * gcc.dg/Wkeyword-macro-6.c: New test. * gcc.dg/Wkeyword-macro-7.c: New test. * gcc.dg/Wkeyword-macro-8.c: New test. * gcc.dg/Wkeyword-macro-9.c: New test. * g++.dg/warn/Wkeyword-macro-1.C: New test. * g++.dg/warn/Wkeyword-macro-2.C: New test. * g++.dg/warn/Wkeyword-macro-3.C: New test. * g++.dg/warn/Wkeyword-macro-4.C: New test. * g++.dg/warn/Wkeyword-macro-5.C: New test. * g++.dg/warn/Wkeyword-macro-6.C: New test. * g++.dg/warn/Wkeyword-macro-7.C: New test. * g++.dg/warn/Wkeyword-macro-8.C: New test. * g++.dg/warn/Wkeyword-macro-9.C: New test. * g++.dg/warn/Wkeyword-macro-10.C: New test. * g++.dg/opt/pr82577.C: Don't #define register to nothing for C++17 and later. Instead define reg macro to nothing for C++17 and later or to register and use it instead of register. * g++.dg/modules/atom-preamble-3.C: Add -Wno-keyword-macro to dg-additional-options. * g++.dg/template/sfinae17.C (static_assert): Rename macro to ... (my_static_assert): ... this. (main): Use my_static_assert instead of static_assert. libcpp/ * include/cpplib.h (struct cpp_options): Add cpp_warn_keyword_macro. (enum cpp_warning_reason): Add CPP_W_KEYWORD_MACRO enumerator. (cpp_keyword_p): New inline function. * directives.cc (do_undef): Support -Wkeyword-macro diagnostics. * macro.cc (warn_of_redefinition): Ignore NODE_WARN flag on nodes registered for -Wkeyword-macro. (_cpp_create_definition): Support -Wkeyword-macro diagnostics. Formatting fixes. 
The following patch introduces a -Wkeyword-macro warning that clang has
since 2014 to implement part of C++26 P2843R3 Preprocessing is never undefined
paper.
The relevant change in the paper is moving [macro.names]/2 paragraph to
https://eel.is/c++draft/cpp.replace.general#9 :
"A translation unit shall not #define or #undef names lexically identical to
keywords, to the identifiers listed in Table 4, or to the attribute-tokens
described in [dcl.attr], except that the names likely and unlikely may be
defined as function-like macros."

Now, my understanding of the paper is that in [macro.names] and surrounding
sections the word shall bears different meaning from [cpp.replace.general],
where only the latter location implies ill-formed, diagnostic required.

The warning in clang when introduced diagnosed all #define/#undef directives
on keywords, but shortly after introduction has been changed not to
diagnose #undef at all (with "#undef a keyword is generally harmless but used
often in configuration scripts" message) and later on even the #define
part tweaked - not warn about say
  #define inline
(or const, extern, static), or
  #define keyword keyword
or
  #define keyword __keyword
or
  #define keyword __keyword__
Later on the warning has been moved to be only pedantic diagnostic unless
requested by users.  Clearly some code in the wild does e.g.
  #define private public
and similar games, or e.g. Linux kernel (sure, C) does
  #define inline __inline__ __attribute__((__always_inline__))
etc.
Now, I believe at least with the current C++26 wording such exceptions
aren't allowed (unless it is changed to IFNDR).  But given that this is just
pedantic stuff, the following patch makes the warning off by default for
C and C++ before C++26 and even for C++26 it enables it by default only
if -pedantic/-pedantic-errors (in that case it pedwarns, otherwise it
warns).  And it diagnoses both #define and #undef without exceptions.

From what I can see, all the current NODE_WARN cases are macros starting
with __ with one exception (_Pragma).  As the NODE_* flags seem to be a
limited resource, I chose to just use NODE_WARN as well and differentiate
on the node names (if they don't start with __ or _P, they are considered
to be -Wkeyword-macro registered ones, otherwise old NODE_WARN cases,
typically builtin macros or __STDC* macros).

2025-08-07  Jakub Jelinek  <jakub@redhat.com>

	PR preprocessor/120778
gcc/
	* doc/invoke.texi (Wkeyword-macro): Document.
gcc/c-family/
	* c.opt (Wkeyword-macro): New option.
	* c.opt.urls: Regenerate.
	* c-common.h (cxx_dialect): Comment formatting fix.
	* c-opts.cc (c_common_post_options): Default to
	-Wkeyword-macro for C++26 if pedantic.
gcc/c/
	* c-decl.cc (c_init_decl_processing): Mark cpp nodes corresponding
	to keywords as NODE_WARN if warn_keyword_macro.
gcc/cp/
	* lex.cc (cxx_init): Mark cpp nodes corresponding
	to keywords, identifiers with special meaning and standard
	attribute identifiers as NODE_WARN if warn_keyword_macro.
gcc/testsuite/
	* gcc.dg/Wkeyword-macro-1.c: New test.
	* gcc.dg/Wkeyword-macro-2.c: New test.
	* gcc.dg/Wkeyword-macro-3.c: New test.
	* gcc.dg/Wkeyword-macro-4.c: New test.
	* gcc.dg/Wkeyword-macro-5.c: New test.
	* gcc.dg/Wkeyword-macro-6.c: New test.
	* gcc.dg/Wkeyword-macro-7.c: New test.
	* gcc.dg/Wkeyword-macro-8.c: New test.
	* gcc.dg/Wkeyword-macro-9.c: New test.
	* g++.dg/warn/Wkeyword-macro-1.C: New test.
	* g++.dg/warn/Wkeyword-macro-2.C: New test.
	* g++.dg/warn/Wkeyword-macro-3.C: New test.
	* g++.dg/warn/Wkeyword-macro-4.C: New test.
	* g++.dg/warn/Wkeyword-macro-5.C: New test.
	* g++.dg/warn/Wkeyword-macro-6.C: New test.
	* g++.dg/warn/Wkeyword-macro-7.C: New test.
	* g++.dg/warn/Wkeyword-macro-8.C: New test.
	* g++.dg/warn/Wkeyword-macro-9.C: New test.
	* g++.dg/warn/Wkeyword-macro-10.C: New test.
	* g++.dg/opt/pr82577.C: Don't #define register to nothing for
	C++17 and later.  Instead define reg macro to nothing for C++17
	and later or to register and use it instead of register.
	* g++.dg/modules/atom-preamble-3.C: Add -Wno-keyword-macro to
	dg-additional-options.
	* g++.dg/template/sfinae17.C (static_assert): Rename macro to ...
	(my_static_assert): ... this.
	(main): Use my_static_assert instead of static_assert.
libcpp/
	* include/cpplib.h (struct cpp_options): Add cpp_warn_keyword_macro.
	(enum cpp_warning_reason): Add CPP_W_KEYWORD_MACRO enumerator.
	(cpp_keyword_p): New inline function.
	* directives.cc (do_undef): Support -Wkeyword-macro diagnostics.
	* macro.cc (warn_of_redefinition): Ignore NODE_WARN flag on nodes
	registered for -Wkeyword-macro.
	(_cpp_create_definition): Support -Wkeyword-macro diagnostics.
	Formatting fixes.
diagnostics: introduce diagnostics/source-printing.cc 2025-07-25T19:13:37+00:00 David Malcolm dmalcolm@redhat.com 2025-07-25T19:13:37+00:00 e31ec9ee65386a7cf978c204e123b9a97eb9c296 Move diagnostic-show-locus.cc to diagnostics/source-printing.cc Move diagnostic-label-effects.h to diagnostics/source-printing-effects.h Move selftest-diagnostic-show-locus.h to diagnostics/selftest-source-printing.h No functional change intended. gcc/ChangeLog: * Makefile.in (OBJS): Replace diagnostic-show-locus.o with diagnostics/source-printing.o. * diagnostic.h (class diagnostic_source_effect_info): Replace with... (class diagnotics::source_effect_info): ...this. * diagnostics/paths-output.cc: Likewise. Update for move of "diagnostic-label-effects.h" to "diagnostics/source-printing-effects.h". * diagnostics/sarif-sink.cc: Update for move of "selftest-diagnostic-show-locus.h" to "diagnostics/selftest-source-printing.h". * selftest-diagnostic-show-locus.h: Move to... * diagnostics/selftest-source-printing.h: ...here. * diagnostic-label-effects.h: Move to... * diagnostics/source-printing-effects.h: ...here, updating for above changes. * diagnostic-show-locus.cc: Move to... * diagnostics/source-printing.cc: ...here. * gcc-rich-location.h: Likewise. * selftest-run-tests.cc: Likewise. * selftest.h: Likewise. gcc/testsuite/ChangeLog: * g++.dg/plugin/show-template-tree-color-labels.C: Update for moves to "source-printing". * gcc.dg/plugin/diagnostic-test-show-locus.py: Likewise. libcpp/ChangeLog: * include/cpplib.h: Update for moves to "source-printing". * include/rich-location.h (class label_effects): Move to... (class diagnostics::label_effects): ...here. Signed-off-by: David Malcolm <dmalcolm@redhat.com> 
Move diagnostic-show-locus.cc to diagnostics/source-printing.cc

Move diagnostic-label-effects.h to diagnostics/source-printing-effects.h

Move selftest-diagnostic-show-locus.h
  to diagnostics/selftest-source-printing.h

No functional change intended.

gcc/ChangeLog:
	* Makefile.in (OBJS): Replace diagnostic-show-locus.o with
	diagnostics/source-printing.o.
	* diagnostic.h (class diagnostic_source_effect_info): Replace
	with...
	(class diagnotics::source_effect_info): ...this.
	* diagnostics/paths-output.cc: Likewise.  Update for move of
	"diagnostic-label-effects.h" to
	"diagnostics/source-printing-effects.h".
	* diagnostics/sarif-sink.cc: Update for move of
	"selftest-diagnostic-show-locus.h" to
	"diagnostics/selftest-source-printing.h".
	* selftest-diagnostic-show-locus.h: Move to...
	* diagnostics/selftest-source-printing.h: ...here.
	* diagnostic-label-effects.h: Move to...
	* diagnostics/source-printing-effects.h: ...here, updating
	for above changes.
	* diagnostic-show-locus.cc: Move to...
	* diagnostics/source-printing.cc: ...here.
	* gcc-rich-location.h: Likewise.
	* selftest-run-tests.cc: Likewise.
	* selftest.h: Likewise.

gcc/testsuite/ChangeLog:
	* g++.dg/plugin/show-template-tree-color-labels.C: Update for
	moves to "source-printing".
	* gcc.dg/plugin/diagnostic-test-show-locus.py: Likewise.

libcpp/ChangeLog:
	* include/cpplib.h: Update for moves to "source-printing".
	* include/rich-location.h (class label_effects): Move to...
	(class diagnostics::label_effects): ...here.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>
c-family: Improve location for -Wunknown-pragmas in a _Pragma [PR118838] 2025-04-28T02:35:25+00:00 Lewis Hyatt lhyatt@gmail.com 2025-02-11T18:45:41+00:00 78673484b4055b93207eee0efd60a434b0bf96ab The warning for -Wunknown-pragmas is issued at the location provided by libcpp to the def_pragma() callback. This location is cpp_reader::directive_line, which is a location for the start of the line only; it is also not a valid location in case the unknown pragma was lexed from a _Pragma string. These factors make it impossible to suppress -Wunknown-pragmas via _Pragma("GCC diagnostic...") directives on the same source line, as in the PR and the test case. Address that by issuing the warning at a better location returned by cpp_get_diagnostic_override_loc(). libcpp already maintains this location to handle _Pragma-related diagnostics internally; it was needed also to make a publicly accessible version of it. gcc/c-family/ChangeLog: PR c/118838 * c-lex.cc (cb_def_pragma): Call cpp_get_diagnostic_override_loc() to get a valid location at which to issue -Wunknown-pragmas, in case it was triggered from a _Pragma. libcpp/ChangeLog: PR c/118838 * errors.cc (cpp_get_diagnostic_override_loc): New function. * include/cpplib.h (cpp_get_diagnostic_override_loc): Declare. gcc/testsuite/ChangeLog: PR c/118838 * c-c++-common/cpp/pragma-diagnostic-loc-2.c: New test. * g++.dg/gomp/macro-4.C: Adjust expected output. * gcc.dg/gomp/macro-4.c: Likewise. * gcc.dg/cpp/Wunknown-pragmas-1.c: Likewise. 
The warning for -Wunknown-pragmas is issued at the location provided by
libcpp to the def_pragma() callback. This location is
cpp_reader::directive_line, which is a location for the start of the line
only; it is also not a valid location in case the unknown pragma was lexed
from a _Pragma string. These factors make it impossible to suppress
-Wunknown-pragmas via _Pragma("GCC diagnostic...") directives on the same
source line, as in the PR and the test case. Address that by issuing the
warning at a better location returned by cpp_get_diagnostic_override_loc().
libcpp already maintains this location to handle _Pragma-related diagnostics
internally; it was needed also to make a publicly accessible version of it.

gcc/c-family/ChangeLog:

	PR c/118838
	* c-lex.cc (cb_def_pragma): Call cpp_get_diagnostic_override_loc()
	to get a valid location at which to issue -Wunknown-pragmas, in case
	it was triggered from a _Pragma.

libcpp/ChangeLog:

	PR c/118838
	* errors.cc (cpp_get_diagnostic_override_loc): New function.
	* include/cpplib.h (cpp_get_diagnostic_override_loc): Declare.

gcc/testsuite/ChangeLog:

	PR c/118838
	* c-c++-common/cpp/pragma-diagnostic-loc-2.c: New test.
	* g++.dg/gomp/macro-4.C: Adjust expected output.
	* gcc.dg/gomp/macro-4.c: Likewise.
	* gcc.dg/cpp/Wunknown-pragmas-1.c: Likewise.
c++: Adjust #embed support for P1967R14 2025-02-28T14:22:08+00:00 Jakub Jelinek jakub@redhat.com 2025-02-28T14:17:37+00:00 b510c53b18b7255bc43de1c45b700e0206ca27f0 Now that the #embed paper has been voted in, the following patch removes the pedwarn for C++26 on it (and adjusts pedwarn warning for older C++ versions) and predefines __cpp_pp_embed FTM. Also, the patch changes cpp_error to cpp_pedwarning with for C++ -Wc++26-extensions guarding, and for C add -Wc11-c23-compat warning about #embed. I believe we otherwise implement everything in the paper already, except I'm really confused by the [Example: #embed <data.dat> limit(__has_include("a.h")) #if __has_embed(<data.dat> limit(__has_include("a.h"))) // ill-formed: __has_include [cpp.cond] cannot appear here #endif — end example] part. My reading of both C23 and C++ with the P1967R14 paper in is that the first case (#embed with __has_include or __has_embed in its clauses) is what is clearly invalid and so the ill-formed note should be for #embed. And the __has_include/__has_embed in __has_embed is actually questionable. Both C and C++ have something like "The identifiers __has_include, __has_embed, and __has_c_attribute shall not appear in any context not mentioned in this subclause." or "The identifiers __has_include and __has_cpp_attribute shall not appear in any context not mentioned in this subclause." (into which P1967R14 adds __has_embed) in the conditional inclusion subclause. #embed is defined in a different one, so using those in there is invalid (unless "using the rules specified for conditional inclusion" wording e.g. in limit clause overrides that). The reason why I think it is fuzzy for __has_embed is that __has_embed is actually defined in the Conditional inclusion subclause (so that would mean one can use __has_include, __has_embed and __has_*attribute in there) but its clauses are described in a different one. GCC currently accepts #embed __FILE__ limit (__has_include (<stdarg.h>)) #if __has_embed (__FILE__ limit (__has_include (<stdarg.h>))) #endif #embed __FILE__ limit (__has_embed (__FILE__)) #if __has_embed (__FILE__ limit (__has_embed (__FILE__))) #endif Note, it isn't just about limit clause, but also about prefix/suffix/if_empty, except that in those cases the "using the rules specified for conditional inclusion" doesn't apply. In any case, I'd hope that can be dealt with incrementally (and should be handled the same for both C and C++). 2025-02-28 Jakub Jelinek <jakub@redhat.com> libcpp/ * include/cpplib.h (enum cpp_warning_reason): Add CPP_W_CXX26_EXTENSIONS enumerator. * init.cc (lang_defaults): Set embed for GNUCXX26 and CXX26. * directives.cc (do_embed): Adjust pedwarn wording for embed in C++, use cpp_pedwarning instead of cpp_error and add CPP_W_C11_C23_COMPAT warning of cpp_pedwarning hasn't diagnosed anything. gcc/c-family/ * c.opt (Wc++26-extensions): Add CppReason(CPP_W_CXX26_EXTENSIONS). * c-cppbuiltin.cc (c_cpp_builtins): Predefine __cpp_pp_embed=202502 for C++26. gcc/testsuite/ * g++.dg/cpp/embed-1.C: Adjust for pedwarn wording change and don't expect any error for C++26. * g++.dg/cpp/embed-2.C: Adjust for pedwarn wording change and don't expect any warning for C++26. * g++.dg/cpp26/feat-cxx26.C: Test __cpp_pp_embed value. * gcc.dg/cpp/embed-17.c: New test. 
Now that the #embed paper has been voted in, the following patch
removes the pedwarn for C++26 on it (and adjusts pedwarn warning for
older C++ versions) and predefines __cpp_pp_embed FTM.

Also, the patch changes cpp_error to cpp_pedwarning with for C++
-Wc++26-extensions guarding, and for C add -Wc11-c23-compat warning
about #embed.

I believe we otherwise implement everything in the paper already,
except I'm really confused by the
 [Example:

 #embed <data.dat> limit(__has_include("a.h"))

 #if __has_embed(<data.dat> limit(__has_include("a.h")))
 // ill-formed: __has_include [cpp.cond] cannot appear here
 #endif

 — end example]
part.  My reading of both C23 and C++ with the P1967R14 paper in
is that the first case (#embed with __has_include or __has_embed in its
clauses) is what is clearly invalid and so the ill-formed note should be
for #embed.  And the __has_include/__has_embed in __has_embed is actually
questionable.
Both C and C++ have something like
"The identifiers __has_include, __has_embed, and __has_c_attribute
shall not appear in any context not mentioned in this subclause."
or
"The identifiers __has_include and __has_cpp_attribute shall not appear
in any context not mentioned in this subclause."
(into which P1967R14 adds __has_embed) in the conditional inclusion
subclause.  #embed is defined in a different one, so using those in there
is invalid (unless "using the rules specified for conditional inclusion"
wording e.g. in limit clause overrides that).
The reason why I think it is fuzzy for __has_embed is that __has_embed
is actually defined in the Conditional inclusion subclause (so that
would mean one can use __has_include, __has_embed and __has_*attribute
in there) but its clauses are described in a different one.

GCC currently accepts
 #embed __FILE__ limit (__has_include (<stdarg.h>))
 #if __has_embed (__FILE__ limit (__has_include (<stdarg.h>)))
 #endif
 #embed __FILE__ limit (__has_embed (__FILE__))
 #if __has_embed (__FILE__ limit (__has_embed (__FILE__)))
 #endif
Note, it isn't just about limit clause, but also about
prefix/suffix/if_empty, except that in those cases the "using the rules
specified for conditional inclusion" doesn't apply.

In any case, I'd hope that can be dealt with incrementally (and should
be handled the same for both C and C++).

2025-02-28  Jakub Jelinek  <jakub@redhat.com>

libcpp/
	* include/cpplib.h (enum cpp_warning_reason): Add
	CPP_W_CXX26_EXTENSIONS enumerator.
	* init.cc (lang_defaults): Set embed for GNUCXX26 and CXX26.
	* directives.cc (do_embed): Adjust pedwarn wording for embed in C++,
	use cpp_pedwarning instead of cpp_error and add CPP_W_C11_C23_COMPAT
	warning of cpp_pedwarning hasn't diagnosed anything.
gcc/c-family/
	* c.opt (Wc++26-extensions): Add CppReason(CPP_W_CXX26_EXTENSIONS).
	* c-cppbuiltin.cc (c_cpp_builtins): Predefine __cpp_pp_embed=202502
	for C++26.
gcc/testsuite/
	* g++.dg/cpp/embed-1.C: Adjust for pedwarn wording change and don't
	expect any error for C++26.
	* g++.dg/cpp/embed-2.C: Adjust for pedwarn wording change and don't
	expect any warning for C++26.
	* g++.dg/cpp26/feat-cxx26.C: Test __cpp_pp_embed value.
	* gcc.dg/cpp/embed-17.c: New test.
Update copyright years. 2025-01-02T10:59:57+00:00 Jakub Jelinek jakub@redhat.com 2025-01-02T10:59:57+00:00 6441eb6dc020faae0672ea724dfdb38c6a9bf6a1 






Support for 64-bit location_t: Activate 64-bit location_t
2024-12-08T15:32:27+00:00

Lewis Hyatt
lhyatt@gmail.com

2024-11-16T18:45:22+00:00

d9cdc500c1e86b1218a24d1e8469930f000528d0

Change location_t to be a 64-bit integer instead of a 32-bit integer in
libcpp.

Also included in this change are the two other patches in the original
series which depended on this one; I am committing them all at once in case
it needs to be reverted later:

-Support for 64-bit location_t: gimple parts

The size of struct gimple increased by 8 bytes with the change in size of
location_t from 32- to 64-bit; adjust the WORD markings in the comments
accordingly. It seems that most of the WORD markings were off by one already,
probably not having been updated after a previous reduction in the size of a
gimple, so they have become retroactively correct again, and only a couple
needed adjustment actually.

Also add a comment that there is now 32 bits of unused padding available in
struct gimple for 64-bit hosts.

-Support for 64-bit location_t: Remove -flarge-source-files

The option -flarge-source-files became unnecessary with 64-bit location_t
and harms performance compared to the new default setting, so silently
ignore it.

libcpp/ChangeLog:

	* include/cpplib.h (struct cpp_token): Adjust comment about the
	struct size.
	* include/line-map.h (location_t): Change typedef from 32-bit to 64-bit
	integer.
	(LINE_MAP_MAX_COLUMN_NUMBER): Increase size to be appropriate for
	64-bit location_t.
	(LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES): Likewise.
	(LINE_MAP_MAX_LOCATION_WITH_COLS): Likewise.
	(LINE_MAP_MAX_LOCATION): Likewise.
	(MAX_LOCATION_T): Likewise.
	(line_map_suggested_range_bits): Likewise.
	(struct line_map): Adjust comment about the struct size.
	(struct line_map_macro): Likewise.
	(struct line_map_ordinary): Likewise. Rearrange fields to optimize
	padding.

gcc/testsuite/ChangeLog:

	* g++.dg/diagnostic/pr77949.C: Adapt the test for 64-bit location_t,
	when the previously expected failure doesn't actually happen.
	* g++.dg/modules/loc-prune-4.C: Adjust the expected output for the
	64-bit location_t case.
	* gcc.dg/plugin/expensive_selftests_plugin.cc: Don't try to test
	the maximum supported column number in 64-bit location_t mode.
	* gcc.dg/plugin/location_overflow_plugin.cc: Adjust the base_location
	so it can effectively test 64-bit location_t.

gcc/ChangeLog:

	* gimple.h (struct gphi): Update word marking comments to reflect
	the new size of location_t.
	(struct gimple): Likewise. Add a comment about padding.
	* common.opt: Mark -flarge-source-files as Ignored.
	* common.opt.urls: Regenerate.
	* doc/invoke.texi: Remove -flarge-source-files.
	* toplev.cc (process_options): Remove support for
	-flarge-source-files.





Change location_t to be a 64-bit integer instead of a 32-bit integer in
libcpp.

Also included in this change are the two other patches in the original
series which depended on this one; I am committing them all at once in case
it needs to be reverted later:

-Support for 64-bit location_t: gimple parts

The size of struct gimple increased by 8 bytes with the change in size of
location_t from 32- to 64-bit; adjust the WORD markings in the comments
accordingly. It seems that most of the WORD markings were off by one already,
probably not having been updated after a previous reduction in the size of a
gimple, so they have become retroactively correct again, and only a couple
needed adjustment actually.

Also add a comment that there is now 32 bits of unused padding available in
struct gimple for 64-bit hosts.

-Support for 64-bit location_t: Remove -flarge-source-files

The option -flarge-source-files became unnecessary with 64-bit location_t
and harms performance compared to the new default setting, so silently
ignore it.

libcpp/ChangeLog:

	* include/cpplib.h (struct cpp_token): Adjust comment about the
	struct size.
	* include/line-map.h (location_t): Change typedef from 32-bit to 64-bit
	integer.
	(LINE_MAP_MAX_COLUMN_NUMBER): Increase size to be appropriate for
	64-bit location_t.
	(LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES): Likewise.
	(LINE_MAP_MAX_LOCATION_WITH_COLS): Likewise.
	(LINE_MAP_MAX_LOCATION): Likewise.
	(MAX_LOCATION_T): Likewise.
	(line_map_suggested_range_bits): Likewise.
	(struct line_map): Adjust comment about the struct size.
	(struct line_map_macro): Likewise.
	(struct line_map_ordinary): Likewise. Rearrange fields to optimize
	padding.

gcc/testsuite/ChangeLog:

	* g++.dg/diagnostic/pr77949.C: Adapt the test for 64-bit location_t,
	when the previously expected failure doesn't actually happen.
	* g++.dg/modules/loc-prune-4.C: Adjust the expected output for the
	64-bit location_t case.
	* gcc.dg/plugin/expensive_selftests_plugin.cc: Don't try to test
	the maximum supported column number in 64-bit location_t mode.
	* gcc.dg/plugin/location_overflow_plugin.cc: Adjust the base_location
	so it can effectively test 64-bit location_t.

gcc/ChangeLog:

	* gimple.h (struct gphi): Update word marking comments to reflect
	the new size of location_t.
	(struct gimple): Likewise. Add a comment about padding.
	* common.opt: Mark -flarge-source-files as Ignored.
	* common.opt.urls: Regenerate.
	* doc/invoke.texi: Remove -flarge-source-files.
	* toplev.cc (process_options): Remove support for
	-flarge-source-files.







preprocessor: Adjust C rules on UCNs for C23 [PR117162]
2024-12-03T13:01:58+00:00

Joseph Myers
josmyers@redhat.com

2024-12-03T13:01:58+00:00

f3b5de944ad6d1f6a10f819b816c2ba234ecd8c0

As noted in bug 117162, C23 changed some rules on UCNs to match C++
(this was a late change agreed in the resolution to CD2 comment
US-032, implementing changes from N3124), which we need to implement.

Allow UCNs below 0xa0 outside identifiers for C, with a
pedwarn-if-pedantic before C23 (and a warning with -Wc11-c23-compat)
except for the always-allowed cases of UCNs for $ @ `.  Also as part
of that change, do not allow \u0024 in identifiers as equivalent to $
for C23.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

	PR c/117162

libcpp/
	* include/cpplib.h (struct cpp_options): Add low_ucns.
	* init.cc (struct lang_flags, lang_defaults): Add low_ucns.
	(cpp_set_lang): Set low_ucns
	* charset.cc (_cpp_valid_ucn): For C, allow UCNs below 0xa0
	outside identifiers, with a pedwarn if pedantic before C23 or a
	warning with -Wc11-c23-compat.  Do not allow \u0024 in identifiers
	for C23.

gcc/testsuite/
	* gcc.dg/cpp/c17-ucn-1.c, gcc.dg/cpp/c17-ucn-2.c,
	gcc.dg/cpp/c17-ucn-3.c, gcc.dg/cpp/c17-ucn-4.c,
	gcc.dg/cpp/c23-ucn-2.c, gcc.dg/cpp/c23-ucnid-2.c: New tests.
	* c-c++-common/cpp/delimited-escape-seq-3.c,
	c-c++-common/cpp/named-universal-char-escape-3.c,
	gcc.dg/cpp/c23-ucn-1.c, gcc.dg/cpp/c2y-delimited-escape-seq-3.c:
	Update expected messages
	* gcc.dg/cpp/ucs.c: Use -pedantic-errors.  Update expected
	messages.





As noted in bug 117162, C23 changed some rules on UCNs to match C++
(this was a late change agreed in the resolution to CD2 comment
US-032, implementing changes from N3124), which we need to implement.

Allow UCNs below 0xa0 outside identifiers for C, with a
pedwarn-if-pedantic before C23 (and a warning with -Wc11-c23-compat)
except for the always-allowed cases of UCNs for $ @ `.  Also as part
of that change, do not allow \u0024 in identifiers as equivalent to $
for C23.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

	PR c/117162

libcpp/
	* include/cpplib.h (struct cpp_options): Add low_ucns.
	* init.cc (struct lang_flags, lang_defaults): Add low_ucns.
	(cpp_set_lang): Set low_ucns
	* charset.cc (_cpp_valid_ucn): For C, allow UCNs below 0xa0
	outside identifiers, with a pedwarn if pedantic before C23 or a
	warning with -Wc11-c23-compat.  Do not allow \u0024 in identifiers
	for C23.

gcc/testsuite/
	* gcc.dg/cpp/c17-ucn-1.c, gcc.dg/cpp/c17-ucn-2.c,
	gcc.dg/cpp/c17-ucn-3.c, gcc.dg/cpp/c17-ucn-4.c,
	gcc.dg/cpp/c23-ucn-2.c, gcc.dg/cpp/c23-ucnid-2.c: New tests.
	* c-c++-common/cpp/delimited-escape-seq-3.c,
	c-c++-common/cpp/named-universal-char-escape-3.c,
	gcc.dg/cpp/c23-ucn-1.c, gcc.dg/cpp/c2y-delimited-escape-seq-3.c:
	Update expected messages
	* gcc.dg/cpp/ucs.c: Use -pedantic-errors.  Update expected
	messages.







c: Implement C2Y N3298 - Introduce complex literals [PR117029]
2024-11-13T08:41:41+00:00

Jakub Jelinek
jakub@redhat.com

2024-11-13T08:41:41+00:00

eb45d151fa1780d01533d9fc9545fec50bfd7152

The following patch implements the C2Y N3298 paper Introduce complex literals
by providing different (or no) diagnostics on imaginary constants (except
for integer ones).
For _DecimalN constants we don't support _Complex _DecimalN and error on any
i/j suffixes mixed with DD/DL/DF, so nothing changed there.

2024-11-13  Jakub Jelinek  <jakub@redhat.com>

	PR c/117029
libcpp/
	* include/cpplib.h (struct cpp_options): Add imaginary_constants
	member.
	* init.cc (struct lang_flags): Add imaginary_constants bitfield.
	(lang_defaults): Add column for imaginary_constants.
	(cpp_set_lang): Copy over imaginary_constants.
	* expr.cc (cpp_classify_number): Diagnose CPP_N_IMAGINARY
	non-CPP_N_FLOATING constants differently for C.
gcc/testsuite/
	* gcc.dg/cpp/pr7263-3.c: Adjust expected diagnostic wording.
	* gcc.dg/c23-imaginary-constants-1.c: New test.
	* gcc.dg/c23-imaginary-constants-2.c: New test.
	* gcc.dg/c23-imaginary-constants-3.c: New test.
	* gcc.dg/c23-imaginary-constants-4.c: New test.
	* gcc.dg/c23-imaginary-constants-5.c: New test.
	* gcc.dg/c23-imaginary-constants-6.c: New test.
	* gcc.dg/c23-imaginary-constants-7.c: New test.
	* gcc.dg/c23-imaginary-constants-8.c: New test.
	* gcc.dg/c23-imaginary-constants-9.c: New test.
	* gcc.dg/c23-imaginary-constants-10.c: New test.
	* gcc.dg/c2y-imaginary-constants-1.c: New test.
	* gcc.dg/c2y-imaginary-constants-2.c: New test.
	* gcc.dg/c2y-imaginary-constants-3.c: New test.
	* gcc.dg/c2y-imaginary-constants-4.c: New test.
	* gcc.dg/c2y-imaginary-constants-5.c: New test.
	* gcc.dg/c2y-imaginary-constants-6.c: New test.
	* gcc.dg/c2y-imaginary-constants-7.c: New test.
	* gcc.dg/c2y-imaginary-constants-8.c: New test.
	* gcc.dg/c2y-imaginary-constants-9.c: New test.
	* gcc.dg/c2y-imaginary-constants-10.c: New test.
	* gcc.dg/c2y-imaginary-constants-11.c: New test.
	* gcc.dg/c2y-imaginary-constants-12.c: New test.





The following patch implements the C2Y N3298 paper Introduce complex literals
by providing different (or no) diagnostics on imaginary constants (except
for integer ones).
For _DecimalN constants we don't support _Complex _DecimalN and error on any
i/j suffixes mixed with DD/DL/DF, so nothing changed there.

2024-11-13  Jakub Jelinek  <jakub@redhat.com>

	PR c/117029
libcpp/
	* include/cpplib.h (struct cpp_options): Add imaginary_constants
	member.
	* init.cc (struct lang_flags): Add imaginary_constants bitfield.
	(lang_defaults): Add column for imaginary_constants.
	(cpp_set_lang): Copy over imaginary_constants.
	* expr.cc (cpp_classify_number): Diagnose CPP_N_IMAGINARY
	non-CPP_N_FLOATING constants differently for C.
gcc/testsuite/
	* gcc.dg/cpp/pr7263-3.c: Adjust expected diagnostic wording.
	* gcc.dg/c23-imaginary-constants-1.c: New test.
	* gcc.dg/c23-imaginary-constants-2.c: New test.
	* gcc.dg/c23-imaginary-constants-3.c: New test.
	* gcc.dg/c23-imaginary-constants-4.c: New test.
	* gcc.dg/c23-imaginary-constants-5.c: New test.
	* gcc.dg/c23-imaginary-constants-6.c: New test.
	* gcc.dg/c23-imaginary-constants-7.c: New test.
	* gcc.dg/c23-imaginary-constants-8.c: New test.
	* gcc.dg/c23-imaginary-constants-9.c: New test.
	* gcc.dg/c23-imaginary-constants-10.c: New test.
	* gcc.dg/c2y-imaginary-constants-1.c: New test.
	* gcc.dg/c2y-imaginary-constants-2.c: New test.
	* gcc.dg/c2y-imaginary-constants-3.c: New test.
	* gcc.dg/c2y-imaginary-constants-4.c: New test.
	* gcc.dg/c2y-imaginary-constants-5.c: New test.
	* gcc.dg/c2y-imaginary-constants-6.c: New test.
	* gcc.dg/c2y-imaginary-constants-7.c: New test.
	* gcc.dg/c2y-imaginary-constants-8.c: New test.
	* gcc.dg/c2y-imaginary-constants-9.c: New test.
	* gcc.dg/c2y-imaginary-constants-10.c: New test.
	* gcc.dg/c2y-imaginary-constants-11.c: New test.
	* gcc.dg/c2y-imaginary-constants-12.c: New test.







c++: Attempt to implement C++26 P3034R1 - Module Declarations Shouldn't be Macros [PR114461]
2024-11-01T18:42:28+00:00

Jakub Jelinek
jakub@redhat.com

2024-11-01T18:42:28+00:00

1ae24f7e0bdbdeaef9265a053a737af11f8393d2

This is an attempt to implement the https://wg21.link/p3034r1 paper,
but I'm afraid the wording in the paper is bad for multiple reasons.
I think I understand the intent, that the module name and partition
if any shouldn't come from macros so that they can be scanned for
without preprocessing, but on the other side doesn't want to disable
macro expansion in pp-module altogether, because e.g. the optional
attribute in module-declaration would be nice to come from macros
as which exact attribute is needed might need to be decided based on
preprocessor checks.
The paper added https://eel.is/c++draft/cpp.module#2
which uses partly the wording from https://eel.is/c++draft/cpp.module#1

The first issue I see is that using that "defined as an object-like macro"
from there means IMHO something very different in those 2 paragraphs.
As per https://eel.is/c++draft/cpp.pre#7.sentence-1 preprocessing tokens
in preprocessing directives aren't subject to macro expansion unless
otherwise stated, and so the export and module tokens aren't expanded
and so the requirement that they aren't defined as an object-like macro
makes perfect sense.  The problem with the new paragraph is that
https://eel.is/c++draft/cpp.module#3.sentence-1 says that the rest of
the tokens are macro expanded and after macro expansion none of the
tokens can be defined as an object-like macro, if they would be, they'd
be expanded to that.  So, I think either the wording needs to change
such that not all preprocessing tokens after module are macro expanded,
only those which are after the pp-module-name and if any pp-module-partition
tokens, or all tokens after module are macro expanded but none of the tokens in
pp-module-name and pp-module-partition if any must come from macro
expansion.  The patch below implements it as if the former would be
specified (but see later), so essentially scans the preprocessing tokens
after module without expansion, if the first one is an identifier, it
disables expansion for it and then if followed by . or : expects another
such identifier (again with disabled expansion), but stops after second
: is seen.

Second issue is that while the global-module-fragment start is fine, matches
the syntax of the new paragraph where the pp-tokens[opt] aren't present,
there is also private-module-fragment in the syntax where module is
followed by : private ; and in that case the colon doesn't match the
pp-module-name grammar and appears now to be invalid.  I think the
https://eel.is/c++draft/cpp.module#2
paragraph needs to change so that it allows also that pp-tokens of
a pp-module may also be : pp-tokens[opt] (and in that case, I think
the colon shouldn't come from a macro and private and/or ; can).

Third issue is that there are too many pp-tokens in
https://eel.is/c++draft/cpp.module , one is all the tokens between
module keyword and the semicolon and one is the optional extra tokens
after pp-module-partition (if any, if missing, after pp-module).
Perhaps introducing some other non-terminal would help talking about it?
So in "where the pp-tokens (if any) shall not begin with a ( preprocessing
token" it isn't obvious which pp-tokens it is talking about (my assumption
is the latter) and also whether ( can't appear there just before macro
expansion or also after expansion.  The patch expects only before expansion,
so
 #define F ();
 export module foo F
would be valid during preprocessing but obviously invalid during
compilation, but
 #define foo(n) n;
 export module foo (3)
would be invalid already during preprocessing.

The last issue applies only if the first issue is resolved to allow
expansion of tokens after : if first token, or after pp-module-partition
if present or after pp-module-name if present.  When non-preprocessing
scanner sees
 export module foo.bar:baz.qux;
it knows nothing can come from preprocessing macros and is ok, but if it
sees
 export module foo.bar:baz qux
then it can't know whether it will be
 export module foo.bar:baz;
or
 export module foo.bar:baz [[]];
or
 export module foo.bar:baz.freddy.garply;
because qux could be validly a macro, which expands to ; or [[]];
or .freddy.garply; etc.  So, either the non-preprocessing scanner would
need to note it as possible export of foo.bar:baz* module partitions
and preprocess if it needs to know the details or just compile, or if that
is not ok, the wording would need to rule out that the expansion of (the
second) pp-tokens if any can't start with . or : (colon would be only
problematic if it isn't present in the tokens before it already).
So, if e.g. defining qux above to . whatever is invalid, then the scanner
can rely it sees the whole module name and partition.

The patch below implements what is above described as the first variant
of the first issue resolution, i.e. disables expansion of as many tokens
as could be in the valid module name and module partition syntax, but
as soon as it e.g. sees two adjacent identifiers, the second one can be
macro expanded.  If it is macro expanded though, the expansion can't
start with . or :, and if it expands to nothing, tokens after it (whether
they come from macro expansion or not) can't start with . or :.
So, effectively:
 #define SEMI ;
 export module SEMI
used to be valid and isn't anymore,
 #define FOO bar
 export module FOO;
isn't valid,
 #define COLON :
 export module COLON private;
isn't valid,
 #define BAR baz
 export module foo.bar:baz.qux.BAR;
isn't valid,
 #define BAZ .qux
 export module foo BAZ;
isn't valid,
 #define FREDDY :garply
 export module foo FREDDY;
isn't valid,
while
 #define QUX [[]]
 export module foo QUX;
or
 #define GARPLY private
 module : GARPLY;
etc. is.

2024-11-01  Jakub Jelinek  <jakub@redhat.com>

	PR c++/114461
libcpp/
	* include/cpplib.h: Implement C++26 P3034R1
	- Module Declarations Shouldn’t be Macros (or more precisely
	its expected intent).
	(NO_DOT_COLON): Define.
	* internal.h (struct cpp_reader): Add diagnose_dot_colon_from_macro_p
	member.
	* lex.cc (cpp_maybe_module_directive): For pp-module, if
	module keyword is followed by CPP_NAME, ensure all CPP_NAME
	tokens possibly matching module name and module partition
	syntax aren't expanded and aren't defined as object-like macros.
	Verify first token after that doesn't start with open paren.
	If the next token after module name/partition is CPP_NAME defined
	as macro, set NO_DOT_COLON flag on it.
	* macro.cc (cpp_get_token_1): Set
	pfile->diagnose_dot_colon_from_macro_p if token to be expanded has
	NO_DOT_COLON bit set in flags.  Before returning, if
	pfile->diagnose_dot_colon_from_macro_p is true and not returning
	CPP_PADDING or CPP_COMMENT and not during macro expansion preparation,
	set pfile->diagnose_dot_colon_from_macro_p to false and diagnose
	if returning CPP_DOT or CPP_COLON.
gcc/testsuite/
	* g++.dg/modules/cpp-7.C: New test.
	* g++.dg/modules/cpp-8.C: New test.
	* g++.dg/modules/cpp-9.C: New test.
	* g++.dg/modules/cpp-10.C: New test.
	* g++.dg/modules/cpp-11.C: New test.
	* g++.dg/modules/cpp-12.C: New test.
	* g++.dg/modules/cpp-13.C: New test.
	* g++.dg/modules/cpp-14.C: New test.
	* g++.dg/modules/cpp-15.C: New test.
	* g++.dg/modules/cpp-16.C: New test.
	* g++.dg/modules/cpp-17.C: New test.
	* g++.dg/modules/cpp-18.C: New test.
	* g++.dg/modules/cpp-19.C: New test.
	* g++.dg/modules/cpp-20.C: New test.
	* g++.dg/modules/pmp-4.C: New test.
	* g++.dg/modules/pmp-5.C: New test.
	* g++.dg/modules/pmp-6.C: New test.
	* g++.dg/modules/token-6.C: New test.
	* g++.dg/modules/token-7.C: New test.
	* g++.dg/modules/token-8.C: New test.
	* g++.dg/modules/token-9.C: New test.
	* g++.dg/modules/token-10.C: New test.
	* g++.dg/modules/token-11.C: New test.
	* g++.dg/modules/token-12.C: New test.
	* g++.dg/modules/token-13.C: New test.
	* g++.dg/modules/token-14.C: New test.
	* g++.dg/modules/token-15.C: New test.
	* g++.dg/modules/token-16.C: New test.
	* g++.dg/modules/dir-only-3.C: Expect an error.
	* g++.dg/modules/dir-only-4.C: Expect an error.
	* g++.dg/modules/dir-only-5.C: New test.
	* g++.dg/modules/atom-preamble-2_a.C: In export module malcolm;
	replace malcolm with kevin.  Don't define malcolm macro.
	* g++.dg/modules/atom-preamble-4.C: Expect an error.
	* g++.dg/modules/atom-preamble-5.C: New test.





This is an attempt to implement the https://wg21.link/p3034r1 paper,
but I'm afraid the wording in the paper is bad for multiple reasons.
I think I understand the intent, that the module name and partition
if any shouldn't come from macros so that they can be scanned for
without preprocessing, but on the other side doesn't want to disable
macro expansion in pp-module altogether, because e.g. the optional
attribute in module-declaration would be nice to come from macros
as which exact attribute is needed might need to be decided based on
preprocessor checks.
The paper added https://eel.is/c++draft/cpp.module#2
which uses partly the wording from https://eel.is/c++draft/cpp.module#1

The first issue I see is that using that "defined as an object-like macro"
from there means IMHO something very different in those 2 paragraphs.
As per https://eel.is/c++draft/cpp.pre#7.sentence-1 preprocessing tokens
in preprocessing directives aren't subject to macro expansion unless
otherwise stated, and so the export and module tokens aren't expanded
and so the requirement that they aren't defined as an object-like macro
makes perfect sense.  The problem with the new paragraph is that
https://eel.is/c++draft/cpp.module#3.sentence-1 says that the rest of
the tokens are macro expanded and after macro expansion none of the
tokens can be defined as an object-like macro, if they would be, they'd
be expanded to that.  So, I think either the wording needs to change
such that not all preprocessing tokens after module are macro expanded,
only those which are after the pp-module-name and if any pp-module-partition
tokens, or all tokens after module are macro expanded but none of the tokens in
pp-module-name and pp-module-partition if any must come from macro
expansion.  The patch below implements it as if the former would be
specified (but see later), so essentially scans the preprocessing tokens
after module without expansion, if the first one is an identifier, it
disables expansion for it and then if followed by . or : expects another
such identifier (again with disabled expansion), but stops after second
: is seen.

Second issue is that while the global-module-fragment start is fine, matches
the syntax of the new paragraph where the pp-tokens[opt] aren't present,
there is also private-module-fragment in the syntax where module is
followed by : private ; and in that case the colon doesn't match the
pp-module-name grammar and appears now to be invalid.  I think the
https://eel.is/c++draft/cpp.module#2
paragraph needs to change so that it allows also that pp-tokens of
a pp-module may also be : pp-tokens[opt] (and in that case, I think
the colon shouldn't come from a macro and private and/or ; can).

Third issue is that there are too many pp-tokens in
https://eel.is/c++draft/cpp.module , one is all the tokens between
module keyword and the semicolon and one is the optional extra tokens
after pp-module-partition (if any, if missing, after pp-module).
Perhaps introducing some other non-terminal would help talking about it?
So in "where the pp-tokens (if any) shall not begin with a ( preprocessing
token" it isn't obvious which pp-tokens it is talking about (my assumption
is the latter) and also whether ( can't appear there just before macro
expansion or also after expansion.  The patch expects only before expansion,
so
 #define F ();
 export module foo F
would be valid during preprocessing but obviously invalid during
compilation, but
 #define foo(n) n;
 export module foo (3)
would be invalid already during preprocessing.

The last issue applies only if the first issue is resolved to allow
expansion of tokens after : if first token, or after pp-module-partition
if present or after pp-module-name if present.  When non-preprocessing
scanner sees
 export module foo.bar:baz.qux;
it knows nothing can come from preprocessing macros and is ok, but if it
sees
 export module foo.bar:baz qux
then it can't know whether it will be
 export module foo.bar:baz;
or
 export module foo.bar:baz [[]];
or
 export module foo.bar:baz.freddy.garply;
because qux could be validly a macro, which expands to ; or [[]];
or .freddy.garply; etc.  So, either the non-preprocessing scanner would
need to note it as possible export of foo.bar:baz* module partitions
and preprocess if it needs to know the details or just compile, or if that
is not ok, the wording would need to rule out that the expansion of (the
second) pp-tokens if any can't start with . or : (colon would be only
problematic if it isn't present in the tokens before it already).
So, if e.g. defining qux above to . whatever is invalid, then the scanner
can rely it sees the whole module name and partition.

The patch below implements what is above described as the first variant
of the first issue resolution, i.e. disables expansion of as many tokens
as could be in the valid module name and module partition syntax, but
as soon as it e.g. sees two adjacent identifiers, the second one can be
macro expanded.  If it is macro expanded though, the expansion can't
start with . or :, and if it expands to nothing, tokens after it (whether
they come from macro expansion or not) can't start with . or :.
So, effectively:
 #define SEMI ;
 export module SEMI
used to be valid and isn't anymore,
 #define FOO bar
 export module FOO;
isn't valid,
 #define COLON :
 export module COLON private;
isn't valid,
 #define BAR baz
 export module foo.bar:baz.qux.BAR;
isn't valid,
 #define BAZ .qux
 export module foo BAZ;
isn't valid,
 #define FREDDY :garply
 export module foo FREDDY;
isn't valid,
while
 #define QUX [[]]
 export module foo QUX;
or
 #define GARPLY private
 module : GARPLY;
etc. is.

2024-11-01  Jakub Jelinek  <jakub@redhat.com>

	PR c++/114461
libcpp/
	* include/cpplib.h: Implement C++26 P3034R1
	- Module Declarations Shouldn’t be Macros (or more precisely
	its expected intent).
	(NO_DOT_COLON): Define.
	* internal.h (struct cpp_reader): Add diagnose_dot_colon_from_macro_p
	member.
	* lex.cc (cpp_maybe_module_directive): For pp-module, if
	module keyword is followed by CPP_NAME, ensure all CPP_NAME
	tokens possibly matching module name and module partition
	syntax aren't expanded and aren't defined as object-like macros.
	Verify first token after that doesn't start with open paren.
	If the next token after module name/partition is CPP_NAME defined
	as macro, set NO_DOT_COLON flag on it.
	* macro.cc (cpp_get_token_1): Set
	pfile->diagnose_dot_colon_from_macro_p if token to be expanded has
	NO_DOT_COLON bit set in flags.  Before returning, if
	pfile->diagnose_dot_colon_from_macro_p is true and not returning
	CPP_PADDING or CPP_COMMENT and not during macro expansion preparation,
	set pfile->diagnose_dot_colon_from_macro_p to false and diagnose
	if returning CPP_DOT or CPP_COLON.
gcc/testsuite/
	* g++.dg/modules/cpp-7.C: New test.
	* g++.dg/modules/cpp-8.C: New test.
	* g++.dg/modules/cpp-9.C: New test.
	* g++.dg/modules/cpp-10.C: New test.
	* g++.dg/modules/cpp-11.C: New test.
	* g++.dg/modules/cpp-12.C: New test.
	* g++.dg/modules/cpp-13.C: New test.
	* g++.dg/modules/cpp-14.C: New test.
	* g++.dg/modules/cpp-15.C: New test.
	* g++.dg/modules/cpp-16.C: New test.
	* g++.dg/modules/cpp-17.C: New test.
	* g++.dg/modules/cpp-18.C: New test.
	* g++.dg/modules/cpp-19.C: New test.
	* g++.dg/modules/cpp-20.C: New test.
	* g++.dg/modules/pmp-4.C: New test.
	* g++.dg/modules/pmp-5.C: New test.
	* g++.dg/modules/pmp-6.C: New test.
	* g++.dg/modules/token-6.C: New test.
	* g++.dg/modules/token-7.C: New test.
	* g++.dg/modules/token-8.C: New test.
	* g++.dg/modules/token-9.C: New test.
	* g++.dg/modules/token-10.C: New test.
	* g++.dg/modules/token-11.C: New test.
	* g++.dg/modules/token-12.C: New test.
	* g++.dg/modules/token-13.C: New test.
	* g++.dg/modules/token-14.C: New test.
	* g++.dg/modules/token-15.C: New test.
	* g++.dg/modules/token-16.C: New test.
	* g++.dg/modules/dir-only-3.C: Expect an error.
	* g++.dg/modules/dir-only-4.C: Expect an error.
	* g++.dg/modules/dir-only-5.C: New test.
	* g++.dg/modules/atom-preamble-2_a.C: In export module malcolm;
	replace malcolm with kevin.  Don't define malcolm macro.
	* g++.dg/modules/atom-preamble-4.C: Expect an error.
	* g++.dg/modules/atom-preamble-5.C: New test.