This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy] Define __clang_analyzer__ macro for clang-tidy for compatibility with clang static analyzer
ClosedPublic

Authored by zinovy.nis on Mar 26 2018, 1:05 PM.

Details

Summary

This macro is widely used in many well-known projects, ex. Chromium.

But it's not set for clang-tidy, so for ex. DCHECK in Chromium is not considered as [[no-return]], and a lot of false-positive warnings about nullptr dereferenced are emitted.

This patch fixes the issue by explicitly added macro definition.

Diff Detail

Repository
rL LLVM

Event Timeline

zinovy.nis created this revision.Mar 26 2018, 1:05 PM
zinovy.nis edited the summary of this revision. (Show Details)Mar 26 2018, 1:06 PM
zinovy.nis edited the summary of this revision. (Show Details)
Eugene.Zelenko removed a subscriber: Restricted Project.
alexfh added inline comments.Mar 27 2018, 8:35 AM
clang-tidy/ClangTidy.cpp
490 ↗(On Diff #139843)

I wonder whether we should instead reuse the logic in the frontend (tools/clang/lib/Frontend/InitPreprocessor.cpp:970). This could be done by overriding ActionFactory::runInvocation and setting FrontendOptions::ProgramAction to frontend::RunAnalysis there. WDYT?

zinovy.nis added inline comments.Mar 27 2018, 8:52 AM
clang-tidy/ClangTidy.cpp
490 ↗(On Diff #139843)

Thanks. I know about this code. But I'm not sure that we can reuse RunAnalysys action hre - we need to parse AST only, but RunAnalysys does a lot of other things we dont' need. Is it correct?

alexfh accepted this revision.Mar 28 2018, 11:01 AM

LG

clang-tidy/ClangTidy.cpp
490 ↗(On Diff #139843)

Clang tooling accepts the action from the client (in this case clang-tidy) and doesn't rely on frontend code that creates an action depending on the value of FrontendOptions::ProgramAction (clang::ExecuteCompilerInvocation). Thus, setting this frontend option will only trigger the logic in Frontend/InitPreprocessor.cpp that defines the macro.

On one hand, doing so will help clang-tidy to keep distance from whatever is done in the frontend to support static analyzer. On the other side, as your answer shows, this may not be a clear way to interact with that logic.

So I'm fine with either implementation.

This revision is now accepted and ready to land.Mar 28 2018, 11:01 AM
This revision was automatically updated to reflect the committed changes.
thakis added a subscriber: thakis.Apr 2 2018, 7:27 AM

The test added here doesn't pass on Windows, and the change breaks another test on Windows: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/9794

Looks like quotes are required.
Thanks for pointing! I'll submit a patch for this.

пн, 2 апр. 2018 г. в 17:28, Nico Weber via Phabricator <
reviews@reviews.llvm.org>:

thakis added a comment.

Actually, it doesn't pass on non-Windows either:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/27665/steps/test/logs/stdio

Repository:

rL LLVM

https://reviews.llvm.org/D44906