Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 344655

Summary: [1.7][compiler] Prohibit use of <> with explicit type arguments to generic constructor
Product: [Eclipse Project] JDT Reporter: Srikanth Sankaran <srikanth_sankaran>
Component: CoreAssignee: Srikanth Sankaran <srikanth_sankaran>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: amj87.iitr, raksha.vasisht
Version: 3.7Flags: amj87.iitr: review+
Target Milestone: 3.7.1   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Proposed patch + tests none

Description Srikanth Sankaran CLA 2011-05-04 02:13:25 EDT 
The latest iteration of specs ban the use of <> with explicit type
arguments to a generic constructor. Eclipse compiler must be changed
to reject these cases.
Comment 1 Srikanth Sankaran CLA 2011-05-10 04:46:15 EDT 
Created attachment 195184 [details]
Proposed patch + tests

This patch also simplifies the implementation of Scope.getStaticFactory().
Comment 2 Srikanth Sankaran CLA 2011-05-10 06:24:32 EDT 
All tests pass. Released in BETA_JAVA7 branch.
Ayush, please review along with the <> implementation's
review. TIA.
Comment 3 Ayushman Jain CLA 2011-05-24 10:40:18 EDT 
Patch looks good. Just one small comment:
Is there any reason for checking of this case in both AllocationExp and QualifiedAllocExp AFTER the type arguments have been resolved and it has been ascertained whether there is an error or not?
The argHasError set when an error is found in resolution is only processed after the place where the new warning is reported and null is returned. So, in cases where I use an invalid syntax such 
new <Blah> X<>("")

maybe it'll be better to just ascertain at the beginning that this is an invalid syntax and report the new warning and not go ahead and try resolve Blah. I'm not sure though if it has other side effects.
Comment 4 Srikanth Sankaran CLA 2011-05-24 10:59:13 EDT 
(In reply to comment #3)

> maybe it'll be better to just ascertain at the beginning that this is an
> invalid syntax and report the new warning and not go ahead and try resolve
> Blah. I'm not sure though if it has other side effects.

The compiler's strategy in general is go ahead and report as many
orthogonal problems as it can while avoiding secondary errors i.e
errors that arise due to inadequate repair from the primary error.
In this case, this would indeed be the case.
Comment 5 Ayushman Jain CLA 2011-05-25 03:17:49 EDT 
+1 then
Comment 6 Raksha Vasisht CLA 2011-07-20 04:15:08 EDT 
Verified.