-
Notifications
You must be signed in to change notification settings - Fork 320
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
JavaClasspathTest.testNoJavaInClasspath fails on latest #3102
Comments
hmmmmm @szarnekow does this ring any bells. still cannot reproduce locally |
maybe in maven the maven/tycho compiled version of the array extensions class is used |
|
=> different builds, different types affected |
And jdt.core is used here, isn't it? |
i assume tycho will do |
can be reprodcued from command line |
|
@srikanth-sankaran does this ring a bell? |
the missing binding is maybe this was not reported before but now is. |
before the resolver was not even called .... => maybe also something in pde/resource/build changed |
maybe also a reace in the test. am not sure if the delete will wait for the concurrently running build |
Hi @cdietrich how can I help you? :) |
ah, maybe I can help: one of the effects of eclipse-jdt/eclipse.jdt.core@f6fe3c8 is, that ecj now more reliably sets While generally this is private business of the compiler, So: if your test indeed runs without Any questions? |
What is the expectation of a test using Java but without Java? |
Xtend will put a marker to file saying no java we use the binding.getComponent type at many places that will crash now
|
It seems that binding recovery is not enabled in this situation. In that case null must be expected even before the change in JDT. I did not change any general null contract, only fine tuned which elements of a type binding will taint the entire binding. So if resilience against missing types is desired enable binding recovery. |
So we need to figure out what the desired behavior is |
in a quick try we also cannot deal with a recovered binding
|
org.eclipse.xtext.common.types.access.jdt.TypeURIHelperTest.testBug300216() |
I know that resilience in the face of an incomplete classpath is very painful. That's what the change in JDT is all about: resilience without incorrect behavior.
In this case binding recovery sounds like the option of choice, but it may be hard to switch from an implementation that (incompletely?) expects |
If you are able to isolate the problem to one or two specific situations (like type variable bound |
need to wait for feedback from sebastian. hard to judge/do an impact analysis |
I’ll look into it next week. |
@szarnekow should temp ignore this test on 4.33? |
I was about to suggest that |
Yes please |
See #3102 Signed-off-by: Christian Dietrich <[email protected]>
org.eclipse.xtend.ide.tests.buildpath.JavaClasspathTest.testNoJavaInClasspath fails on latest
reason unclear
cannot reproduce from dev env yet.
The text was updated successfully, but these errors were encountered: