[Bug libstdc++/98605] [8/9/10 Regression] clang-tidy error parsing on libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605 --- Comment #12 from Matheus Izvekov --- Thank you!!!
[Bug libstdc++/98605] [8/9/10 Regression] clang-tidy error parsing on libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jonathan Wakely --- This should be fixed in all active branches now.
[Bug libstdc++/98605] [8/9/10 Regression] clang-tidy error parsing on libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605 --- Comment #10 from CVS Commits --- The releases/gcc-8 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:283c218a4846075c549f0215d6883e577b26e845 commit r8-10726-g283c218a4846075c549f0215d6883e577b26e845 Author: Jonathan Wakely Date: Wed Jan 13 11:03:58 2021 + libstdc++: Fix clang analyzer suppression [PR 98605] The fix for PR libstdc++/82481 should only have applied for targets where _GLIBCXX_HAVE_TLS is defined. Because it was also done for non-TLS targets, it isn't possible to use clang's analyzers on non-TLS targets if the code uses . This fixes it by using a NOLINT comment on the relevant line instead of testing #ifdef __clang_analyzer__ and compiling different code when analyzing. I'm not actually able to reproduce the analyzer warning with the tools from Clang 10.0.1 so I'm not going to try to make the suppression more specific with NOLINTNEXTLINE(clang-analyzer-code.StackAddressEscape). libstdc++-v3/ChangeLog: PR libstdc++/98605 * include/std/mutex (call_once): Use NOLINT to suppress clang analyzer warnings. (cherry picked from commit 8d3636923a309074eb19240ebaa30c1a0801eaaf)
[Bug libstdc++/98605] [8/9/10 Regression] clang-tidy error parsing on libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:4aeae11db66c9bce0aadf447e6ff0776a97bfccf commit r9-9180-g4aeae11db66c9bce0aadf447e6ff0776a97bfccf Author: Jonathan Wakely Date: Wed Jan 13 11:03:58 2021 + libstdc++: Fix clang analyzer suppression [PR 98605] The fix for PR libstdc++/82481 should only have applied for targets where _GLIBCXX_HAVE_TLS is defined. Because it was also done for non-TLS targets, it isn't possible to use clang's analyzers on non-TLS targets if the code uses . This fixes it by using a NOLINT comment on the relevant line instead of testing #ifdef __clang_analyzer__ and compiling different code when analyzing. I'm not actually able to reproduce the analyzer warning with the tools from Clang 10.0.1 so I'm not going to try to make the suppression more specific with NOLINTNEXTLINE(clang-analyzer-code.StackAddressEscape). libstdc++-v3/ChangeLog: PR libstdc++/98605 * include/std/mutex (call_once): Use NOLINT to suppress clang analyzer warnings. (cherry picked from commit 8d3636923a309074eb19240ebaa30c1a0801eaaf)
[Bug libstdc++/98605] [8/9/10 Regression] clang-tidy error parsing on libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:8d3636923a309074eb19240ebaa30c1a0801eaaf commit r10-9267-g8d3636923a309074eb19240ebaa30c1a0801eaaf Author: Jonathan Wakely Date: Wed Jan 13 11:03:58 2021 + libstdc++: Fix clang analyzer suppression [PR 98605] The fix for PR libstdc++/82481 should only have applied for targets where _GLIBCXX_HAVE_TLS is defined. Because it was also done for non-TLS targets, it isn't possible to use clang's analyzers on non-TLS targets if the code uses . This fixes it by using a NOLINT comment on the relevant line instead of testing #ifdef __clang_analyzer__ and compiling different code when analyzing. I'm not actually able to reproduce the analyzer warning with the tools from Clang 10.0.1 so I'm not going to try to make the suppression more specific with NOLINTNEXTLINE(clang-analyzer-code.StackAddressEscape). libstdc++-v3/ChangeLog: PR libstdc++/98605 * include/std/mutex (call_once): Use NOLINT to suppress clang analyzer warnings.
[Bug libstdc++/98605] [8/9/10 Regression] clang-tidy error parsing on libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605 --- Comment #7 from Jonathan Wakely --- The original report said it was with 4.0.0
[Bug libstdc++/98605] [8/9/10 Regression] clang-tidy error parsing on libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605 --- Comment #6 from Matheus Izvekov --- What clang-tidy version? From the date of the commit, it was probably no older than 6, probably 4 or 5. If that is too old and probably considered unsupported, I think that is fine. But even if in the end it was a false positive, the warning seemed to me to be of high quality, ie to some standard of coding practice, it would be advised to document this somewhat subtle assumption. Not sure that applies to libstdc++ standards :) But if you cannot reproduce the original warning anyway, then I guess it's better to just remove it than make some change that can't even be tested.
[Bug libstdc++/98605] [8/9/10 Regression] clang-tidy error parsing on libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605 --- Comment #5 from Jonathan Wakely --- I can't reproduce the original error reported in PR 82481 anyway. Maybe clang-tidy got smarter (it doesn't show problems in system headers by default, which helps). Maybe we can just remove that code entirely.
[Bug libstdc++/98605] [8/9/10 Regression] clang-tidy error parsing on libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |8.5 Known to work||11.0, 7.2.0 Known to fail||10.2.0, 7.3.0, 8.4.0, 9.3.0 Summary|clang-tidy error parsing|[8/9/10 Regression] | on libstdc++-v3 |clang-tidy error parsing || on libstdc++-v3
