<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 21, 2020 at 2:03 AM Artem Dergachev <<a href="mailto:noqnoqneo@gmail.com">noqnoqneo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <br>
    <br>
    <div>On 6/16/20 3:56 AM,
      <a href="mailto:philip.chimento@gmail.com" target="_blank">philip.chimento@gmail.com</a> wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div>
          <div class="gmail_quote">
            <div dir="ltr" class="gmail_attr">On Sun, Jun 14, 2020 at
              2:05 AM Artem Dergachev <<a href="mailto:noqnoqneo@gmail.com" target="_blank">noqnoqneo@gmail.com</a>>
              wrote:<br>
            </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
              <div> > How do I get the SVal for the memory pointed to
                by CallEvent::getArgSVal(0)?<br>
                <br>
                ProgramState::getSVal (the overload that accepts the
                location/region).<br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>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!</div>
            <div> <br>
            </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
              <div> Generally i recommend checking out a few links at
                the bottom of <a href="http://clang-analyzer.llvm.org/checker_dev_manual.html" target="_blank">http://clang-analyzer.llvm.org/checker_dev_manual.html</a></div>
            </blockquote>
            <div><br>
            </div>
            <div>Speaking of that... would you be interested in merging
              my PR <a href="https://github.com/haoNoQ/clang-analyzer-guide/pull/5" target="_blank">https://github.com/haoNoQ/clang-analyzer-guide/pull/5</a>
              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...<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    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).<br></div></blockquote><div><br></div><div>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). By 'rst' documentation do you mean this page? <a href="https://clang-analyzer.llvm.org/checker_dev_manual.html">https://clang-analyzer.llvm.org/checker_dev_manual.html</a></div><div><br></div><div>Regards,<br></div></div>-- <br><div dir="ltr" class="gmail_signature">Philip</div></div>