361441 – Error in JDT Core during AST creation

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

Bug 361441 - Error in JDT Core during AST creation

Summary: Error in JDT Core during AST creation

Status:	RESOLVED FIXED

Alias:	None

Product:	JDT
Classification:	Eclipse Project
Component:	Core (show other bugs)
Version:	3.7.1
Hardware:	Macintosh Mac OS X

Importance:	P3 normal (vote)
Target Milestone:	3.6.2+J7
Assignee:	Ayushman Jain
QA Contact:

URL:
Whiteboard:
Keywords:

Depends on:
Blocks:

Reported:	2011-10-19 13:35 EDT by Philippe Marschall
Modified:	2012-01-19 01:40 EST (History)
CC List:	5 users (show)

See Also:

Attachments
A simple class that reproduces the bug (292 bytes, text/plain) 2011-10-19 13:36 EDT, Philippe Marschall	no flags	Details
proposed fix (1.08 KB, application/octet-stream) 2011-10-20 04:05 EDT, Ayushman Jain	no flags	Details
proposed fix (963 bytes, patch) 2011-10-20 04:12 EDT, Ayushman Jain	no flags	Details \| Diff
proposed fix v1.0 + regression tests (3.09 KB, patch) 2011-11-09 12:31 EST, Ayushman Jain	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 Philippe Marschall

2011-10-19 13:35:06 EDT

What steps will reproduce the problem?
1. create a Java 7 project
2. compile the attached class
3. an error dialog pops up


-- Error Details --
Date: Wed Oct 19 19:25:52 CEST 2011
Message: Error in JDT Core during AST creation
Severity: Error
Product: Eclipse SDK 3.7.1.v201109091335 (org.eclipse.sdk.ide)
Plugin: org.eclipse.jdt.ui
Session Data:
eclipse.buildId=M20110909-1335
java.version=1.6.0_26
java.vendor=Apple Inc.
BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US
Framework arguments:  -keyring /Users/marschall/.eclipse_keyring -showlocation
Command-line arguments:  -os macosx -ws cocoa -arch x86_64 -keyring /Users/marschall/.eclipse_keyring -showlocation

Exception Stack Trace:
java.lang.ClassCastException: org.eclipse.jdt.internal.compiler.lookup.MethodBinding cannot be cast to org.eclipse.jdt.internal.compiler.lookup.ParameterizedGenericMethodBinding
	at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.invalidMethod(ProblemReporter.java:3677)
	at org.eclipse.jdt.internal.compiler.ast.MessageSend.resolveType(MessageSend.java:435)
	at org.eclipse.jdt.internal.compiler.ast.Expression.resolve(Expression.java:947)
	at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:463)
	at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:252)
	at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:422)
	at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1148)
	at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1258)
	at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:539)
	at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1191)
	at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:681)
	at org.eclipse.jdt.core.dom.ASTParser.internalCreateAST(ASTParser.java:1181)
	at org.eclipse.jdt.core.dom.ASTParser.createAST(ASTParser.java:807)
	at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider$1.run(ASTProvider.java:544)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.createAST(ASTProvider.java:537)
	at org.eclipse.jdt.internal.ui.javaeditor.ASTProvider.getAST(ASTProvider.java:480)
	at org.eclipse.jdt.ui.SharedASTProvider.getAST(SharedASTProvider.java:128)
	at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup.calculateASTandInform(SelectionListenerWithASTManager.java:170)
	at org.eclipse.jdt.internal.ui.viewsupport.SelectionListenerWithASTManager$PartListenerGroup$3.run(SelectionListenerWithASTManager.java:155)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

Comment 1 Philippe Marschall

2011-10-19 13:36:07 EDT

Created attachment 205551 [details]
A simple class that reproduces the bug

Comment 2 Ayushman Jain

2011-10-19 15:21:37 EDT

Happens because of incorrect problem reason found during org.eclipse.jdt.internal.compiler.lookup.Scope.computeCompatibleMethod(MethodBinding, TypeBinding[], InvocationSite). 

We just assume that since invocation site is generified with type parameters and we couldn't find a matching method, the type parameters are to be blamed. But as shown in this case, this is not so. We should report an error here saying that there's no matching method corresponding to the given arguments URI and Collection<object,object>. javac 7 gives:

error: no suitable method found for newFileSystem(URI,Map<Object,Object>)
    FileSystems.<String, Object>newFileSystem(uri, Collections.emptyMap());
               ^
    method FileSystems.newFileSystem(Path,ClassLoader) is not applicable
      (actual argument URI cannot be converted to Path by method invocation conv
ersion)
    method FileSystems.newFileSystem(URI,Map<String,?>,ClassLoader) is not appli
cable
      (actual and formal argument lists differ in length)
    method FileSystems.newFileSystem(URI,Map<String,?>) is not applicable
      (actual argument Map<Object,Object> cannot be converted to Map<String,?> b
y method invocation conversion)
1 error

Comment 3 Ayushman Jain

2011-10-19 15:40:08 EDT

Basically javac7 allows us to specify type arguments for even a non-generic method, so the second last line of computeCompatibleMethod(MethodBinding,
TypeBinding[], InvocationSite) method should be removed, because type arguments in invocation site when the actual method is non generic is not the real problem.

Comment 4 Srikanth Sankaran

2011-10-20 02:00:17 EDT

I'll follow up.

Comment 5 Ayushman Jain

2011-10-20 04:05:22 EDT

Created attachment 205585 [details]
proposed fix

Passes compiler tests. Haven't run the full suite yet. But looks reasonable that we should only report a problem as having been caused by a parameterized method, not when type args have been specified at invocation site, but when this is done for an actually generic method.

Comment 6 Ayushman Jain

2011-10-20 04:12:06 EDT

Created attachment 205587 [details]
proposed fix

Git messed the above patch.

Comment 7 Ayushman Jain

2011-11-09 12:31:24 EST

Created attachment 206718 [details]
proposed fix v1.0 + regression tests

Added a test in the above patch.

Comment 8 Ayushman Jain

2011-11-09 12:36:08 EST

Released in HEAD via commit 23a0c6bd4ce9391b9f82ed7b1662678a44429de5

Comment 9 Ayushman Jain

2011-11-09 12:36:44 EST

Srikanth, this is a regression over 3.6.2. Do we want to backport to 3.7.2?

Comment 10 Srikanth Sankaran

2011-11-10 00:46:48 EST

(In reply to comment #9)
> Srikanth, this is a regression over 3.6.2. Do we want to backport to 3.7.2?

Agree with analysis and fix. 
Yes, let us backport this to 3.7.2 and 3.6.2+java7 after a bit more testing.

Comment 11 Srikanth Sankaran

2011-11-10 01:13:40 EST

Dani, this is being considered for backport to 3.7.2 and 3.6.2+java7
after a bit more testing.

Fix is small and safe and this is a regression since 3.6.2 - FYI.

Comment 12 Dani Megert

2011-11-10 02:26:25 EST

(In reply to comment #11)
> Dani, this is being considered for backport to 3.7.2 and 3.6.2+java7
> after a bit more testing.
> 
> Fix is small and safe and this is a regression since 3.6.2 - FYI.

+1.

Comment 13 Philippe Marschall

2011-11-13 10:30:24 EST

I just wanted to let you guys know that you rock. Whenever I report a bug against JDT it gets fixed and back ported quickly. Thank you.

Comment 14 Srikanth Sankaran

2011-11-13 23:27:33 EST

(In reply to comment #13)
> I just wanted to let you guys know that you rock. Whenever I report a bug
> against JDT it gets fixed and back ported quickly. Thank you.

Thank you ! For the record the fix hasn't been backported yet, we like
the fix to get some exposure on HEAD before backporting, but it us surely
in plan for 3.7.2.

Comment 15 Ayushman Jain

2011-11-23 01:43:44 EST

Released in R3_7_maintenance via commit 27bdb27668bb0d28026a2d0298321059115dd9db

Comment 16 Ayushman Jain

2011-11-24 08:33:17 EST

Jay confirmed release of this patch in 362+java7 branch via commit	d36704d1542f1e9fe5510cf4bbc33793ec815d34

Comment 17 Jay Arthanareeswaran

2011-12-05 06:08:41 EST

Verified for 3.8M4 with build I20111202-0800.

Comment 18 Srikanth Sankaran

2012-01-19 01:40:22 EST

Verified for 3.7.2RC2 using build M20120118-0800.