Since the standard library doesn't preclude an #include of a standard
library header from bringing in declarations from other headers, we can
translate an #include of any of the importable headers as an import of
<bits/stdc++.h>.
To reduce the amount of C++ standard knowledge encoded in libcpp, I extend
the translate_include callback to allow it to suggest an alternate header to
try translating. It's a bit awkward to bounce back and forth, but this
seems like the right division of responsibilities.
libcpp/ChangeLog:
* include/cpplib.h (struct cpp_callbacks): Replace 'path' parameter
with file, angle_brackets, and alternate name.
(cpp_get_name): Declare.
* files.cc (cpp_get_name): New.
(_cpp_stack_include, _cpp_post_stack_file, _cpp_stack_file)
(_cpp_stack_translated_file): Refactor, try alternate file.
gcc/cp/ChangeLog:
* module.cc (maybe_translate_include): Suggest <bits/stdc++.h>
as an alternate for importable standard library headers.
(importable_headers, is_importable_header): New.
gcc/ChangeLog:
* doc/invoke.texi (C++ Modules): Remove standard library header
units from missing pieces, mention importable header redirection.
gcc/testsuite/ChangeLog:
* g++.dg/modules/compile-std1.C: Test <vector> translation.
Back in r78875 mrs added cpp_get_path/dir accessors for _cpp_file in order
to interface with the darwin framework system. But now I notice that the
latter duplicates the better-named _cpp_get_file_dir, and I'm inclined to
rename the former to match.
Perhaps we should drop the initial underscore since these are no
longer internal interfaces; OTOH, _cpp_hashnode_value and
_cpp_backup_tokens still have the initial underscore in cpplib.h.
libcpp/ChangeLog:
* include/cpplib.h (cpp_get_path, cpp_get_dir): Remove.
(_cpp_get_file_path, _cpp_get_file_name, _cpp_get_file_stat)
(_cpp_get_file_dir): Move prototypes from...
* internal.h: ...here.
* files.cc (_cpp_get_file_path): Rename from...
(cpp_get_path): ...this.
(cpp_get_dir): Remove.
gcc/ChangeLog:
* config/darwin-c.cc (find_subframework_header): Use
_cpp_get_file_*.
The following patch implements CWG3053 approved in Kona, where it is now
valid not just to #define likely(a) or #define unlikely(a, b, c) but also
to #undef likely or #undef unlikely.
2025-11-10 Jakub Jelinek <jakub@redhat.com>
libcpp/
* directives.cc: Implement CWG3053.
(do_undef): Don't pedwarn or warn about #undef likely or #undef
unlikely.
gcc/testsuite/
* g++.dg/warn/Wkeyword-macro-4.C: Don't diagnose for #undef likely
or #undef unlikely.
* g++.dg/warn/Wkeyword-macro-5.C: Likewise.
* g++.dg/warn/Wkeyword-macro-9.C: Likewise.
* g++.dg/warn/Wkeyword-macro-8.C: Likewise.
* g++.dg/warn/Wkeyword-macro-10.C: Likewise.
It is permissible to define macros prior to including a PCH, as long as
these definitions are disjoint from or identical to the macros in the
PCH. The PCH loading process replaces all libcpp data structures with those
from the PCH, so it is necessary to remember the extra macros separately and
then restore them after loading the PCH, which all is handled by
cpp_save_state() and cpp_read_state() in libcpp/pch.cc. The restoration
process consists of pushing a buffer containing the macro definition and
then lexing it from there, similar to how a command-line -D option is
processed. The current implementation does not attempt to set up the
line_map for this process, and so the locations assigned to the macros are
often not meaningful. (Similar to what happened in the past with lexing the
tokens out of a _Pragma string, lexing out of a buffer rather than a file
produces "sorta" reasonable locations that are often close enough, but not
reliably correct.)
Fix that up by remembering enough additional information (more or less, an
expanded_location for each macro definition) to produce a reasonable
location for the newly restored macros.
One issue that came up is the treatment of command-line-defined macros. From
the perspective of the generic line_map data structures, the command-line
location is not distinguishable from other locations; it's just an ordinary
location created by the front ends with a fake file name by convention. (At
the moment, it is always the string `<command-line>', subject to
translation.) Since libcpp needs to assign macros to that location, it
needs to know what location to use, so I added a new member
line_maps::cmdline_location for the front ends to set, similar to how
line_maps::builtin_location is handled.
This revealed a small issue, in c-opts.cc we have:
/* All command line defines must have the same location. */
cpp_force_token_locations (parse_in, line_table->highest_line);
But contrary to the comment, all command line defines don't actually end up
with the same location anymore. This is because libcpp/lex.cc has been
expanded (r6-4873) to include range information on the returned
locations. That logic has never been respecting the request of
cpp_force_token_locations. I believe this was not intentional, and so I have
corrected that here. Prior to this patch, the range logic has been leading
to command-line macros all having similar locations in the same line map (or
ad-hoc locations based from there for sufficiently long tokens); with this
change, they all have exactly the same location and that location is
recorded in line_maps::cmdline_location.
With that change, then it works fine for pch.cc to restore macros whether
they came from the command-line or from the main file.
gcc/c-family/ChangeLog:
PR preprocessor/105608
* c-opts.cc (c_finish_options): Set new member
line_table->cmdline_location.
* c-pch.cc (c_common_read_pch): Adapt linemap usage to changes in
libcpp pch.cc; it is now possible that the linemap is in a different
file after returning from cpp_read_state().
libcpp/ChangeLog:
PR preprocessor/105608
* include/line-map.h: Add new member CMDLINE_LOCATION.
* lex.cc (get_location_for_byte_range_in_cur_line): Do not expand
the token location to include range information if token location
override was requested.
(warn_about_normalization): Likewise.
(_cpp_lex_direct): Likewise.
* pch.cc (struct saved_macro): New local struct.
(struct save_macro_data): Change DEFNS vector to hold saved_macro
rather than uchar*.
(save_macros): Adapt to remember the location information for each
saved macro in addition to the definition.
(cpp_prepare_state): Likewise.
(cpp_read_state): Use the saved location information to generate
proper locations for the restored macros.
gcc/testsuite/ChangeLog:
PR preprocessor/105608
* g++.dg/pch/line-map-3.C: Remove xfails.
* g++.dg/pch/line-map-4.C: New test.
* g++.dg/pch/line-map-4.Hs: New test.
In traditional CPP mode (-save-temps, -no-integrated-cpp, etc.), the
compilation directory is conveyed to cc1 using a line such as:
# <line> "/path/name//"
This string literal can contain escape sequences, for instance, if the
original source file was compiled in "/tmp/a\b", then this line will be:
# <line> "/tmp/a\\b//"
So reading the compilation directory must decode escape sequences. This
last part is currently missing and this patch implements it.
libcpp/
* init.cc (read_original_directory): Attempt to decode escape
sequences with cpp_interpret_string_notranslate.
The following patch updates GCC from Unicode 16.0.0 to 17.0.0.
I've followed what the README says and updated also one script from
glibc, but that needed another Unicode file - HangulSyllableType.txt -
around as well, so I'm adding it.
I've added one new test to named-universal-char-escape-1.c for
randomly chosen character from new CJK block.
Note, Unicode 17.0.0 authors forgot to adjust the 4-8 table, I've filed
bugreports about that but the UnicodeData.txt changes for the range ends
and the new range seems to match e.g. what is in the glyph tables, so
the patch follows UnicodeData.txt and not 4-8 table here.
Another thing was that makeuname2c.cc didn't handle correctly when
the size of the generated string table modulo 77 was 76 or 77, in which
case it forgot to emit a semicolon after the string literal and so failed
to compile.
And as can be seen in the emoji-data.txt diff, some properties like
Extended_Pictographic have been removed from certain characters, e.g.
from the Mahjong cards characters except U+1F004, and one libstdc++
test was testing that property exactly on U+1F000. Dunno why that was
changed, but U+1F004 is the only colored one among tons of black and white
ones.
2025-10-08 Jakub Jelinek <jakub@redhat.com>
contrib/
* unicode/README: Add HangulSyllableType.txt file to the
list as newest utf8_gen.py from glibc now needs it. Adjust
git commit hash and change unicode 16 version to 17.
* unicode/from_glibc/utf8_gen.py: Updated from glibc.
* unicode/DerivedCoreProperties.txt: Updated from Unicode 17.0.0.
* unicode/emoji-data.txt: Likewise.
* unicode/PropList.txt: Likewise.
* unicode/GraphemeBreakProperty.txt: Likewise.
* unicode/DerivedNormalizationProps.txt: Likewise.
* unicode/NameAliases.txt: Likewise.
* unicode/UnicodeData.txt: Likewise.
* unicode/EastAsianWidth.txt: Likewise.
* unicode/DerivedGeneralCategory.txt: Likewise.
* unicode/HangulSyllableType.txt: New file.
gcc/testsuite/
* c-c++-common/cpp/named-universal-char-escape-1.c: Add test for
\N{CJK UNIFIED IDEOGRAPH-3340E}.
libcpp/
* makeucnid.cc (write_copyright): Adjust copyright year.
* makeuname2c.cc (generated_ranges): Adjust end points for a couple
of ranges based on UnicodeData.txt Last changes and add a whole new
CJK UNIFIED IDEOGRAPH- entry. None of these changes are in the 4-8
table, but clearly it has just been forgotten.
(write_copyright): Adjust copyright year.
(write_dict): Fix up condition when to print semicolon.
* generated_cpp_wcwidth.h: Regenerate.
* ucnid.h: Regenerate.
* uname2c.h: Regenerate.
libstdc++-v3/
* include/bits/unicode-data.h: Regenerate.
* testsuite/ext/unicode/properties.cc: Test __is_extended_pictographic
on U+1F004 rather than U+1F000.
SARIF "fix" objects SHOULD have a "description" property (§3.55.2) that
describes the proposed fix, but currently GCC's SARIF output doesn't
support this, and we don't capture this anywhere internally as we build
fix-it hints in the compiler.
Currently we can have zero or more instances of fixit_hint associated
with a diagnostic, each representing an edit of a range of the source
code. Ideally we would have an internal API that allowed for associating
multiple fixes with a diagnostic, each with a description worded in terms
of the source language (e.g. "Fix 'colour' mispelling of field 'color'"),
and each consisting of multiple edited ranges.
For now, this patch extends the sarif output sink so that it
autogenerates descriptions of fix-it hints for simple cases of
insertion, deletion, and replacement of a single range
(e.g. "Replace 'colour' with 'color'").
gcc/ChangeLog:
PR diagnostics/121986
* diagnostics/sarif-sink.cc: Include "intl.h".
(sarif_builder::make_message_describing_fix_it_hint): New.
(sarif_builder::make_fix_object): Attempt to auto-generate a
description for fix-it hints.
gcc/testsuite/ChangeLog:
PR diagnostics/121986
* gcc.dg/sarif-output/extra-semicolon.c: New test.
* gcc.dg/sarif-output/extra-semicolon.py: New test.
* gcc.dg/sarif-output/missing-semicolon.py: Verify the description
of the insertion fix-it hint.
* libgdiagnostics.dg/test-fix-it-hint-c.py: Verify the description
of the replacement fix-it hint.
libcpp/ChangeLog:
PR diagnostics/121986
* include/rich-location.h (fixit_hint::deletion_p): New accessor.
(fixit_hint::replacement_p): New accessor.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
The following patch implements the
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3457.htm
paper without the first 3 lines in Recommended practice.
Seems GCC behavior already matches the expected behavior except for
diagnostics of more than 2147483648 __COUNTER__ expansions, so the
patch adds a diagnostic for that (but not testcase because
#define A __COUNTER__ __COUNTER__ __COUNTER__ __COUNTER__ __COUNTER__ __COUNTER__ __COUNTER__ __COUNTER__
#define B A A A A A A A A
#define C B B B B B B B B
#define D C C C C C C C C
#define E D D D D D D D D
#define F E E E E E E E E
#define G F F F F F F F F
#define H G G G G G G G G
#define I H H H H H H H H
#define J I I I I I I I I
J J J J
__COUNTER__
just takes too long to preprocess).
Plus I've included all the snippets from the paper into one testcase.
2025-09-01 Jakub Jelinek <jakub@redhat.com>
* macro.cc: Implement C2Y N3457 - The __COUNTER__ predefined macro.
(_cpp_builtin_macro_text): Diagnose if __COUNTER__ reaches
2147483648 value.
* gcc.dg/cpp/c2y-counter-1.c: New test.
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).
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.
Another easy part from the paper.
Part of the CWG2579 has been already done in an earlier paper (with
test commits by Marek) and the remaining part is implemented correctly,
we diagnose as error when token pasting doesn't form a valid token.
Except that message
pasting """" and """" does not give a valid preprocessing token
looked weird and so I've updated the message to use %< and %> instead
of \" quoting.
2025-08-05 Jakub Jelinek <jakub@redhat.com>
PR preprocessor/120778
* macro.cc (paste_tokens): Use %< and %> instead of \" in
diagnostics around %.*s.
* g++.dg/DRs/dr2579.C: New test.
* c-c++-common/cpp/va-opt-6.c: Expect ' rather than \" around
tokens in incorrect pasting diagnostics.
* gcc.dg/c23-attr-syntax-6.c: Likewise.
* gcc.dg/cpp/paste12.c: Likewise.
* gcc.dg/cpp/paste12-2.c: Likewise.
* gcc.dg/cpp/paste14.c: Likewise.
* gcc.dg/cpp/paste14-2.c: Likewise.
This is another case which changed from compile time undefined behavior
to ill-formed, diagnostic required. Now, we warn on this, so pedantically
that is good enough, maybe all we need is a testcase, but the following
patch changes it to a pedwarn for C++26.
2025-08-04 Jakub Jelinek <jakub@redhat.com>
PR preprocessor/120778
* macro.cc (stringify_arg): For C++26 emit a pedarn instead of warning
for \ at the end of stringification.
* g++.dg/DRs/dr2578.C: New test.
My changes for "Module Declarations Shouldn’t be Macros" paper broke
the following testcase. The backup handling intentionally tries to
drop CPP_PRAGMA_EOL token if things go wrong, which is desirable for the
case where we haven't committed to the module preprocessing directive
(i.e. changed the first token to the magic one). In that case there is
no preprocessing directive start and so CPP_PRAGMA_EOL would be wrong.
If there is a premature new-line after we've changed the first token though,
we shouldn't drop CPP_PRAGMA_EOL, because otherwise we ICE in the FE.
While clang++ and MSVC accept the testcase, in my reading it is incorrect
at least in the C++23 and newer wordings and I think the changes have been
a DR, https://eel.is/c++draft/cpp.module has no exception for new-lines
and https://eel.is/c++draft/cpp.pre#1.sentence-2 says that new-line (unless
deleted during phase 2 when after backslash) ends the preprocessing
directive.
The patch arranges for eol being set only in the not_module case.
2025-08-03 Jakub Jelinek <jakub@redhat.com>
PR c++/120845
libcpp/
* lex.cc (cpp_maybe_module_directive): Move eol variable declaration
to the start of the function, initialize to false and only set it to
peek->type == CPP_PRAGMA_EOL in the not_module case. Formatting fix.
gcc/testsuite/
* g++.dg/modules/cpp-21.C: New test.
The P2843R3 Preprocessing is never undefined paper contains comments
that various compilers handle comma operators in preprocessor expressions
incorrectly and I think they are right.
In both C and C++ the grammar uses constant-expression non-terminal
for #if/#elif and in both C and C++ that NT is conditional-expression,
so
#if 1, 2
is IMHO clearly wrong in both languages.
C89 then says for constant-expression
"Constant expressions shall not contain assignment, increment, decrement,
function-call, or comma operators, except when they are contained within the
operand of a sizeof operator."
Because all the remaining identifiers in the #if/#elif expression are
replaced with 0 I think assignments, increment, decrement and function-call
aren't that big deal because (0 = 1) or ++4 etc. are all invalid, but
for comma expressions I think it matters. In r0-56429 PR456 Joseph has
added !CPP_OPTION (pfile, c99) to handle that correctly.
Then C99 changed that to:
"Constant expressions shall not contain assignment, increment, decrement, function-call,
or comma operators, except when they are contained within a subexpression that is not
evaluated."
That made for C99+
#if 1 || (1, 2)
etc. valid but
#if (1, 2)
is still invalid, ditto
#if 1 ? 1, 2 : 3
In C++ I can't find anything like that though, and as can be seen on say
int a[(1, 2)];
int b[1 ? 1, 2 : 3];
being accepted by C++ and rejected by C while
int c[1, 2];
int d[1 ? 2 : 3, 4];
being rejected in both C and C++, so I think for C++ it is indeed just the
grammar that prevents #if 1, 2. When it is the second operand of ?: or
inside of () the grammar just uses expression and that allows comma
operator.
So, the following patch uses different decisions for C++ when to diagnose
comma operator in preprocessor expressions, for C++ tracks if it is inside
of () (obviously () around #embed clauses don't count unless one uses
limit ((1, 2)) etc.) or inside of the second ?: operand and allows comma
operator there and disallows elsewhere.
BTW, I wonder if anything in the standard disallows <=> in the preprocessor
expressions. Say
#if (0 <=> 1) < 0
etc.
#include <compare>
constexpr int a = (0 <=> 1) < 0;
is valid (but not valid without #include <compare>) and the expressions
don't use any identifiers.
2025-07-30 Jakub Jelinek <jakub@redhat.com>
PR c++/120778
* internal.h (struct lexer_state): Add comma_ok member.
* expr.cc (_cpp_parse_expr): Initialize it to 0, increment on
CPP_OPEN_PAREN and CPP_QUERY, decrement on CPP_CLOSE_PAREN
and CPP_COLON.
(num_binary_op): For C++ pedwarn on comma operator if
pfile->state.comma_ok is 0 instead of !c99 or skip_eval.
* g++.dg/cpp/if-comma-1.C: New test.
To respect the #pragma diagnostic lines in libstdc++ headers when compiling
with module std, we need to represent them in the module.
I think it's reasonable to give serializers direct access to the underlying
data, as here with get_classification_history. This is a different approach
from how Jakub made PCH streaming members of diagnostic_option_classifier,
but it seems to me that modules handling belongs in module.cc.
libcpp/ChangeLog:
* line-map.cc (linemap_location_from_module_p): Add.
* include/line-map.h: Declare it.
gcc/ChangeLog:
* diagnostic.h (diagnostic_option_classifier): Friend
diagnostic_context.
(diagnostic_context::get_classification_history): New.
gcc/cp/ChangeLog:
* module.cc (module_state::write_diagnostic_classification): New.
(module_state::write_begin): Call it.
(module_state::read_diagnostic_classification): New.
(module_state::read_initial): Call it.
(dk_string, dump_dc_change): New.
gcc/testsuite/ChangeLog:
* g++.dg/modules/warn-spec-3_a.C: New test.
* g++.dg/modules/warn-spec-3_b.C: New test.
* g++.dg/modules/warn-spec-3_c.C: New test.
This patch to the "experimental-html" diagnostic sink:
* adds use of the PatternFly 3 CSS library (via an optional link
in the generated html to a copy in a CDN)
* uses PatternFly's "alert" pattern to show severities for diagnostics,
properly nesting "note" diagnostics for diagnostic groups.
Example:
before: https://dmalcolm.fedorapeople.org/gcc/2025-06-10/before/diagnostic-ranges.c.html
after: https://dmalcolm.fedorapeople.org/gcc/2025-06-10/after/diagnostic-ranges.c.html
* adds initial support for logical locations and physical locations
* adds initial support for multi-level nested diagnostics such as those
for C++ concepts diagnostics. Ideally this would show a clickable
disclosure widget to expand/collapse a level, but for now it uses
nested <ul> elements with <li> for the child diagnostics.
Example:
before: https://dmalcolm.fedorapeople.org/gcc/2025-06-10/before/nested-diagnostics-1.C.html
after: https://dmalcolm.fedorapeople.org/gcc/2025-06-10/after/nested-diagnostics-1.C.html
gcc/ChangeLog:
PR other/116792
* diagnostic-format-html.cc: Include "diagnostic-path.h" and
"diagnostic-client-data-hooks.h".
(html_builder::m_logical_loc_mgr): New field.
(html_builder::m_cur_nesting_levels): New field.
(html_builder::m_last_logical_location): New field.
(html_builder::m_last_location): New field.
(html_builder::m_last_expanded_location): New field.
(HTML_STYLE): Add "white-space: pre;" to .source and .annotation.
Add "gcc-quoted-text" CSS class.
(html_builder::html_builder): Initialize the new fields. If CSS
is enabled, add CDN links to PatternFly 3 stylesheets.
(html_builder::add_stylesheet): New.
(html_builder::on_report_diagnostic): Add "alert" param to
make_element_for_diagnostic, setting it by default, but unsetting
it for nested diagnostics below the top level. Use
add_at_nesting_level for nested diagnostics.
(add_nesting_level_attr): New.
(html_builder::add_at_nesting_level): New.
(get_pf_class_for_alert_div): New.
(get_pf_class_for_alert_icon): New.
(get_label_for_logical_location_kind): New.
(add_labelled_value): New.
(html_builder::make_element_for_diagnostic): Add leading comment.
Add "alert" param. Drop class="gcc-diagnostic" from <div> tag,
instead adding the class for a PatternFly 3 alert if "alert" is
true, and adding a <span> with an alert icon, both according to
the diagnostic severity. Add a severity prefix to the message for
alerts. Add any metadata/option text as suffixes to the message.
Show any logical location. Show any physical location. Don't
show the locus if the last location is unchanged within the
diagnostic_group. Wrap any execution path element in a
<div id="execution-path"> and add a label to it. Wrap any
generated patch in a <div id="suggested-fix"> and add a label
to it.
(selftest::test_simple_log): Update expected HTML.
gcc/testsuite/ChangeLog:
PR other/116792
* gcc.dg/html-output/missing-semicolon.py: Update for changes
to diagnostic elements.
* gcc.dg/format/diagnostic-ranges-html.py: Likewise.
* gcc.dg/plugin/diagnostic-test-metadata-html.py: Likewise. Drop
out-of-date comment.
* gcc.dg/plugin/diagnostic-test-paths-2.py: Likewise.
* gcc.dg/plugin/diagnostic-test-paths-4.py: Likewise. Drop
out-of-date comment.
* gcc.dg/plugin/diagnostic-test-show-locus.py: Likewise.
* lib/htmltest.py (get_diag_by_index): Update to use search by id.
(get_message_within_diag): Update to use search by class.
libcpp/ChangeLog:
PR other/116792
* include/line-map.h (typedef expanded_location): Convert to...
(struct expanded_location): ...this.
(operator==): New decl, for expanded_location.
(operator!=): Likewise.
* line-map.cc (operator==): New decl, for expanded_location.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
GCC Administrator