Bug 204536 - [1.5][compiler] Type variables insufficiently connected in presence of errors
Summary: [1.5][compiler] Type variables insufficiently connected in presence of errors
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.4   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.4 M3   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-09-25 07:50 EDT by Philipe Mulet CLA
Modified: 2007-10-30 08:13 EDT (History)
2 users (show)

See Also:

Attachments
Proposed patch (13.98 KB, text/plain)
2007-09-25 07:53 EDT, Philipe Mulet CLA 		no flags Details
Better patch (15.85 KB, patch)
2007-09-25 11:28 EDT, Philipe Mulet CLA 		no flags Details | Diff
Better patch/2 (16.61 KB, patch)
2007-09-25 16:06 EDT, Philipe Mulet CLA 		no flags Details | Diff
Show Obsolete (2) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Philipe Mulet CLA 2007-09-25 07:50:00 EDT 
Build 3.4M2

In presence of errors in type variable bounds, the compiler will usually bail out of the resolution, and thus fail to report more pending issues.

e.g.
public class X<T extends Zork & Zork & Object> {
}

It could report 3 errors at once.
Comment 1 Philipe Mulet CLA 2007-09-25 07:52:11 EDT 
Added GenericTypeTest#test1182
Comment 2 Philipe Mulet CLA 2007-09-25 07:53:31 EDT 
Created attachment 79119 [details]
Proposed patch
Comment 3 Philipe Mulet CLA 2007-09-25 11:28:25 EDT 
Created attachment 79137 [details]
Better patch
Comment 4 Philipe Mulet CLA 2007-09-25 11:32:20 EDT 
Also added GenericTypeTest#test11183-1184
Comment 5 Philipe Mulet CLA 2007-09-25 16:06:07 EDT 
Created attachment 79165 [details]
Better patch/2
Comment 6 Philipe Mulet CLA 2007-09-25 16:13:58 EDT 
Released for 3.4M3.
Fixed
Comment 7 Maxime Daniel CLA 2007-10-29 09:24:49 EDT 
Verified for 3.4 M3 using build I20071029-0010.

IMHO, test1184 shows a limit rather than an added value (isn't it reporting a secondary error that could have been avoided by using an error type which extends Runnable anyway?), but the initial test case is definitely addressed.
Comment 8 Philipe Mulet CLA 2007-10-29 12:49:28 EDT 
?!?
The test is proving that when unable to resolve the first bound, the second bound doesn't magically replace it from thereon.
Comment 9 Maxime Daniel CLA 2007-10-29 13:38:52 EDT 
My point was only that the erroneous type we had in hand still satisfied to Runnable. It was not about forgetting that it is erroneous. It was about still knowing something about it.
Comment 10 Maxime Daniel CLA 2007-10-30 08:13:36 EDT 
After discussing the point with Philippe, we decided to open a specific bug to address the point. See bug 207959.