The following were reported while reviewing test/tools/javac/diags/examples:


-CantResolve.java

examples/CantResolve.java:29: cannot find symbol
        Object o = t.v;
                    ^
  symbol: variable v
1 error

I wonder why the compiler doesn't include a 'location: type-variable T', which would have the benefit of also adding a 'where' clause at the end of the diagnostic (which would help understanding why T does not have a 'v' member).


-DiamondNotSupported.java (can't remember if you already filed this):

examples/DiamondNotSupported.java:31: diamond operator is not supported in -source 1.6
        List<String> list = new ArrayList<>();
                                          ^
  (use -source 7 or higher to enable *multi-catch statement*)

-EnumConstRequired.java

I think the output of this test is actually worse than the one of the subsequent test (EnumLabelUnqualified.java), we might want to consider to unify the two keys.


-ForeachNotApplicable.java

examples/ForeachNotApplicable.java:28: foreach not applicable to expression type
        for (String a: arg) {
                       ^

two comments: (i) 'for-each' instead of 'foreach'  [so that it would be consistent with other diagnostics] and (ii) it could be helpful to add a found/required couple in order to explain why the type is not supported. E.g.

found: String
required: array or java.lang.Iterable<?>


- NotWithinBounds.java

I guess this message can be improved by adding a reference to the declared type-variable (which will cause a 'where' clause to be generated, showing the variable's declared bound)

- OperatorCantBeApplied.java

I always found this one a bit confusing - I guess that surrounding the operator ( '-'  in this case) with ' ' as in '-' would result in a cleaner message.

- PkgClashWithClass.java

It is not clear from the message what clashes with what; we should add a 'kindname' as a diagnostic argument so that the message becomes ' *class* p clashes with package with the same name'

- UndeterminedType1.java

this message should look similar to other inference messages (I did some work in this area and changed the shape of inference messages so that they look less cryptic, see InferredDoNotConformToBounds.java)