-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Looks into indirect types during compilation #543
Comments
An example about looking into indirectly types without extending and overriding: https://github.com/Atmosphere/atmosphere, jdt reports
in |
Improvement in this area largely depends on reproducing examples, as there can be millions of reasons for this infamous error. When we have an example, I see three possible outcomes
I do hope that the added information in the error message will help users to understand the chain of dependencies and correct their build paths for all cases (2). |
@stephan-herrmann thanks a lot for the reply.
Yeah, in my mentioned case, the added information can show where the indirect type is referenced, that's pretty good :). For that sample I mentioned in #543 (comment), since we can execute |
@CsCherrYY to better help you debug the issue it would be good to know how exactly you are able to reproduce the problem: ideally and in the end we'd need a JUnit test. As long as isolating the problem is tricky, you may of course debug the real-life version of the problem. As I don't know how ecj is invoked, the most general hint would be to use remote debugging. The most obvious breakpoint would then be on If theory tells, that the type should be found, then it's likely that OTOH, if you're more interested in finding why the compiler needed to resolve that type, tell us the call stack in which the problem was detected, and which program elements where involved. |
Well, I think I have found one of the causes from the example projects, which is about anonymous class. Given sample project: https://github.com/Atmosphere/atmosphere, we can get the mentioned error about type First of all, the indirect type However, there are serveral snippets creating an anonymous class, whose supertype is We can found the call stack shows the problem occurs when looking up the inherit methods from anonymous class: One interesting thing is that, the direct type My point is that now we will look into inherit methods in anonymous class, even though they will not be invoked. If we're invoking a method whose return type is an indirectly type not present in the classpath, we should report error indeed, but if those methods are not invoked, things can be improved here? |
@srikanth-sankaran could you join me in a thought experiment regarding this ancient, recurring problem? Background: The oldest idea I remember was to ensure that the transitive closure of all referenced classes is indeed visible to the compiler. But some transitive dependencies may be private to another dependency / library (read: not re-exported). Hence it should be visible only for that library, not for the client code, for which the team around Phillipe coined the term "forbhidden" 😄 - Still nobody actually put this idea into code, perhaps because we have no general solution to actually retrieve all transitive dependencies (since JDT is agnostic towards all build systems). Next we have tried to avoid resolving a few types here and there, but nothing systematic came from that. Every other bug report in this area (correctly) states that for this particular program that particular lookup was not necessary, but it seems each program would need its own strategy of what to resolve and more importantly: when. But we learned the hard way that toying with the (order of) our systematic phases of compilation is very risky. New? Idea Could we, instead of such hard core changes, "simply" defer the
Please see that currently the drastic abort is done because at the point where it happens we are analysing binary classes and hence cannot blame any particular source code. If not knowing whom to blame is the problem, then perhaps waiting until we have a location to blame would be the natural solution, no? Since overloading implies we don't know which exact method in a given type hierarchy is needed when, I feel that recording the selector is the right level of caution. You can't call |
I will. Would love to see this vexing problem get some solution. Give me a couple of days please. |
Include slf4j.api and org.apache.sshd.osgi on the build classpath to work around a JDT bug[1] in Eclipse newer than 2023-12. [1] eclipse-jdt/eclipse.jdt.core#543 Bug: egit-35 Change-Id: Icac5492f2285d6563782ee4f3fe0bf6e08c1357e Signed-off-by: Thomas Wolf <[email protected]>
Hi @stephan-herrmann I think your outline looks promising enough - I don't have any holes to poke, why don't we prototype this and see - perhaps the new behavior could come under a preference and we can selectively ask people who complain about this problem to try the option and report feedback. Folks impacted by #1842 could be the initial testers - |
Glad to help testing with my reported problem. |
fixes eclipse-jdt#543 + tolerate missing types during BTB.resolveTypesFor(MethodBinding) + new parameterCompatibilityLevel NEED_MISSING_TYPE + when NEED_MISSING_TYPE is encountered during resolution answer ProblemMethodBinding(ProblemReason.MissingTypeInSignature) + for varargs invocation try to discern if a missing type is relevant Tests: + adjust expected secondary errors (neither is better than the other) TODO: + check all call paths into parameterCompatibilityLevel() + fields
Good news: |
fixes eclipse-jdt#543 + tolerate missing types during BTB.resolveTypesFor(MethodBinding) + new parameterCompatibilityLevel NEED_MISSING_TYPE + when NEED_MISSING_TYPE is encountered during resolution answer ProblemMethodBinding(ProblemReason.MissingTypeInSignature) + for varargs invocation try to discern if a missing type is relevant Tests: + adjust expected secondary errors (neither is better than the other) TODO: + check all call paths into parameterCompatibilityLevel() + fields
Has the PR been validated against this sample project ? Either by you @stephan-herrmann or by pulling in @CsCherrYY for help ?? I am not sure this would help @chrisrueger's report - As @stephan-herrmann mentioned elsewhere |
@srikanth-sankaran just want to mention here too, that i got my problem solved. See #1842 (comment) |
+ tolerate missing types during BTB.resolveTypesFor(MethodBinding) + new parameterCompatibilityLevel NEED_MISSING_TYPE + when NEED_MISSING_TYPE is encountered during resolution answer ProblemMethodBinding(ProblemReason.MissingTypeInSignature) + for varargs invocation try to discern if a missing type is relevant + detect when method return type can be ignored + detect missing types during type inference - don't let constraint with missing type fail type inference - prefer that candidate during overload resolution + let more locations propagate HasMissingType + improve collectMissingTypes() & protect against infinite recursion Tests: + adjust expected secondary errors (neither is better than the other) + Java50Tests pointed to incomplete impl. at compliance below 1.8 => restrict new policy to 1.8+ + DependencyTests.testMissingClassFile() + bump test to 1.8 and let it include positive & negative cases + MultiProjectTests.test461074_error() split to 1.5 and 1.8 variants: + no change at 1.5 + no longer an error at 1.8+ + improved errors in GenericsRegressionTest_1_8.testBug525580*() et al + fix JCL_LIB -> JCL18_LIB in ImportRewrite18Test + JavaSearchBugsTest2: - fix tests by adding required import - create one test variant with missing import and POTENTIAL_MATCH fixes #543
+ tolerate missing types during BTB.resolveTypesFor(MethodBinding) + new parameterCompatibilityLevel NEED_MISSING_TYPE + when NEED_MISSING_TYPE is encountered during resolution answer ProblemMethodBinding(ProblemReason.MissingTypeInSignature) + for varargs invocation try to discern if a missing type is relevant + detect when method return type can be ignored + detect missing types during type inference - don't let constraint with missing type fail type inference - prefer that candidate during overload resolution + let more locations propagate HasMissingType + improve collectMissingTypes() & protect against infinite recursion Tests: + adjust expected secondary errors (neither is better than the other) + Java50Tests pointed to incomplete impl. at compliance below 1.8 => restrict new policy to 1.8+ + DependencyTests.testMissingClassFile() + bump test to 1.8 and let it include positive & negative cases + MultiProjectTests.test461074_error() split to 1.5 and 1.8 variants: + no change at 1.5 + no longer an error at 1.8+ + improved errors in GenericsRegressionTest_1_8.testBug525580*() et al + fix JCL_LIB -> JCL18_LIB in ImportRewrite18Test + JavaSearchBugsTest2: - fix tests by adding required import - create one test variant with missing import and POTENTIAL_MATCH fixes eclipse-jdt#543
Today I saw this error in my default SDK workspace, using latest nightly 4.33 M2 build. |
Ups, I didn't steal What exactly did the error say?
This issue avoids reporting missing types, when those are not really needed during compilation. There is only one part of the fix, where detection of missing types has been made more complete, notably when a missing type is referenced from the bound of a type variable. This surfaced, e.g., in eclipse/xtext#3102, but there it affects a test that intentionally works without java libraries. Nothing of this causes a type to be missing, all this is only about how we react after a type is found to be missing. No, what you describe sounds like some other flakiness in reading system libraries. |
+ tolerate missing types during BTB.resolveTypesFor(MethodBinding) + new parameterCompatibilityLevel NEED_MISSING_TYPE + when NEED_MISSING_TYPE is encountered during resolution answer ProblemMethodBinding(ProblemReason.MissingTypeInSignature) + for varargs invocation try to discern if a missing type is relevant + detect when method return type can be ignored + detect missing types during type inference - don't let constraint with missing type fail type inference - prefer that candidate during overload resolution + let more locations propagate HasMissingType + improve collectMissingTypes() & protect against infinite recursion Tests: + adjust expected secondary errors (neither is better than the other) + Java50Tests pointed to incomplete impl. at compliance below 1.8 => restrict new policy to 1.8+ + DependencyTests.testMissingClassFile() + bump test to 1.8 and let it include positive & negative cases + MultiProjectTests.test461074_error() split to 1.5 and 1.8 variants: + no change at 1.5 + no longer an error at 1.8+ + improved errors in GenericsRegressionTest_1_8.testBug525580*() et al + fix JCL_LIB -> JCL18_LIB in ImportRewrite18Test + JavaSearchBugsTest2: - fix tests by adding required import - create one test variant with missing import and POTENTIAL_MATCH fixes eclipse-jdt#543
Hello, I know it's an error message with a long history with eclipse:
There are still a lot of related eclipse issues open: https://bugs.eclipse.org/bugs/show_bug.cgi?id=328057, https://bugs.eclipse.org/bugs/show_bug.cgi?id=508306, https://bugs.eclipse.org/bugs/show_bug.cgi?id=533490, https://bugs.eclipse.org/bugs/show_bug.cgi?id=461074, https://bugs.eclipse.org/bugs/show_bug.cgi?id=545108 and so on.
after investigating, I found that in most cases, if xxx is a type belongs to JDK (e.g., java.lang.Object), the cause is likely the JDK configuration issue. If xxx is a type from external dependency, it looks like ecj has troubing when looking into indirectly types. Recently #327 improves the error massage so that in come cases we can get the exact error type to do troubleshooting. But this error is still exists and keep troubling users.
I can imagine serveral scenarios we will look into/need those indirect types:
Serveral thoughts and questions (please correct me if I'm missing any background :)):
The text was updated successfully, but these errors were encountered: