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>