-
Enhancement
-
Resolution: Fixed
-
P3
-
7
-
b51
-
unknown
-
generic
-
Verified
After the fix of 6735840 we have new types/symbol visitor printer in Types. Those visitors could be refined by current diagnostic formatters in order to provide better diagnostic output. In particular, they could help in improving:
*) localization support - as the visitors have full support for localized output
*) improving wildcards diagnostics
The latter point it's quite intruguing as wildcards-related diagnostics have always been quite hard to grasp for the average programmer - in the first place it would be good at least to generate a more user-friendly numeric identifier for captured-type variables, instead of relying on Object.hashcode(). Note that the actual output for captured type-variables severely limits the predictability of error messages containing captured types (because hash always changes!). This makes it almost impossible to write e.g. a simple negative regression test that compares the output of the compiler against a golden file.
Another problem is that the current output for captured type-variables might go into an endless loop if the bound of the captured type variables contains the variable itself; e.g.
#420-captureof ? extends Enum<#420-captureof ... >
This poses serious issues when generating more complex type-system diagnostics - note that this situation is very rare but it's actually needed by another type-system fix - see 6369605
*) localization support - as the visitors have full support for localized output
*) improving wildcards diagnostics
The latter point it's quite intruguing as wildcards-related diagnostics have always been quite hard to grasp for the average programmer - in the first place it would be good at least to generate a more user-friendly numeric identifier for captured-type variables, instead of relying on Object.hashcode(). Note that the actual output for captured type-variables severely limits the predictability of error messages containing captured types (because hash always changes!). This makes it almost impossible to write e.g. a simple negative regression test that compares the output of the compiler against a golden file.
Another problem is that the current output for captured type-variables might go into an endless loop if the bound of the captured type variables contains the variable itself; e.g.
#420-captureof ? extends Enum<#420-captureof ... >
This poses serious issues when generating more complex type-system diagnostics - note that this situation is very rare but it's actually needed by another type-system fix - see 6369605
- relates to
-
JDK-6369605 Unconstrained type variables fails to include bounds
- Closed
-
JDK-6492019 Overhaul compiler diagnostics
- Resolved
-
JDK-6735840 Need a type/symbol visitor printer
- Closed