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

[Stephan Herrmann <stephan@xxxxxxxxxxxxxxx>]

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?