improve strong mode inference error messages

[jmesserly]

from @leafpetersen

The original error message is from this code:

values.fold(values.elementAt(0) as num, math.max)

The original error message is this:

[error] Couldn't infer type parameter 'T'.

Inferred type 'num' does not work with constraints:
  Argument 'combine' inferred as '(dynamic, dynamic) → dynamic' must be a '(T, dynamic) → T'.
The type 'num' was inferred from:
  Return type             declared as 'T'   used where a 'num' is required.
  Argument 'initialValue' inferred as 'num' must be a 'T'.

I ended up with this:

The type parameter 'T' was inferred to be 'num'
  Therefore argument 'combine' should be '(num, dynamic) → num', but
   the inferred type for 'combine' is '(dynamic, dynamic) → dynamic'.
The type 'num' was inferred for 'T' because:
  Return type             declared as 'T'   used where a 'num' is expected.

The changes are:

• partially just wording: trying to avoid just saying things like "must be" or "is required', and instead try to give some intuition.
• partially using the instantiated rather than uninstantiated type when talking about why the inference failed
• In this case eliding the upwards constraints, which I think will be irrelevant with your new CL changes.

[jmesserly]

I think we'd like to get this in 1.23 as it will improve usability of the error messages. (So, a really good tradeoff in terms of effort to user happiness.)

[bwilkerson]

That would be great, but at this point the question might be: is it essential that this happen for 1.23 (that is, should we hold up the release because of this). From that perspective, I'd remove the milestone.

[jmesserly]

yes. I will do it today, so hopefully this point becomes moot.

[jmesserly]

https://codereview.chromium.org/2757233004/