RE: [jdt-core-dev] null receiverType in ExplicitConstructor.resolve?

[Philippe P Mulet <philippe_mulet@xxxxxxxxxx>]

Stephan is almost a JDT committer...
he knows the internal so well, I do not have a problem him using this mailing
list.
Actually, Stephan, wouldn't you want
to help us building JDT/Core, and earn commit rights ? <g>

Re: your issue.
It indeed does look suspicious. When
I added support for 196200, I did introduce more resilience, but could
have failed to get rid of some unneeded null checks elsewhere.
I do not believe we could get a null
receiverType other than through superclass (for super invocation). 
Constructing a testcase for the NPE
to occur would definitely prove the issue, but until then a bug report
is fair.

Like for the following code, the resolution
of #super() is intercepted in constructor declaration directly, so we would
not enter the constructor call with a null receiverType (coming from Object's
superclass which is null).

package
java.lang;
public
class
Object {
       
public
Object() {
       
        super();
       
}
}

"Walter Harley" <eclipse@xxxxxxxxxxxxxx>
Sent by: jdt-core-dev-bounces@xxxxxxxxxxx

07/04/2008 06:40 PM

Please respond to
"Eclipse JDT Core developers list." <jdt-core-dev@xxxxxxxxxxx>

To	"'Eclipse JDT Core developers list.'" <jdt-core-dev@xxxxxxxxxxx>
cc
Subject	RE: [jdt-core-dev] null receiverType in ExplicitConstructor.resolve?

Hi, Stephan.

Given that you're actually working on a branch of the JDT, it's probably
okay to ask here, but it would still be better to post to
eclipse.tools.jdt.  As it says on http://www.eclipse.org/mail,
"Technical questions and discussions about using eclipse and
eclipse-based tools, and developing plug-in tools should be posted to
the newsgroups. Mailing lists at eclipse.org are intended for use by
developers actually working on or otherwise contributing to day-to-day
development. The development mailing lists are the way design and
implementation issues are discussed and decisions voted on by the
committers. " 

That said: most of what drove bug 196200 was the desire to reach parity
with javac regarding behavior of the typesystem (e.g., as viewed through
the APT API) when compiling defective code.  The checks are not
generally paranoia checks, they're motivated by individual reports of
discrepancies, and it's certainly possible we missed something.  Many
of
the regression tests for this are in the JDT APT JSR269 test suites
(org.eclipse.jdt.apt.pluggable.tests).  As you've probably discovered,
it is harder to cover all possible scenarios of defective code than all
possible scenarios of correct code :-)

The behavior you're seeing certainly could be a compiler bug.  Are
you
seeing it in cases where correct code is being compiled, or incorrect
code?

I would suggest going ahead and filing a bug report.

Thanks,
  -Walter Harley
   JDT APT lead


> -----Original Message-----
> From: jdt-core-dev-bounces@xxxxxxxxxxx 
> [mailto:jdt-core-dev-bounces@xxxxxxxxxxx] On Behalf Of 
> Stephan Herrmann
> Sent: Friday, July 04, 2008 6:25 AM
> To: jdt-core-dev@xxxxxxxxxxx
> Subject: [jdt-core-dev] null receiverType in 
> ExplicitConstructor.resolve?
> 
> Hi,
> 
> I found an NPE in my logs where I'm having difficulties to 
> spot who's at fault.
> Something's looking strange in the compiler, but the NPE 
> _could_ also just be my fault.
> 
> The NPE occurred in ExplicitConstructorCall:383 (as of head / 1.65):
>                  }
else if (receiverType.erasure().id == 
> TypeIds.T_JavaLangEnum) {
> 
> The strange thing: there's plenty of checks whether 
> receiverType==null both above and directly below the 
> suspicious line. This makes me think that the patch for bug 
> 196200 perhaps just forgot this one null-check.
> 
> OTOH I can't find a test case were receiverType actually _is_ null.
> Neither scope.enclosingReceiverType() nor 
> receiverType.superclass() have an obvious way of returning null.
> 
> My question: are you aware of any scenarios that actually 
> produce a null here?
> If so, it should be easy to create a regression test.
> If not, are all those null-checks in 
> ExplicitConstructorCall.resolve just "paranoia" checks?
;-) 
> It seems like you have placed those checks very carefully..
> 
> FWIW: The stack trace indicated that the 
> CompilationUnitProblemFinder was driving this compile run. 
> However, the stack wouldn't directly help you much, because 
> it was produced by our branch of jdt.core.
> 
> Could this be a bug in the jdt?
> 
> best,
> Stephan
> 
> PS: is it OK to ask pre-bugzilla questions here?
> _______________________________________________
> jdt-core-dev mailing list
> jdt-core-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jdt-core-dev
> 

_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jdt-core-dev



Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
Compagnie IBM France
Siège Social : Tour Descartes, 2, avenue Gambetta, La Défense 5, 92400
Courbevoie
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 542.737.118 euros
SIREN/SIRET : 552 118 465 02430