Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 548899

Summary: Explicit constructor invocation bindings are not resolved if it isn't first statement
Product: [Eclipse Project] JDT Reporter: Ivan Ivan <stoshins>
Component: CoreAssignee: JDT-Core-Inbox <jdt-core-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: stephan.herrmann
Version: 4.13   
Target Milestone: ---   
Hardware: PC   
OS: Windows NT   
Whiteboard:
Attachments:
Description Flags
Main2.java
none
Input source none

Description Ivan Ivan CLA 2019-07-03 04:57:32 EDT
Created attachment 279161 [details]
Main2.java

Hi, I know this code is invalid, but nevertheless there are no any reasons why it shouldn't be resolved

Input source:
class Test {
	public Test() {
		;
		this(1);
	}

	public Test(int i) {
	}
}

Code to test:
		public void acceptAST(String sourceFilePath, CompilationUnit ast) {
		    TypeDeclaration td = (TypeDeclaration) ast.types().get(0);
		    MethodDeclaration md = (MethodDeclaration) td.bodyDeclarations().get(0);
		    ConstructorInvocation ci = (ConstructorInvocation) md.getBody().statements().get(1);
		    System.out.println("" + ci.resolveConstructorBinding());
		}


And it prints null! But if I remove ";" and change "md.getBody().statements().get(1)" to "md.getBody().statements().get(0)" it will print the binding. 

Can you please do something with the bug?
Comment 1 Ivan Ivan CLA 2019-07-03 04:58:06 EDT
Created attachment 279162 [details]
Input source
Comment 2 Stephan Herrmann CLA 2019-07-03 10:55:43 EDT
(In reply to Sergey Toshin from comment #0)
> Created attachment 279161 [details]
> Main2.java
> 
> Hi, I know this code is invalid,

I agree, and of course ecj reports:

"Constructor call must be the first statement in a constructor"

> but nevertheless there are no any reasons
> why it shouldn't be resolved

I disagree. Correctly resolved bindings are guaranteed only for error-free code. Many errors actually cause compilation to abort at some level. In this case I believe the entire constructor will remain unresolved.

Do you see any API contract violated by the current behavior? Which?
Comment 3 Ivan Ivan CLA 2019-07-03 11:02:02 EDT
> Do you see any API contract violated by the current behavior?

No, I don't. It's just a wish :) But looks like the decompiler's developer agreed to comment out all statements before a constructor call, so I will close the issue