If we use the -Werror flag be sure to NOT enable all warnings and disable some of them (this makes build non-reproducible if JVM changes). So when using -Werror, we should list all warnings we want to see explicit (so no “all” warning). For Eclipse’s ECJ do the same.
In general with the Eclipse compiler we can define “per violation type” which action to take (warn or fail). But unfortunately, this does not allow suppression (as it is no longer a warning). ----- Uwe Schindler Achterdiek 19, D-28357 Bremen http://www.thetaphi.de <http://www.thetaphi.de/> eMail: [email protected] From: [email protected] [mailto:[email protected]] On Behalf Of Mike Drob Sent: Wednesday, July 5, 2017 6:10 PM To: Lucene Dev <[email protected]> Cc: Christine Poerschke <[email protected]> Subject: Re: 10 Resource Leak warnings dated to Q2 2017 I think you can do this with the -Werror flag and supress annotating everything else. On Wed, Jul 5, 2017 at 10:45 AM, Erick Erickson <[email protected] <mailto:[email protected]> > wrote: bq: making precommit fail for some but not all resource leaks. Implementation wise, how might one go about that? No clue, hoping somebody who _does_ have clue will just say "oh, you just specify blah blah blah" ;) On Wed, Jul 5, 2017 at 8:39 AM, Christine Poerschke (BLOOMBERG/ LONDON) <[email protected] <mailto:[email protected]> > wrote: > Hi Erick, > > Thanks for the extra context re: JavaBinCodec and SOLR-10779. > > I agree that backporting warning fixes to 6x is optional at this point and > for complex fixes probably not worth the risk of introducing subtle bugs in > the process. > > +1 to your idea of making precommit fail for some but not all resource leaks. > Implementation wise, how might one go about that? Redirecting precommit > output and post-processing it should be do-able but seems hacky ... > > Christine > > ----- Original Message ----- > From: [email protected] <mailto:[email protected]> > To: Christine Poerschke (BLOOMBERG/ LONDON), [email protected] > <mailto:[email protected]> > At: 07/04/17 16:45:11 > > Christine: > > I fixed the JavaBinCodec warnings in SOLR-10779 for master/7.0, but > didn't backport to 6x. So if those warnings are creeping back in to > the 7x code line we can take a look. > > I didn't backport to 6x since this seems to be long-term enough that > there isn't much point, along with the feeling that we'll introduce > problems at times in the effort and my view is that 6x is close enough > to end of development that we shouldn't expend the effort or introduce > instabilities. Or, put another way, I didn't want to be responsible > for introducing bugs in 6x, 7x is fair game ;) > > Along the lines of making forward progress though.... Is it possible > to make precommit fail for resource leaks for specific classes only? > Or for specific files? It wouldn't be perfect, but cleaning up > warnings for a class then having precommit fail if resource leaks came > back in would feel less like Sisyphus. > > I'm looking for either of the following. Or both of course. > - fail if precommit issues resource leak warnings for the _class_ > JavaBinCodec wherever it's used. > - fail if precommit issues resource leak warnings in the _file_ > whatever.java if any resource leak warnings are found for any class. > > The first one is the one I'd probably use on the theory that one gets > familiar with the quirks of a particular class and it's easier to > clean up the resource leak warnings for that class than all the > warnings that might be in a file. But that's a personal preference. > > Erick > > On Tue, Jul 4, 2017 at 3:47 AM, Christine Poerschke (BLOOMBERG/ > LONDON) <[email protected] <mailto:[email protected]> > wrote: >> Hi Everyone, >> >> The following list is the latest Q2 2017 portion of the dated-warnings.log >> file I've attached to https://issues.apache.org/jira/browse/SOLR-10778 and >> it was generated by the also attached shell script that correlates warnings >> with git commit history. >> >> Any help to investigate and take care of these warnings would be >> appreciated. The short term goal is to not increase the number of warnings >> we have and in the medium to long term the goal would be to fail precommit >> if any warnings are detected. >> >> Christine >> >> PS: @SuppressWarnings("resource") can be used to suppress inappropriate >> warnings and Erick Erickson is already looking into warnings related to >> JavaBinCodec. >> >> ----------------------------------------- >> ant precommit warnings dated to Q2 2017 >> ----------------------------------------- >> >> 2017-06-21 >> http://www.github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/ReadersAndUpdates.java#L845 >> 2017-06-21 >> http://www.github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/FrozenBufferedUpdates.java#L186 >> 2017-06-21 >> http://www.github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/FrozenBufferedUpdates.java#L144 >> 2017-06-16 >> http://www.github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Utils.java#L110 >> 2017-06-16 >> http://www.github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/CommandOperation.java#L248 >> 2017-06-16 >> http://www.github.com/apache/lucene-solr/blob/master/solr/core/src/test/org/apache/solr/util/TestUtils.java#L186 >> 2017-05-30 >> http://www.github.com/apache/lucene-solr/blob/master/solr/core/src/test/org/apache/solr/cloud/autoscaling/TestPolicyCloud.java#L161 >> 2017-05-16 >> http://www.github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/codecs/CodecUtil.java#L523 >> 2017-04-12 >> http://www.github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/core/CoreContainer.java#L969 >> 2017-04-11 >> http://www.github.com/apache/lucene-solr/blob/master/solr/solrj/src/test/org/apache/solr/client/solrj/io/stream/StreamExpressionTest.java#L232 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > <mailto:[email protected]> > For additional commands, e-mail: [email protected] > <mailto:[email protected]> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] <mailto:[email protected]> For additional commands, e-mail: [email protected] <mailto:[email protected]>
