Community
Participate
Working Groups
Build Identifier: 20120216-1857 Lines like the following cause a problem: public <$T extends SelectableChannel & WritableByteChannel> void aFunction($T $obj) { This causes the following stack trace to appear on the console: Exception in thread "org.eclipse.jdt.internal.ui.text.JavaReconciler" java.lang.IllegalArgumentException at org.eclipse.jdt.internal.compiler.util.Util.scanTypeVariableSignature(Util.java:1349) at org.eclipse.jdt.core.Signature.appendTypeSignature(Signature.java:913) at org.eclipse.jdt.core.Signature.appendTypeSignature(Signature.java:855) at org.eclipse.jdt.core.Signature.toCharArray(Signature.java:2637) at org.eclipse.jdt.core.Signature.toString(Signature.java:2848) at org.eclipse.jdt.internal.core.Member.findMethods(Member.java:100) at org.eclipse.jdt.internal.core.util.Util.getUnresolvedJavaElement(Util.java:1445) at org.eclipse.jdt.core.dom.MethodBinding.getUnresolvedJavaElement(MethodBinding.java:254) at org.eclipse.jdt.core.dom.MethodBinding.getJavaElement(MethodBinding.java:240) at org.eclipse.jdt.internal.ui.javaeditor.SemanticHighlightings$DeprecatedMemberHighlighting.consumes(SemanticHighlightings.java:1232) at org.eclipse.jdt.internal.ui.javaeditor.SemanticHighlightingReconciler$PositionCollector.visit(SemanticHighlightingReconciler.java:169) at org.eclipse.jdt.core.dom.SimpleName.accept0(SimpleName.java:149) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514) at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2562) at org.eclipse.jdt.core.dom.SimpleType.accept0(SimpleType.java:137) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514) at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2562) at org.eclipse.jdt.core.dom.ParameterizedType.accept0(ParameterizedType.java:174) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514) at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2562) at org.eclipse.jdt.core.dom.ClassInstanceCreation.accept0(ClassInstanceCreation.java:332) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514) at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2562) at org.eclipse.jdt.core.dom.VariableDeclarationFragment.accept0(VariableDeclarationFragment.java:225) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2585) at org.eclipse.jdt.core.dom.VariableDeclarationStatement.accept0(VariableDeclarationStatement.java:273) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2585) at org.eclipse.jdt.core.dom.Block.accept0(Block.java:136) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514) at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2562) at org.eclipse.jdt.core.dom.MethodDeclaration.accept0(MethodDeclaration.java:504) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2585) at org.eclipse.jdt.core.dom.TypeDeclaration.accept0(TypeDeclaration.java:484) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2585) at org.eclipse.jdt.core.dom.CompilationUnit.accept0(CompilationUnit.java:219) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514) at org.eclipse.jdt.internal.ui.javaeditor.SemanticHighlightingReconciler.reconcilePositions(SemanticHighlightingReconciler.java:371) at org.eclipse.jdt.internal.ui.javaeditor.SemanticHighlightingReconciler.reconciled(SemanticHighlightingReconciler.java:321) at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.reconciled(CompilationUnitEditor.java:1664) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconciled(JavaReconcilingStrategy.java:212) at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconciled(JavaCompositeReconcilingStrategy.java:164) at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.initialReconcile(JavaCompositeReconcilingStrategy.java:144) at org.eclipse.jface.text.reconciler.MonoReconciler.initialProcess(MonoReconciler.java:105) at org.eclipse.jdt.internal.ui.text.JavaReconciler.initialProcess(JavaReconciler.java:406) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:173) Syntax highlighting for that file fails almost entirely (comments (both block and inline), keywords, and operator characters are still highlighted, even if added to the file after the exception occurs). All actual parsing otherwise appears to be fine; inline compile errors for example are still flawless. Problem also existed in Indigo SR1, however in that release the problem would hang all eclipse (that is, after alt-tabbing in and out eclipse would fail to render anything at all and does not respond to keystrokes). In Indigo SR2 (that is, the build ID I'm submitting the bug with) once the exception is thrown it is not rethrown when refreshing the file or under any action I'm aware of except closing and reopening the file. Reproducible: Always Steps to Reproduce: 1. Open a file with the described line. 2. ... 3. Profit The problem will also begin to manifest after adding the described line to an existing file and continuing to edit the file thereafter even without closing and reopening the file; it's a bit harder to concisely explain the results of that, but essentially though highlighting will not revert through most unmodified lines, new highlighting will fail.
I cannot reproduce this pasting either your code from comment 0 or this complete example: package snippet; import java.nio.channels.SelectableChannel; import java.nio.channels.WritableByteChannel; public class Snippet { public <$T extends SelectableChannel & WritableByteChannel> void aFunction( $T $obj) { } } I'm used the latest 3.8 build (http://download.eclipse.org/eclipse/downloads/drops/I20120419-1434/) and a new workspace. Can you please try with that build and if you can reproduce, provide more detailed steps? Thanks.
Alright, I owe you several corrections, sorry... - I thought I had pared lines to reproduce down to that function earlier, but it seems I either misremembered or wasn't thorough enough. The following actually works in a clean fresh workspace: package snippet; import java.nio.channels.SelectableChannel; import java.nio.channels.WritableByteChannel; class Snippet<$T extends SelectableChannel & WritableByteChannel> { public Snippet($T $obj) {} } The class having the type parameter is fine; having a no-args constructor goes fine; adding the generically typed argument to the constructor goes south. This example has a slightly shorter stack trace than that trace I posted earlier, though the beginning and end remain the same and only the repeating area around ASTNode changed. Will attach if you like but hopefully this example allows you to reproduce anyway. - The exception will consistently occur when opening a file for edit that already contains the problem code. The exception will also occur if pasting the example into an empty java file. Opening a file containing the example class and no body will not cause the exception; adding the constructor line will promptly cause the exception; removing the constructor line and readding it will not cause the exception to reappear unless you also close and reopen that file. - I was wrong about the issue never causing total unresponsiveness in SR2. It seems to be rarer, but still occurs. I cannot yet figure out any particular trigger to reproduce that; only that the syntax highlighter break is a prerequisite. (I haven't yet downloaded a nightly from your link; I reached a "file unavailable" page? Will continue to look for that now.)
Thanks Eric for the updated code snippet. I can now easily reproduce the bug with this. The bug got introduced during 3.7.
Problem comes from incorrect handling of $ in the identifier name. Which also means, until a fix is made a workaround is to rename the type variables concerned to not have $ in the identifier name.
This is still present in juno SR2. Stack trace same as original report.
(In reply to comment #5) > This is still present in juno SR2. Stack trace same as original report. We haven't looked at it yet and unlikely in Kepler's time frame. Is there a compelling reason to use $ in the type parameter name? If now, you can use the workaround suggested in comment #4.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
