Comment 1 Philipe Mulet 2002-11-02 12:08:05 EST

I suspect it is getting late for 2.0.2

Comment 2 Olivier Thomann 2002-11-02 17:47:20 EST

The fix is trivial. It is already done in 2.1 stream since the 9th of September 
2002.

Comment 3 Philipe Mulet 2002-11-04 08:54:40 EST

Unfortunately, 2.0.2 is frozen already (unless a critical defect was found).
I don't think this one qualifies as critical.

Comment 4 Philipe Mulet 2002-11-04 08:55:58 EST

Olivier - is there a work-around for this one ? Would source positions be 0 for 
such an implicit constructor call or something like that ?

Comment 5 Olivier Thomann 2002-11-04 13:17:41 EST

There is no real workaround.
In 2.0.2 stream, an implicit super will have the same starting position than the
name of the corresponding constructor declaration.
The fix consists in replacing:
if (explicitConstructorCall != null)...

with:
if (explicitConstructorCall != null && explicitConstructorCall.accessMode !=
ExplicitConstructorCall.ImplicitSuper) ....

in the ASTConverter.convert(AbstractMethodDeclaration methodDeclaration).

Comment 6 Philipe Mulet 2002-11-05 07:21:12 EST

Is the access mode indicating it is an ImplicitSuper on the DOM AST side ?

Comment 7 Olivier Thomann 2002-11-05 08:18:19 EST

No, because an implicit super call should not be a node in the DOM/AST tree.

Comment 8 Philipe Mulet 2002-11-12 09:09:02 EST

Closing, source positions are to be checked to tell the difference until the 
proper fix is made (it is in 2.1 stream).

Source positions would correspond to the constructor name.

Closing.