On the build-time vs static analysis point: I'd much prefer to have errors pointed out right from './mach build', which I can fix on the spot; rather than wait hours until I notice static analysis errors on a treeherder build. (e.g., I always forget explicit/MOZ_IMPLICIT!)
Unless we can get cross-platform & consistent static analysis from our build environments? g. On Tuesday, August 23, 2016 at 11:20:30 PM UTC+10, Eric Rescorla wrote: > I'm indifferent to this particular case, but I think that rkent's point > about static > checking is a good one. Given that C++ has existing annotations that say: > > - This does not produce a useful return value (return void) > - I am explicitly ignoring the return value (cast to void) > > And that we have (albeit imperfect) static checking tools that can detect > non-use of > return values, it seems like we would ultimately be better-off by using > those tools > to treat use of the return value by the default flagging a compiler error > when that > doesn't happen yet a third annotation rather than treating "use the return > value > somehow" as the default and flagging a compiler error when that doesn't > happen. > I appreciate that we have a lot of code that violates this rule now, so > actually cleaning > that up is a long process gradually converting the code base, but it has > the advantage > that once that's done then it just stays clean (just like any other -Werror > conversion). > > -Ekr > > > On Mon, Aug 22, 2016 at 5:03 PM, Bobby Holley <bobby...@gmail.com> wrote: > > > On Mon, Aug 22, 2016 at 4:39 PM, R Kent James <ke...@caspia.com> wrote: > > > > > On 8/21/2016 9:14 PM, Nicholas Nethercote wrote: > > > > I strongly encourage people to do likewise on > > > > any IDL files with which they are familiar. Adding appropriate checks > > > isn't > > > > always easy > > > > > > Exactly, and I hope that you and others restrain your exuberance a > > > little bit for this reason. A warning would be one thing, but a hard > > > failure that forces developers to drop what they are doing and think > > > hard about an appropriate check is just having you set YOUR priorities > > > for people rather than letting people do what might be much more > > > important work. > > > > > > There's lots of legacy code around that may or may not be worth the > > > effort to think hard about such failures. This is really better suited > > > for a static checker that can make a list of problems, which list can be > > > managed appropriately for priority, rather than a hard error that forces > > > us to drop everything. > > > > > > > I don't quite follow the objection here. > > > > Anybody who adds such an annotation needs to get the tree green before they > > land the annotation. Developers writing new code that ignores the nsresult > > will get instant feedback (by way of try failure) that the developer of the > > API thinks the nsresult needs to be checked. This doesn't seem like an > > undue burden, and enforced-by-default assertions are critical to code > > hygiene and quality. > > > > If your concern is the way this API change may break Thunderbird-only > > consumers of shared XPCOM APIs, that's related to Thunderbird being a > > non-Tier-1 platform, and pretty orthogonal to the specific change that Nick > > made. > > > > bholley > > > > > :rkent _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
