JDK-7098660 : Write better overload resolution/inference tests
  • Type: Enhancement
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: unknown
  • Submitted: 2011-10-07
  • Updated: 2012-02-24
  • Resolved: 2012-02-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8 b12Fixed
Related Reports
Relates :  
JDK-6722234 - javac diagnostics need better integration with the type-system
Relates :  
JDK-5088624 - cannot find symbol message should be more intelligent
Relates :  
JDK-6758789 - Some method resolution diagnostic should be improved
Description
We need high quality test coverage in the overload resolution/inference area - this is crucial in order to detect regression when we start porting the inference bits in the lambda repository into the JDK 8 repository.
Comments
SUGGESTED FIX A webrev of this fix is available at the following URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/05814303a056
24-10-2011
EVALUATION There's a lot to be desired in overload resolution/inference diagnostics - in JDK7 several changes have been made to such diagnostics such as: *) provide better integration between diagnostics and type-systems (see where clauses) *) in case of overload resolution failures, list all non-applicable candidates. These diagnostics are very good to understand why a given call-site is erroneous; however they don't provide any ways for us to inspect what is the outcome of a _successful_ overload resolution/inference process. This is a big problem when writing tests in this area, as we currently have to resort to the following techniques: *) Write a positive compiler test in which the body of each candidate that should not be resolved to throws an assertion error. If resolution went as expected, no exception should be issued when running the test. *) Alternatively, write a simple positive test and verify the the bytecode generated by javac contains the decsriptor for the right method (the one the call site has been resolved to). Both techniques are somehow clumsy, as they attempt to workaround the lack of info available from javac during the resolution process. Moreover, it is nearly impossible to check whether a method has been inferred with a given signature: since method types are subject to type-erasure, it is impossible to recover the exact signature of the inferred method after the code has been generated. To address these problems, we propose a two step approach: *) have javac generate verbose resolution diagnostics that can be enabled by using an hidden option *) write a test harness that process such diagnostics and perform a set of tests on a given source code (i.e. by annotating each resolution candidate and then verifying that the candidate has generated a diagnostic that matches the info contained in the annotation).
07-10-2011