[cfe-dev] clang --analyze: how do I get more verbose diagnostics?

[Tomasz Mikolajczyk]

"sh: /Users/grubber/src/llvm-build/Debug+Asserts/bin: is a directory"

You mean
--use-analyzer=/Users/grubber/src/llvm-build/Debug+Asserts/bin/clang++ I
guess


On Mon, Nov 18, 2013 at 3:44 AM, Jared Grubb <jared.grubb at gmail.com> wrote:

> Is there a way to debug checkers and BugReporterVisitors? I'm trying to
> implement a visitor, but having trouble getting it to show any notes.
>
> Based on your advice, I tried this:
>
> $ /Users/grubber/src/llvm/tools/clang/tools/scan-build/scan-build
> --use-analyzer=/Users/grubber/src/llvm-build/Debug+Asserts/bin -v -v -v
> -enable-checker alpha.cplusplus.BlockRefCapture -enable-checker core --view
> clang++ -fblocks -std=c++11 blocks.cpp
> sh: /Users/grubber/src/llvm-build/Debug+Asserts/bin: is a directory
> scan-build: Using '/Users/grubber/src/llvm-build/Debug+Asserts/bin' for
> static analysis
> scan-build: Emitting reports for this run to
> '/var/folders/fq/4_p48fh50_72j_gt7_pfgn_40000gn/T/scan-build-2013-11-17-184203-37891-1'.
> clang++ -fblocks -std=c++11 blocks.cpp
> scan-build: Removing directory
> '/var/folders/fq/4_p48fh50_72j_gt7_pfgn_40000gn/T/scan-build-2013-11-17-184203-37891-1'
> because it contains no reports.
> scan-build: No bugs found.
>
> But that didnt find any issue, so I'm thinking it's not actually trying my
> alpha checker?
>
> Jared
>
> On Nov 14, 2013, at 9:27, Jordan Rose <jordan_rose at apple.com> wrote:
>
> Hi, Richard. "clang --analyze” is not intended to be a usual interface for
> the analyzer, merely an invocation that higher-level tools can use. The
> correct way to run the analyzer, even on a single file, is through the
> scan-build <http://clang-analyzer.llvm.org/scan-build.html> tool, which
> provides HTML output that shows you the full path to the purported bug. (Or
> through Xcode, of course, if you’re on a Mac.)
>
> Sorry for the inconvenience,
> Jordan
>
>
> On Nov 12, 2013, at 11:56 , Richard <legalize at xmission.com> wrote:
>
> clang --analyze reports this problem in my code:
>
> warning: Potential memory leak
>        for (extent_vector_iter deit = disk_.provided_extents.begin();
>             deit != disk_.provided_extents.end(); ++deit)
>                                                   ^~
> 1 warning generated.
>
> Context:
> typedef std::vector<extent_data> extent_vector;
> typedef extent_vector::const_iterator extent_vector_iter;
>
> extent_data has no raw pointers, only non-pointer POD types and other
> standard library classes like string and vector of string, etc.
>
> The problem with this diagnostic is that it points to the place where
> it thinks a memory leak may occur, but it doesn't provide me with a
> chain of reasoning that makes me understand why it thinks this
> particular chunk of code may leak memory.
>
> Am I missing some magic flag to tell me this extra level of
> information, or is that ability simply lacking?
> --
> "The Direct3D Graphics Pipeline" free book <
> http://tinyurl.com/d3d-pipeline>
>     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org<http://computergraphicsmuseum.org/>
> >
>         The Terminals Wiki <http://terminals.classiccmp.org>
>  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com<http://legalizeadulthood.wordpress.com/>
> >
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131118/f04835a4/attachment.html>