[cfe-dev] Clang Static Analyzer Feature Bounties
Artem Dergachev via cfe-dev
cfe-dev at lists.llvm.org
Wed Mar 7 20:02:26 PST 2018
On 06/03/2018 8:29 AM, Benjamin Bales wrote:
> Hey guys,
>
> Thanks for your insightful responses! We've decided for now to first
> learn more about how development is done on the analyzer. We are
> primarily interested in contributing to the development of new
> checkers, particularly buffer issues (e.g. buffer overflow). Aside
> from looking at http://clang-analyzer.llvm.org/potential_checkers.html
> and http://clang-analyzer.llvm.org/checker_dev_manual.html, is there
> anything else we need to be aware of before we begin development?
> Also, what is the procedure for getting new checkers approved to add
> to the list of potential checkers?
The list of potential checkers is stored in the clang source tree, much
like the whole website, eg.:
https://github.com/llvm-mirror/clang/blob/master/www/analyzer/potential_checkers.html
So you can post improvements as code reviews.
Currently this list is not in a fantastic shape and requires cleanup
because since the last time it received a major update we've realized
that not all of these checkers are something that the analyzer is really
good at. So please discuss before you start working on any of them. Be
careful about checkers that require checking an invariant on all paths
through a piece of code (eg. SameResLogicalExpr - "the condition is true
on all paths") because the analyzer is not guaranteed to explore all
paths, and we don't have a good infrastructure for figuring out if any
paths were dropped, and we cannot provide good user experience in our
additional bug report notes for such bugs like we do for normal
single-path bugs by explaining the path to the user.
>
> -Ben
>
> On Fri, Mar 2, 2018 at 6:41 PM, Artem Dergachev <noqnoqneo at gmail.com
> <mailto:noqnoqneo at gmail.com>> wrote:
>
> Yeah, I guess, The LLVM Foundation might be the right contact for
> the business/commercial side of things (not sure).
>
> On the technical side - I'm currently reviewing a large portion of
> patches for the analyzer. I'd be happy to review and accept any
> patches, regardless of where they came from - under the usual
> terms of the LLVM developer policy (you should totally have a look
> at it). Most importantly, please discuss any non-trivial work
> before you start coding, and split it up into small incremental
> patches that gradually improve an experimental feature until it's
> ready to be turned on by default - this is called "developing
> under the flag". For example, a new checker will stay in the alpha
> package during development, and an experimental analyzer core
> feature will be disabled by an -analyzer-config option. The main
> point here is to speed up reviews and make sure you don't need to
> re-do anything - because it's extremely hard to do anything right
> with LLVM in isolation. Of course, I cannot guarantee that any
> particular patch is going to be accepted, at least not before I
> see it.
>
>
> On 02/03/2018 3:17 PM, Jonas Toth via cfe-dev wrote:
>
> Hi,
>
> no. I dont have any major position, i would just potentially
> benefit
> from the bounties :P
>
> I dont know who has the power to decide about financial
> questions, but
> the LLVM deciders are most likely involved in it!
>
> All the best, Jonas :)
>
>
> Am 02.03.2018 um 23:21 schrieb Benjamin Bales:
>
> Hi Jonas!
>
> Nice to hear from you. We could certainly add clang-tidy
> to our
> roadmap. The primary reason we are interested in
> improving the clang
> static analyzer is because we build our commercial
> product, CodeAI
> (www.mycode.ai <http://www.mycode.ai>), on top of it. I
> am hiring an internal work force to
> enhance the checkers, but I am interesting in exploring
> open source
> alternatives to push forward this work. I have some
> ideas, but I
> think it would be best if we could arrange a phone call
> next week
> sometime to discuss things. Are you the maintainer of
> this project?
>
> -Ben
>
> On Fri, Mar 2, 2018 at 4:59 PM, Jonas Toth via cfe-dev
> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>>
> wrote:
>
> Hi,
>
> nice to hear! Would you consider clang-tidy as second
> part of clangs
> static analysis framework as worthwhile, too?
>
> All the best, Jonas
>
>
> Am 02.03.2018 um 22:48 schrieb Benjamin Bales via cfe-dev:
>
> Greetings Clang Front End Developers!
>
> My name is Benjamin Bales, and I am the CTO and
> co-founder of
> QbitLogic, a startup company in Atlanta. We are
> interested in
> sponsoring feature bounties to further develop the
> clang static
> analyzer. Can someone recommend me a point of
> contact with whom I can
> open a dialogue? Let me know. Thanks!
>
> Sincerely,
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>
>
>
>
>
> --
> Benjamin Bales
> Chief Technology Officer
> QbitLogic
> 1180 West Peachtree Street, Ste. 2425
> Atlanta, GA 30309
> 470-214-0598
>
> CONFIDENTIALITY NOTICE
>
> This e-mail and any files transmitted with it are confidential and are
> intended solely for the use of the individual or entity to which they
> are addressed. This communication may contain privileged attorney
> material or other Property and Confidential matter. If you are not
> the intended recipient or the person responsible for delivering the
> e-mail for the intended person, be advised that you have received this
> e-mail in error and that any use, dissemination, forwarding, printing,
> or copying of this e-mail is strictly prohibited. If you believe you
> have received this e-mail in error, please immediately delete this
> e-mail and notify Benjamin Bales by telephoning 470-214-0598
> <tel:470-214-0598>.
>
More information about the cfe-dev
mailing list