Summary: | AbortCompilation in log during normal editing | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Walter Harley <eclipse> |
Component: | Core | Assignee: | Srikanth Sankaran <srikanth_sankaran> |
Status: | VERIFIED WORKSFORME | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | jarthana, Olivier_Thomann, philippe_mulet, srikanth_sankaran |
Version: | 3.3 | ||
Target Milestone: | 3.7 M3 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Walter Harley
2007-04-16 18:22:11 EDT
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. |