Diagnostic elaboration is not consistently reported in language service

[DanielRosenwasser]

Adapted from #3275:

class GenericThingamabob<T> {
 constructor(private entity: T) {}
 add(item: T) { }
}

class CouponInfo {
 private couponTag: {};
}

class Snake {
 private snakeTag: {};
}

var blah = new GenericThingamabob(new CouponInfo());

blah.add(new Snake());
// ~~~~~~~~~~~
var x: CouponInfo = new Snake();
// ~

On the first error, I get

Argument of type 'Snake' is not assignable to parameter of type 'CouponInfo'.
 Property 'couponTag' is missing in type 'Snake'

On the second, I get

Type 'Snake' is not assignable to type 'CouponInfo'.

Note that if you turned blah.add(new Snake()); into a variable assignment like var a: CouponInfo = new Snake(), you'll get the same issue.

[Andarist]

There is a complex interplay here between headMessage, overrideNextErrorInfo , and perhaps also lastSkippedInfo.

Calls coming from checkVariableLikeDeclaration don't have any headMessage. Based on that an early return might be chosen in reportErrorResults based on !headMessage && maybeSuppress (this early return also assigns to lastSkippedInfo). This basically happens when we only test var x: CouponInfo = new Snake(); and in such a case the reported errors looks like this:

Property 'couponTag' is missing in type 'Snake' but required in type 'CouponInfo'.(2741)

It's worth noting that in this scenario the default head message that would be computed ("Type 'Snake' is not assignable to type 'CouponInfo'.(2322)") is not reported exactly because it was skipped.

The elaboration is reported here though based on the reportUnmatchedProperty call that happened when checking this variable declaration.

When we put both a function call and a variable declaration in the file, like this

blah.add(new Snake());
var x: CouponInfo = new Snake();

Then this call never~ skips reporting the headMessage part because it comes with its own headMessage. The elaboration part is reported together with it because reportUnmatchedProperty gets called when checking that function call.

So why the elaboration part is not reported for the variable declaration case? It's because when checking that we never get to reportUnmatchedProperty. It happens within propertiesRelatedTo but that gets called transitively by recursiveTypeRelatedTo and that's a heavily cached function. In the current implementation, it is intended that for each relation key errors are not always elaborated in full (it looks to me that it's the whole purpose of RelationComparisonResult.Reported).

So when checking the variable declaration we hit the cache, we never go into propertiesRelatedTo+reportUnmatchedProperty and thus we never overrideNextErrorInfo++. So this time in reportErrorResults we don't skip reporting the default head message but we also never have a chance to report the elaboration.