On Sun, Sep 27, 2015 at 10:54 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote:
> On 2015-09-25 7:35 PM, Robert O'Callahan wrote: > >> On Sat, Sep 26, 2015 at 7:34 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com >> <mailto:ehsan.akhg...@gmail.com>> wrote: >> >> On 2015-09-25 12:01 PM, Justin Dolske wrote: >> >> At Mozilla, it seems like previous discussions on this kind of >> thing >> (style and warnings come to mind) have dealt with this at a >> file/directory/module level... Someone fixes up a thing >> completely, adds >> it to a whitelist, and then it's a simple pass/fail. Could that >> work >> here too? >> >> >> Yes, that is another option for checks that tons of existing code >> don't pass. >> >> >> That'll help some. >> >> The problem of attributing new errors to the correct part of the diff >> remains, and is quite interesting. >> > > FWIW based on an in-person discussion with gps last week, it seems like > MozReview's static analysis support is built for cheap analyses that do not > need to invoke the build system, so C++ analysis will probably not be > integrated with MozReview (at least not any time soon), so we're going to > need to rely on try pushes any way. > > I'm working on extending our C++ static analysis coverage so I hope to > make it much more difficult for something to get past the checks on various > platforms in the future. We can and should figure out ways for Try pushes with a corresponding MozReview review to submit results back to MozReview (instead of having to sift through Treeherder job results). I'm not yet sure if this integration is performed as part of the job itself or as part of TreeHerder. For now, we can future proof ourselves by producing machine readable output of all static analysis results. If the data is produced and readable, we'll figure out a way to consume and present it. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
