Stop elaborating errors when relating intersection constituents #7203
Conversation
| @@ -5522,7 +5522,7 @@ namespace ts { | |||
| // A & B = (A & B) | (C & D). | |||
| if (source.flags & TypeFlags.Intersection) { | |||
| // If target is a union type the following check will report errors so we suppress them here | |||
| if (result = someTypeRelatedToType(<IntersectionType>source, target, reportErrors && !(target.flags & TypeFlags.Union))) { | |||
| if (result = someTypeRelatedToType(<IntersectionType>source, target, reportErrors && !(target.flags & (TypeFlags.Union | TypeFlags.ObjectType)))) { | |||
There was a problem hiding this comment.
Seems like we should use structural error reporting for other things, too, like primitives or type parameters.
DanielRosenwasser
changed the title
|
@sandersn @RyanCavanaugh any thoughts? |
|
Seems like the change is simple enough and the baselines look improved. What's the worst-case scenario here? |
|
The worst scenario I could come up with is the case that the error message happens when relating a multiple intersection of giant types, say 1000+ members each. Then the error "A is not assignable to B & C & D & E & F & G -- 'A.a' is 'string' but 'B & C & D & E & F & G.a' is 'number'." means you have to go searching through B, C, D, E, F and G to find and fix property 'a'. This kind of type is common in big data/relational code, say Spark or U-SQL. In U-SQL (which I'm more familiar with), the above type results from joining giant tables, eg On the other hand, I think insufficient elaboration is better than confusingly-wrong elaboration, so I vote that we take this change. 👍 |
|
👍 |
Stop elaborating errors when relating intersection constituents
Fixes #7199