[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-2'.
Changed from 0000000000000000000000000000000000000000 to b7cf426afdcdbb99593f66b5e6f6cdc963de6afc
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