Community
Participate
Working Groups
I've been getting these errors in my log a couple times a day, during normal editing and debugging sessions. I am using I20070410-1023. I unfortunately do not know what causes it to happen; there is not any indication at the time it happens, I just happened to be looking at the log and saw a few of these. Let me know if there is anything I can do to gather more data. org.eclipse.jdt.internal.compiler.problem.AbortCompilation at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.abort(TypeDeclaration.java:72) at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:132) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.handle(ProblemReporter.java:1768) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.nonGenericTypeCannotBeParameterized(ProblemReporter.java:4880) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.nonGenericTypeCannotBeParameterized(ProblemReporter.java:4876) at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.resolve(ParameterizedTypeBinding.java:826) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:111) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveTypesFor(BinaryTypeBinding.java:891) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.methods(BinaryTypeBinding.java:874) at org.eclipse.jdt.core.dom.TypeBinding.getDeclaredMethods(TypeBinding.java:266) at org.eclipse.jdt.internal.corext.dom.Bindings.findOverriddenMethodInType(Bindings.java:423) at org.eclipse.jdt.internal.corext.dom.Bindings.findOverriddenMethodInHierarchy(Bindings.java:440) at org.eclipse.jdt.internal.corext.dom.Bindings.findOverriddenMethodInHierarchy(Bindings.java:445) at org.eclipse.jdt.internal.corext.dom.Bindings.findOverriddenMethod(Bindings.java:474) at org.eclipse.jdt.ui.OverrideIndicatorLabelDecorator.findInHierarchyWithAST(OverrideIndicatorLabelDecorator.java:179) at org.eclipse.jdt.ui.OverrideIndicatorLabelDecorator.getOverrideIndicators(OverrideIndicatorLabelDecorator.java:154) at org.eclipse.jdt.ui.OverrideIndicatorLabelDecorator.computeAdornmentFlags(OverrideIndicatorLabelDecorator.java:129) at org.eclipse.jdt.ui.OverrideIndicatorLabelDecorator.decorate(OverrideIndicatorLabelDecorator.java:261) at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:259) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:71) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.runtime.Platform.run(Platform.java:850) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(LightweightDecoratorManager.java:336) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:322) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:363) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:325) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
With the fix for bug 176118, we should have protected ourselves from the reconciler resolving types well after they had been processed. Seems like another case when the LookupEnvironment's unitBeingCompleted needs to be left alone.
Actually this isn't related to bug 176118. Walter - can you look around to find a source file with an error: "The type {0} is not generic; it cannot be parameterized with arguments <{1}>" Philippe - we may want to change the binary case of ProblemReporter.nonGenericTypeCannotBeParameterized() to not abort.
I believe that message is from org.eclipse.jdt.internal.compiler.problem/messages.properties. Message number 524 in that file.
Correct - so we need to see the source for your file with that error + the source for the class file that is referenced. I've tried creating a testcase & I do get the error but not the walkback.
Oh, now I understand. I don't have a file with that error; it would have been something transient that occurred during a reconcile as I was typing.
If we stop aborting, we need to change the way we handle error situations in binaries. Also, we need to check other error messages doing similar checks (check refs to AbortCompilation in ProblemReporter). I am all for becoming more resilient, but we need to be careful. Like in ParameterizedTypeBinding#resolve(), the best answer would be to return 'resolvedType' instead of this (which still contains ref to unresolved), but further references are expecting a ParameterizedTypeBinding. Also a parameterizedTypeBinding is reaching into its actualType parameters... which non generic types don't have... so tricky.
Philippe - there are 7 different errors in ProblemReporter that abort if the location == null (binary case). incorrectArityForParameterizedType nonGenericTypeCannotBeParameterized parameterizedMemberTypeMissingArguments rawMemberTypeCannotBeParameterized staticMemberOfParameterizedType typeMismatchError undefinedTypeVariableSignature
We could be a bit more resilient for some ill-formed types, like: parameterizedMemberTypeMissingArguments rawMemberTypeCannotBeParameterized staticMemberOfParameterizedType I don't see how we could improve for incorrect arity, or attempts to parameterize a non-generic type.
Kent - can you construct regression tests for each of the scenarii you described ? Then we can look at them all individually.
(In reply to comment #5) > Oh, now I understand. > > I don't have a file with that error; it would have been something transient > that occurred during a reconcile as I was typing. Are you mixing 1.5 and 1.4 projects ? i.e is a 1.5 project a required project for a 1.4 project ? Or is otherwise on the class path of a 1.4 project ? We have recently seen a slew of bugs with this set up and some of these we are seeing this situation (i.e a non-generic type being parameterized problem)
(In reply to comment #10) > Are you mixing 1.5 and 1.4 projects ? i.e is a 1.5 project a required > project for a 1.4 project ? Or is otherwise on the class path of a 1.4 > project ? > > We have recently seen a slew of bugs with this set up and some of > these we are seeing this situation (i.e a non-generic type being > parameterized problem) Hi, Srikanth. Hard to remember as that was 3+ years ago. I don't think that would have been the setup but I'm not certain. Okay to close this bug as Not Repro, and wait to see if anyone encounters it again. Maybe it's gone away through Brownian motion by now :-)
Closing as WORKSFORME as this should have been taken care of by the fix for bug 324850.
Verified for 3.7M3 using build I20101025-0901.
