Community
Participate
Working Groups
Cheetah-03 The following program doesn't reconcile properly: interface Predicate<T> { boolean is(T t); } interface List<T> { List<T> select(Predicate<T> p); } class ArrayList<T> implements List<T>, Iterable<T> { public List<T> select(Predicate<T> p) { ArrayList<T> result = new ArrayList<T>(); for (T t : this) { if (p.is(t)) result.add(t); } return result; } } Exception in thread "org.eclipse.jdt.internal.ui.text.JavaReconciler" java.lang.IllegalArgumentException: Not yet implemented: convert(class org.eclipse.jdt.internal.compiler.ast.ForeachStatement) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:1792) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:398) at org.eclipse.jdt.core.dom.ASTConverter.buildBodyDeclarations (ASTConverter.java:209) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:1936) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:931) at org.eclipse.jdt.core.dom.AST.convertCompilationUnit(AST.java:244) at org.eclipse.jdt.internal.core.CompilationUnit.buildStructure (CompilationUnit.java:151) at org.eclipse.jdt.internal.core.Openable.generateInfos (Openable.java:183) at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed (JavaElement.java:543) at org.eclipse.jdt.internal.core.CompilationUnit.makeConsistent (CompilationUnit.java:970) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation (ReconcileWorkingCopyOperation.java:58) at org.eclipse.jdt.internal.core.JavaModelOperation.run (JavaModelOperation.java:700) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation (JavaModelOperation.java:739) at org.eclipse.jdt.internal.core.CompilationUnit.reconcile (CompilationUnit.java:1111) at org.eclipse.jdt.internal.core.CompilationUnit.reconcile (CompilationUnit.java:1080) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile (JavaReconcilingStrategy.java:85) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile (JavaReconcilingStrategy.java:118) at org.eclipse.jface.text.reconciler.CompositeReconcilingStrategy.reconcile (CompositeReconcilingStrategy.java:83) at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile (JavaCompositeReconcilingStrategy.java:97) at org.eclipse.jface.text.reconciler.MonoReconciler.process (MonoReconciler.java:76) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run (AbstractReconciler.java:189)
I added a regression test to be sure that the conversion in AST.LEVEL_3_0 is not a problem. When the ast level can be set for a reconcile operation, this should be fixed.
*** Bug 59023 has been marked as a duplicate of this bug. ***
Move to JDT/UI. In 1.5 mode, please set AST level to 3.0.
We can now set the AST but we need to see whether resources are allocated to fix 1.5 bugs before 3.0 committed items are done.
removing target milestone
this is now AST.JLS3 right? I will try to put this in for RC1.
We cannot do this for now: we use a shared/chached AST for the active editor. Lots of functions are written against this AST and expect JSL2 (syntax coloring, mark occurrences, quick fixes, refactoring). They would be broken unless ported i.e. it might get worse (stuff might break in the UI thread and the editor might stop working at all) than better when we simply change the AST level.
*** Bug 63761 has been marked as a duplicate of this bug. ***
*** Bug 63985 has been marked as a duplicate of this bug. ***
I'm not a developer of Eclipse, but one suggestion might be the following: Couldn't you add a the possibility to somehow suppress the dialog displaying the error (which it does on my system, see bug 63985 for details) from appearing all the time? I can live with some things not working (after all, this is test-stuff), but the window appearing all the time bothers me. I can file a RFE later. For now I wanted to ask if there is anything I can do. Unfortunately, my next Java project should be 1.5 code, therefore I kind of depend on at least some 1.5 support.
Olivier, I think it would be better if no IllegalArgumentException is thrown but we still get an AST but one with nodes markes as malformed . Not everybody will change to AST.JLS3 right away, there will e.g. contributed plugins written for Eclipse 3.0 that will try to build an ASTs with AST.JLS2 and it can always happen that the user enters something that looks like 1.5 code. Clients of ASTParser.createAST don't expect IllegalArgumentExceptions. Moving to jdt.core
1.5 programs are not representable in AST 2 level. Creating malformed nodes or no nodes doesn't seem much different in the end, as malformed nodes couldn't be trusted anyway. Back to UI land for leveraging AST 3 level usage.
ASTParser.createAST does not spec that IllegalArgumentException to be thrown. The current way of the ASTParser to communicate that the source can't be parsed is to return a malformed tree. Jeem, is that correct?
*** Bug 65880 has been marked as a duplicate of this bug. ***
I second Martin's opinion. Throwing IllegalArgumentExceptions forces everybody to convert all of his code. Marking the tree as malformed would give clients the possibility to do the conversion step by step.
Dirk and Martin are right: ASTParser.createAST (and ICompilationUnit.reconcile) indicates that the source can't be parsed by returning an AST with node(s) marked as MALFORMED. If a JLS2 ASTParser is asked to parse a program containing a 1.5-only construct like an enhanced for, it should be returning an AST with a malformed node of some sort; it should not be throwing an exception.
We (Erich, Philippe and I) discussed this on the phone and agreed that the AST should be marked as malformed in this case. Now IAE should be thrown. The open question is which nodes are still present in the AST and which are marked as malformed. The more complete the AST is the better it is for the tooling. However marking types as malformed doesn't make to much sense either. For example for a statement like List<String> s= new List<String>(); it is fine to mark the whole class instance creation node as malformed. So I opt to mark statementa and "larger" expressions (for example an method class argument) as malformed.
Dirk - what about attaching AST3 node and tagging them as malformed into an AST2 tree ? Think of how we would represent a foreach statement, and enum declaration ?
Philippe, That would be difficult. If you have a JLS2 AST, you cannot instantiate any of the new JLS3 node types like EnhancedForStatement
Then we have a problem. What should be the node that should be tagged as malformed? For a parameterized type, we can take its erasure. But for a enhanced for statement, there is no equivalent.
Maybe you could mark the parent of the statement (probably a block) as malformed and have it contain only the parseable statements. The foreach code would then be not be represented by any node and just treated like whitespace. It would also be ok to skip all statements following the unknown code, but of course the more we have the better result we have for features like quick fix and semantic highlighting.
Reasonable AST2 placeholders feel more reasonable(empty statement or erased type reference) and these should be marked as malformed. What would be a reasonable placeholder for type parameters ? class X <E> { } --> class X {} and type decl is malformed ?
*** Bug 67763 has been marked as a duplicate of this bug. ***
First draft released. I will double-check it is working fine. 1.5 code should not produce IllegalArgumentException in JLS2 mode anymore.
Fix for bug 68602 has been released.
BTW when will there be an update available on the update site?
There is no more updates on the update site. The 1.5 stream has been merged back into HEAD. So latest integration builds contains our latest 1.5 submission. Check the jdt/core buildnotes to find out what bugs have been fixed.
I close it. Please open new bugs if you still find errors in DOM/AST tree creation with generics. Fixed and released in HEAD. Regression tests added.
Verified in I200409212000.
