Bug 344783 - [1.7][enh][compiler] Introduce new compiler warnings for potentially incorrect/unnecessary use of @SafeVarargs
Summary: [1.7][enh][compiler] Introduce new compiler warnings for potentially incorrec...
Status: NEW
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.7   Edit
Hardware: All All
: P3 enhancement with 3 votes (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-05 03:11 EDT by Ayushman Jain CLA
Modified: 2020-06-05 18:36 EDT (History)
10 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ayushman Jain CLA 2011-05-05 03:11:52 EDT
The new specs say

"Compilers are encouraged to issue warnings when this annotation type is applied to a method or constructor declaration where: 
- The variable-arity parameter has a reifiable element type, which includes primitive types, Object, and String. (The unchecked warnings this annotation type suppresses already do not occur for a reifiable element type.) 
- The body of the method or constructor declaration performs potentially unsafe operations, such as an assignment to an element of the variable-arity parameter's array that generates an unchecked warning. 
Future versions of the platform may mandate compiler errors for such unsafe operations. "

So, it'll be good to introduce compiler warnings for usage of @SafeVarargs in following cases

(1)

class SafeVar {        
	@SafeVarargs       // TODO: warn here
        // reifiable variable arity parameter type
	public static <T> List<T> asList( T abc, Object... a) {
		return null;
	}
}


(2)

class SafeVar {    
	@SafeVarargs         // TODO: warn here
	public static <T> List<T> asList( Object abc, T... a) {
		if (a.length == 1) {
			a[0] = (T) abc;    // unchecked operation
		}
		
		return null;
	}
}
Comment 1 Srikanth Sankaran CLA 2012-01-28 20:32:00 EST
See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=349669
Comment 2 Srikanth Sankaran CLA 2013-03-02 21:58:55 EST
Please implement the "varargs" suppression token to enable any new additional
warnings to be suppressed when this is implemented.
Comment 3 Stephan Herrmann CLA 2013-03-03 06:30:39 EST
See bug 349669 comment 10 for another interesting warning given by javac
that is not currently reported by ECJ.
Comment 4 Stefan Lindner CLA 2016-10-06 18:41:53 EDT
I'm using neon now and I still run into this problem when using Oracle's javac (1.8/102) on Windows 7

Having a pice of code like this

	private ICacheKey<T>[] subCaches;
	public SimpleCacheKey(final Comparator<T> comparator, final ICacheKey<T>... subCaches) {
		...
		this.subCaches = subCaches;
	}

Leads to the well known heap pollution warning. Adding annotation 

	private ICacheKey<T>[] subCaches;
	@SafeVarargs
	public SimpleCacheKey(final Comparator<T> comparator, final ICacheKey<T>... subCaches) {
		...
		this.subCaches = subCaches;
	}

makes the warning disappear in Eclipse. But Oracle's javac now issues a warning for the line

		this.subCaches = subCaches;

Oracle's javax warning can be suppresses by another annotation

	private ICacheKey<T>[] subCaches;
	@SafeVarargs
	@SuppressWarnings( "varargs" )
	public SimpleCacheKey(final Comparator<T> comparator, final ICacheKey<T>... subCaches) {
		...
		this.subCaches = subCaches;
	}

but now Eclipse reports "Unsupported @SuppressWarnings("varargs")"

Oracle's javac accepts this annotation and does no longer report any warnings but Eclise says that it's unsupported.

Why?
Comment 5 Jay Arthanareeswaran CLA 2016-10-12 05:42:37 EDT
(In reply to Stefan Lindner from comment #4)
> Oracle's javac accepts this annotation and does no longer report any
> warnings but Eclise says that it's unsupported.
> 
> Why?

Looks like we neither warn on incorrect usage of @SafeVarargs (which is what this bug is about) nor recognize "varargs" as a valid case for @SuppressWarnings.
Comment 6 Manoj N Palat CLA 2018-05-17 03:24:04 EDT
bulk move out of 4.8