[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC 0/8] Introduce an extensible static analyzer
From: |
Daniel P . Berrangé |
Subject: |
Re: [RFC 0/8] Introduce an extensible static analyzer |
Date: |
Wed, 6 Jul 2022 11:15:25 +0100 |
User-agent: |
Mutt/2.2.6 (2022-06-05) |
On Wed, Jul 06, 2022 at 10:54:51AM +0100, Alberto Faria wrote:
> On Tue, Jul 5, 2022 at 5:12 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > On Tue, Jul 05, 2022 at 12:28:55PM +0100, Alberto Faria wrote:
> > > On Tue, Jul 5, 2022 at 8:16 AM Daniel P. Berrangé <berrange@redhat.com>
> > > wrote:
> >
> > Overall I think a libclang based analysis tool will be useful, but
> > I can't see us enabling it as a standard part of 'make check'
> > given the time penalty.
> >
> >
> > Feels like something that'll have to be opt-in to a large degree
> > for regular contributors. In terms of gating CI though, it is less
> > of an issue, since we massively parallelize jobs. As long as we
> > have a dedicated build job just for running this static analysis
> > check in isolation, and NOT as 'make check' in all existing jobs,
> > it can happen in parallel with all the other build jobs, and we
> > won't notice the speed.
> >
> > In summary, I think this approach is viable despite the speed
> > penalty provided we dont wire it into 'make check' by default.
>
> Agreed. Thanks for gathering these numbers.
>
> Making the script use build dependency information, to avoid
> re-analyzing translation units that weren't modified since the last
> analysis, should make it fast enough to be usable iteratively during
> development. Header precompilation could also be worth looking into.
> Doing that + running a full analysis in CI should be good enough.
For clang-tidy, I've been trying it out integrated into emacs
via eglot and clangd. This means I get clang-tidy errors reported
interactively as I write code, so wouldn't need to run a full
tree analysis. Unfortunately, unless I'm missing something, there's
no way to extend clangd to plugin extra checks. So it would need
to re-implement something equivalent to clangd for our custom checks,
and then integrate that into eglot (or equiv for other editors).
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
- [RFC 6/8] Fix some coroutine_fn indirect calls and pointer assignments, (continued)
- [RFC 6/8] Fix some coroutine_fn indirect calls and pointer assignments, Alberto Faria, 2022/07/02
- [RFC 7/8] block: Add no_coroutine_fn marker, Alberto Faria, 2022/07/02
- [RFC 8/8] Avoid calls from coroutine_fn to no_coroutine_fn, Alberto Faria, 2022/07/02
- Re: [RFC 0/8] Introduce an extensible static analyzer, Paolo Bonzini, 2022/07/02
- Re: [RFC 0/8] Introduce an extensible static analyzer, Daniel P . Berrangé, 2022/07/04
- Re: [RFC 0/8] Introduce an extensible static analyzer, Alberto Faria, 2022/07/04
- Re: [RFC 0/8] Introduce an extensible static analyzer, Daniel P . Berrangé, 2022/07/05
- Re: [RFC 0/8] Introduce an extensible static analyzer, Alberto Faria, 2022/07/05
- Re: [RFC 0/8] Introduce an extensible static analyzer, Daniel P . Berrangé, 2022/07/05
- Re: [RFC 0/8] Introduce an extensible static analyzer, Alberto Faria, 2022/07/06
- Re: [RFC 0/8] Introduce an extensible static analyzer,
Daniel P . Berrangé <=
- Re: [RFC 0/8] Introduce an extensible static analyzer, Alberto Faria, 2022/07/08
Re: [RFC 0/8] Introduce an extensible static analyzer, Daniel P . Berrangé, 2022/07/05