[qt/clang/llvm-project]: Summary of bulk changes made

Git repository change summary for qt/clang/llvm-project
Pushed by mirror-service into branch 'upstream/users/steakhal/csa/output-crashes-3'.
Changed from 0000000000000000000000000000000000000000 to 92fa322590b66e754d2daaef3e8f89dee8b53e88
Acknowledgement was received that this change introduces only existing code that has been pushed to another public open source repository.

This change contains the following new commits:

Git commit a9207acd87fea7a5933312f33ac6a9e821200c58 by Balazs Benics on 06/08/2026 at 15:06..
[clang][NFC] Extract getExpansionRangeInFile out of the diagnostic renderers

Prep for the following commits, which fix crashes in the analyzer's SARIF and
HTML output on ranges that end inside a macro expansion. Fixing them means
mapping such a range into the reported file - the normalization the frontend
text and SARIF renderers already do, and that the two analyzer consumers each
do differently and incorrectly.

Hoist that logic into getExpansionRangeInFile, beside the DiagnosticRenderer
base both frontend renderers derive from, so the fixes reuse one
implementation instead of adding two more copies. TextDiagnostic and
SARIFDiagnostic move onto it here with no behavior change; the analyzer
consumers follow in later commits.

getFileID() replaces SARIFDiagnostic's getDecomposedLoc(...).first - equivalent
here, and what TextDiagnostic has used since c113cbb51005.

Assisted-By: claude
https://invent.kde.org/qt/clang/llvm-project/-/commit/a9207acd87fea7a5933312f33ac6a9e821200c58

Git commit b7cf426afdcdbb99593f66b5e6f6cdc963de6afc by Balazs Benics on 06/08/2026 at 15:06..
[clang] Reject ranges getExpansionRangeInFile cannot represent

getExpansionRangeInFile was extracted verbatim and inherited two shortcomings
of the original loop, fixed here before the analyzer's SARIF and HTML consumers
depend on it:

- It mapped the end with getExpansionRange(SourceLocation), which always
  reports a token range, so a char-range input was widened by a whole token.
  Now using the getExpansionRange(CharSourceRange) overload, which keeps the flag.
- It passed reversed ranges through. Consumers walk begin->end; now returning
  nullopt for those, as Lexer::makeFileCharRange already does.

Separate from the extraction so that stays NFC, and out of the consumer fixes
because it changes the shared helper's contract rather than one output.

Both contract changes, plus the invalid- and cross-file-range guards, are
covered by a GetExpansionRangeInFile unit test in
clang/unittests/Frontend/TextDiagnosticTest.cpp.

Assisted-By: claude
https://invent.kde.org/qt/clang/llvm-project/-/commit/b7cf426afdcdbb99593f66b5e6f6cdc963de6afc

Git commit 92fa322590b66e754d2daaef3e8f89dee8b53e88 by Balazs Benics on 06/08/2026 at 15:06..
[analyzer] Fix -analyzer-output=sarif crash on macro-expanded ranges

A path piece whose range ends inside a macro expansion aborted the whole
document: https://godbolt.org/z/61vWYcsWj

  Cannot create a physicalLocation from invalid SourceRange!

convertTokenRangeToCharRange() built the end with
Lexer::getLocForEndOfToken(), which returns an invalid location for a macro
ID that is not at the end of its expansion, and used it unchecked. The
analyzer's own test corpus hits this in nine files; text and plist output
were unaffected because both already map such ranges to the expansion.

- Use getExpansionRangeInFile(), so the region covers the macro use like the
  other two outputs.
- Fall back to a caret when the range is unusable. A thread flow needs a
  location per piece, so dropping one would truncate the reported path. This
  also stops reversed ranges producing regions with endColumn < startColumn.

Single-token ranges keep their zero-width regions; widening them would churn
every expected-sarif file, so that is left for a separate change.

Assisted-By: claude
https://invent.kde.org/qt/clang/llvm-project/-/commit/92fa322590b66e754d2daaef3e8f89dee8b53e88