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

["Walter Harley" <eclipse@xxxxxxxxxxxxxx>]

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
>