Content assist does not activate, inside if() within a switch

[stephan-herrmann]

fixes #1561

Simpler approach, using new tests from #1625

@gayanper I tried to explain with minimal code comments. LMK if this is sufficient to understand the approach.

This change is not quite complete yet:

• no explanation for changed relevance in three tests
• may need to cover more control statements: only implemented for those that are covered by tests from #1625

[gayanper]

@stephan-herrmann This approach is much elegant. I think we should go ahead with this.

[stephan-herrmann]

@stephan-herrmann This approach is much elegant. I think we should go ahead with this.

Thanks.

Would you care to resolve the TODOs mentioned above?

[gayanper]

@stephan-herrmann Could this be due to poping out the interestingEnclosings ?

[stephan-herrmann]

@stephan-herrmann Could this be due to poping out the interestingEnclosings ?

To assess the change in relevance I'd first check which ingredient to this number got lost.

[stephan-herrmann]

To answer my own question: with this change R_VOID is "added" to the relevance, which in fact is the penalty -5.

This happens during computeRelevanceForExpectingType(), where previously no expected types were known, but now we recognize that in this condition position type boolean should be expected. This lets us detect that the method return type void is a bad match.

I confirmed, that without the current change, no expected types were available, and R_VOID was never raised.

[gayanper]

I tried to see if we are missing any control conditions, I see we don't have a endVisit for ForStatement, But even without it our unit test pass with following test snippet

switch (input) {
case A:
	for (int i = 0; i < nam)
	break;
}

Do you think we are missing any ?

[stephan-herrmann]

I tried to see if we are missing any control conditions, I see we don't have a endVisit for ForStatement, But even without it our unit test pass with following test snippet

switch (input) {
case A:
	for (int i = 0; i < nam)
	break;
}

Do you think we are missing any ?

To parallel the original test case I'd try smth like this:

case A:
	for (int i = 0; nam|)
	    break;
}

i.e., completion on a direct child in the ForStatement.condition location (currently you have an intermediate binary expression).

Another check for completeness: if we have a method in scope that returns boolean and has a name starting with 'nam': do we propose it with relevance R_EXACT_EXPECTED_TYPE? I.e. is completion correctly leveraging the information from the .condition location? I'm not sure though, if CompletionEngine is complete in this regard, yet.

[gayanper]

@stephan-herrmann I added a additional test for testing the scenarios you mentioned in above comment #1953 (comment)