Bug 547645 - [compiler] after 100 suppressed warnings @SuppressWarnings can get confused
Summary: [compiler] after 100 suppressed warnings @SuppressWarnings can get confused
Status: NEW
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 4.12   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard: stalebug bulk move
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-25 15:13 EDT by Stephan Herrmann CLA
Modified: 2022-07-13 05:46 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Herrmann CLA 2019-05-25 15:13:09 EDT
I observed a combination of settings and source file that can confuse the analysis of @SuppressWarnings:


- configure the following options:

org.eclipse.jdt.core.compiler.problem.undocumentedEmptyBlock=error
org.eclipse.jdt.core.compiler.problem.fatalOptionalError=enabled

compile the following source:
//---
package p;

import java.util.List;

public class C {
	@SuppressWarnings("unused") private int i00, i01, i02, i03, i04, i05, i06, i07, i08, i09;
	@SuppressWarnings("unused") private int i10, i11, i12, i13, i14, i15, i16, i17, i18, i19;
	@SuppressWarnings("unused") private int i20, i21, i22, i23, i24, i25, i26, i27, i28, i29;
	@SuppressWarnings("unused") private int i30, i31, i32, i33, i34, i35, i36, i37, i38, i39;
	@SuppressWarnings("unused") private int i40, i41, i42, i43, i44, i45, i46, i47, i48, i49;
	@SuppressWarnings("unused") private int i50, i51, i52, i53, i54, i55, i56, i57, i58, i59;
	@SuppressWarnings("unused") private int i60, i61, i62, i63, i64, i65, i66, i67, i68, i69;
	@SuppressWarnings("unused") private int i70, i71, i72, i73, i74, i75, i76, i77, i78, i79;
	@SuppressWarnings("unused") private int i80, i81, i82, i83, i84, i85, i86, i87, i88, i89;
	@SuppressWarnings("unused") private int i90, i91, i92, i93, i94, i95, i96, i97, i98, i99;
	@SuppressWarnings("unused") private int j00, j01, j02, j03, j04, j05, j06, j07, j08, j09;
	
	@SuppressWarnings("rawtypes") List l;
	
	void empty() {
	}
}
//---


Observations:

We accumulate > 100 problems (110 of which are "unused private field").

We detect undocumented empty block, which is configured as error.

Due to fatalOptionalError we tag the MethodDeclaration with ignoreFurtherInvestigation.

During generateCode() for this method we invoke compilationResult.getProblems().

Since problemCount > maxProblemPerUnit we reduce the problems to 100.

After this, CompilationUnitDeclaration.finalizeProblems()
 - does not see hasMandatoryErrors so we proceed to analysie @SW
 - we find two @SW declarations for which the suppressed problem got deleted

In particular @SuppressWarnings("unused") gets the infamous
   "At least one of the problems in category 'unused' is not analysed due to a compiler option being ignored"

At @SuppressWarnings("rawtypes") we incorrectly get
   "Unnecessary @SuppressWarnings("rawtypes")"


I chose undocumentedEmptyBlock arbitrarily. Any optional problem configured to error will do.
Comment 1 Stephan Herrmann CLA 2019-05-25 15:25:33 EDT
I see several ways out of this:

Never complain unused @SW or similar when we reached the limit of 100 problems. Not fully correct, when all problems have been suppressed, though, but better then the above false positives.

When generateCode() calls getProblems() don't let this destructively reduce CompilationResult.problems, at least keep a copy of the full list, so that CUD.finalizeProblems can still match all @SW annotations.
If we have thousands of problems, reducing them for each method with errors - which involves sorting by priority - _could_ potentially affect performance, but I wouldn't expect that this would be much noticeable.
Comment 2 Manoj N Palat CLA 2019-08-27 02:06:42 EDT
Bulk move out of 4.13
Comment 3 Eclipse Genie CLA 2022-07-13 05:46:39 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.