Bugzilla – Full Text Bug Listing
| Summary: | Accepts illegal method-local classes if hidden by generics parameters | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Chris West (Faux) <eclipse> | ||||||||
| Component: | Core | Assignee: | Srikanth Sankaran <srikanth_sankaran> | ||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | amj87.iitr, Olivier_Thomann, satyam.kandula | ||||||||
| Version: | 3.6 | Flags: | satyam.kandula:
review+
|
||||||||
| Target Milestone: | 3.7 M1 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows Vista | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
Srikanth, please review. Created attachment 168624 [details]
Add regression tests
Created attachment 168713 [details]
Patch under consideration
Here is an odd behavior from javac:
case (1)
class Y {
class X {}
void foo() {
class X {}
}
}
doesn't elicit any messages while
case (2)
class Y {
class X {}
<X> void foo() {
class X {}
}
}
elicits:
Y.java:4: X is already defined in <X>foo()
class X {}
^
1 error
With respect to case (1), eclipse behavior is similar to javac
with or without this patch.
With respect to case(2) the proposed patch implements the same
behavior, but that is not appropriate and the compiler's behavior
should be similar to case (1)
Created attachment 168727 [details]
Revised patch under test
Targetting 3.7M1 JLS3 sections 8.1 and 9.1 disallow class A and B of comment# 0 ("A compile-time error occurs if a class has the same simple name as any of its enclosing classes or interfaces.") Note that this says nothing about the enclosing type being visible there (i.e, not already being shadowed) This is the subject matter of the current defect and is addressed by the proposed patch. The shadowing rules for type variables are ill specified in the JLS (as acknowledged in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5060485). 14.3 Local Class Declarations is silent about type variables in scope having the same simple name as the local type. 6.3.1 Shadowing Declarations is silent about type variables. 4.4 Type Variables defers to 6.3 for scoping rules for type variables, but that section does not give the shadowing rules. 8.4.4 Generic Methods: gives the scoping rules for type parameters but is silent about legalities of shadowing. Eclipse compiler starting with https://bugs.eclipse.org/bugs/show_bug.cgi?id=165662, has always allowed a local type to shadow a type variable in scope. The current patch leaves this behavior unchanged. Thus the following code: class Y { class X {} <X> void foo() { class X {} } } which refuses to compile with javac continues to compile without a problem (as before) with this patch. Satyam, please review -- Thanks. It will help if the bug numbers are associated with the new tests added. All the other changes look good. +1 Thanks Satyam. I have added defect URLs to unit tests. Released in HEAD for 3.7 M1 Verified for 3.7M1 using build I20100802-1800. |
Build Identifier: I20100506-0800 I believe both of the following classes are illegal for the same reason that class C is: class C { void foo() { class C {}}} Eclipse: ^ The nested type C cannot hide an enclosing type. sun6javac: ^ C is already defined in unnamed package Eclipse, however, unlike Sun javac (1.6.0_19-b04 win64), does not issue that error for the following classes: class A { <A> void foo() { class A {}}} class B<B> { void foo() { class B {}}} This code is not sensible as (as far as I'm aware) it's not possible to refer to the method-local classes in any way. Reproducible: Always Steps to Reproduce: 1. Paste class A or B into any Java editor. 2. Observe error.