[cfe-dev] [analyzer] Modeling a function with an out parameter pointer in check::PostCall

[Artem Dergachev via cfe-dev]

On 6/23/20 8:15 AM, philip.chimento at gmail.com wrote:
> On Sun, Jun 21, 2020 at 2:03 AM Artem Dergachev <noqnoqneo at gmail.com 
> <mailto:noqnoqneo at gmail.com>> wrote:
>
>
>
>     On 6/16/20 3:56 AM, philip.chimento at gmail.com
>     <mailto:philip.chimento at gmail.com> wrote:
>>     On Sun, Jun 14, 2020 at 2:05 AM Artem Dergachev
>>     <noqnoqneo at gmail.com <mailto:noqnoqneo at gmail.com>> wrote:
>>
>>         > How do I get the SVal for the memory pointed to by
>>         CallEvent::getArgSVal(0)?
>>
>>         ProgramState::getSVal (the overload that accepts the
>>         location/region).
>>
>>
>>     Thanks, that was it. I would never have thought that SVal ->
>>     SVal::getAsRegion() -> ProgramState::getSVal() would have ended
>>     up with anything but the original SVal, but there it is!
>>
>>         Generally i recommend checking out a few links at the bottom
>>         of http://clang-analyzer.llvm.org/checker_dev_manual.html
>>
>>
>>     Speaking of that... would you be interested in merging my PR
>>     https://github.com/haoNoQ/clang-analyzer-guide/pull/5 and some of
>>     the other open PRs on the handbook, and releasing a new version?
>>     Depending on how much of a hassle it is, I might be interested to
>>     make it publish as HTML to GitHub Pages automatically so you
>>     wouldn't have to release PDFs...
>
>     Ugh, there are countless more outdated paragraphs in there. There
>     are even bugs documented that had to be fixed rather than
>     documented. I emitted it as an artifact that would have been
>     created anyway at some point but i'm personally not planning to
>     maintain it further because it's not the right way to do
>     documentation (we'd rather have doxygen / rst documentation).
>     Please feel free to fork but i'd much rather have it converted to
>     into in-tree documentation (say, documentation in chapter 5 could
>     be torn into individual doxygen comments).
>
>
> I can't honestly say that in-tree documentation would be more useful 
> for people like me trying to develop checker plugins against a 
> released version of clang... is there a middle ground where it could 
> live in-tree but get rendered into something else than doxygen? The 
> doxygen pages are super slow to load (especially if you accidentally 
> load a large one) and difficult to search (nearly impossible if you 
> don't already know what you're looking for).

Mmm, strange. As a person who regularly googles class names in llvm.org 
doxygen, i've never had these problems. Say, 
https://clang.llvm.org/doxygen/classclang_1_1Decl.html loads instantly 
for me. I don't know how could that be slow aside from llvm.org servers 
suddenly being slow or a poor internet connection. Those are plain old 
static pages. Of course you have to know the class name in advance; 
doxygen is not great for tutorials. You can also always build doxygen 
locally and grep it (but that's not necessarily better than reading 
source code).

> By 'rst' documentation do you mean this page? 
> https://clang-analyzer.llvm.org/checker_dev_manual.html

I mean something like this: 
https://clang.llvm.org/docs/LibASTMatchersTutorial.html

This would be better for step-by-step-tutorial-like material and doxygen 
would be better for documentation on individual classes and methods.

> Regards,
> -- 
> Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200624/1f389d82/attachment.html>