[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[jdt-core-dev] 1.5 source using a apilevel JLS2
|
Hi,
Here is the start of a discussion in
order to determine what should be the resulting tree when a DOM/AST tree
is created using a compilation unit that contains 1.5 constructs and an
api level JLS2. The 1.5 nodes don't exist in JLS2. Using JLS3 apilevel,
this is not an issue since all new 1.5 constructs are available.
See the attached document and please
give us your feedback.
Thanks,
OlivierConverting 1.5 code using JLS2 api level (https://bugs.eclipse.org/bugs/show_bug.cgi?id=59052)
1) What do we have right now?
Right now we blow up with a IllegalArgumentException saying that this conversion in not implemented yet. This should be considered
as an internal error case. This is the case that should not happen, but it is happening since we have a 1.5 source that is converted
using a JLS2 api level. It means that something that cannot be represented in JLS2 is showing up.
2) What could we do?
When we have to convert a 1.5 compiler node in JLS2 mode, we could:
2.1. Create fake JLS2 node tagged as MALFORMED
Create a fake node (like an EmptyStatement) known in JLS2 world and tag it as MALFORMED.
The problem with this solution is that we don't get any error in the compilation unit problem list. Note that we
could however add problem that says something like "AST subtree is not representable in JLS2.0 mode". That fake node doesn't mean anything, so it should
never be traversed. The AST visitor should skip a MALFORMED node and its corresponding subtree.
2.2. Create a JLS3 node tagged as MALFORMED
Create a JLS3 node and tag it as MALFORMED. The problem with this solution is that the user is not expecting JLS3 node
in the resulting tree. We need to define how bad it is for the user to get JLS3 nodes. If we consider that MALFORMED nodes should not
be investigated, then this should not really be a problem except that JLS3 nodes should not show up in JLS2 tree.
2.3. Not create any node and tagged the parent as MALFORMED
We could simply skip the creation of such nodes and tag the parent as MALFORMED. This is not completely true also, because the parent is not MALFORMED.
Only the 1.5 construct is MALFORMED and in fact is simply not supported in JLS2 conversion.
Right now we don't have a good solution to reprensent a 1.5 source using JLS2 rules. Ideally we want to be able to expose a tree that could be used
outside of the 1.5 code constructs. The rest of the tree must be usable. The 1.5 constructs should only invalidate subpart of the tree.