problematic re-use of ProblemIDs

[stephan-herrmann]

The ProblemIDs IncompatibleTypesInConditionalOperator and IncompatibleTypesInEqualityOperator have some "interesting" history.

IncompatibleTypesInConditionalOperator

Right from the beginning this ID was used for two different situations:

• ConditionalExpression, see ProblemReporter.conditionalArgumentsIncompatibleTypes(ConditionalExpression, TypeBinding, TypeBinding)
  • this might be obsolete in 1.8, see Simplify ConditionalExpression.resolveType() considering minimal compliance 1.8 #3089
• InstanceOfExpression, see ProblemReporter.notCompatibleTypesError() which originally expected an InstanceOfExpression and has later seen re-use for other situations, too.

IncompatibleTypesInEqualityOperator

• originally issued via notCompatibleTypesError(EqualExpression, TypeBinding, TypeBinding)
  • this method is being merged into notCompatibleTypesError(ASTNode, TypeBinding, TypeBinding) (as of [Switch][Record Patterns] Unchecked conversion error missing from ECJ #3069)

This new method is being shared from the following locations, and internally selects the ProblemID from the ast location:

• InstanceOfExpression
• Pattern
• EqualExpression

Question1:
Are toplevel patterns (i.e., not members of a RecordPattern) correctly classified during error reporting?

ID vs message

I can see that the messages issued by the compiler are ok-ish, but I wonder if it is a good idea to share IDs from ancient Java versions for new error situations. Notably: is the current classification sufficient for JDT/UI for proposing suitable quickfixes (if any)?