[qt/clang/llvm-project]: Summary of bulk changes made
KDE Git Services - Bulk Change <[email protected]>
| Newsgroups | gmane.comp.kde.cvs |
|---|---|
| Message-ID | <[email protected]> |
Git repository change summary for qt/clang/llvm-project Pushed by mirror-service into branch 'upstream/users/steakhal/csa/output-crashes-4'. Changed from 7ed751ca78b622544977007e4cb2353f51596a2f to 2938cfca825444d70e58cbeffeec98549eced337 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-project/-/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-project/-/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-project/-/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-project/-/commit/e29e70d010308dceefcfac89436b4898ead902ff Git commit 2938cfca825444d70e58cbeffeec98549eced337 by Balazs Benics on 10/08/2026 at 11:08.. [analyzer] Fix -analyzer-output=html assert on reversed and macro ranges HTMLDiagnostics::HighlightRange guarded against a reversed range by comparing line numbers, so a same-line reversal - which is what the piece for an implicit copy constructor carries - reached html::HighlightRange. Its scan walks from begin to end, ran off the end of the buffer, and asserted: https://godbolt.org/z/sTb5qfjjd Invalid position to insert! (RewriteRope.h) It also added the end token's length itself and then passed a token range to html::HighlightRange, which measured the token again, this time from the interior. For most tokens the two cancel, but where the tail re-lexes longer the highlight reached past the end of the range, e.g. over a trailing ';'. Use getExpansionRangeInFile(), which rejects reversed and cross-file ranges, then convert once and tell html::HighlightRange the range is already char-granular. A range ending inside a macro expansion now covers the whole macro use, so the highlight nests around the 'macro' element rather than ending inside it. Assisted-By: claude https://invent.kde.org/qt/clang/llvm-project/-/commit/2938cfca825444d70e58cbeffeec98549eced337