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

Git repository change summary for qt/clang/llvm
Pushed by mirror-service into branch 'upstream/users/steakhal/csa/output-crashes-3'.
Changed from 92fa322590b66e754d2daaef3e8f89dee8b53e88 to e29e70d010308dceefcfac89436b4898ead902ff
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 a117608cd1487401064079bd097622b22942e0d4 by Balazs Benics on 10/08/2026 at 11:08..
[clang][NFC] Reuse SourceManager::getExpansionRange in getExpansionRangeInFile
https://invent.kde.org/qt/clang/llvm/-/commit/a117608cd1487401064079bd097622b22942e0d4

Git commit 550d4a426e875efbb57b90c279f79c0a630e7783 by Balazs Benics on 10/08/2026 at 11:08..
[clang][NFC] Document getExpansionRangeInFile's nullopt cases
https://invent.kde.org/qt/clang/llvm/-/commit/550d4a426e875efbb57b90c279f79c0a630e7783

Git commit ee8dc4c03c3265b48c7ff5f59faff2330bc7e8de by Balazs Benics on 10/08/2026 at 11:08..
[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/-/commit/ee8dc4c03c3265b48c7ff5f59faff2330bc7e8de

Git commit e29e70d010308dceefcfac89436b4898ead902ff by Balazs Benics on 10/08/2026 at 11:08..
[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/-/commit/e29e70d010308dceefcfac89436b4898ead902ff