From 7e4532f4a3281abce389810c048ab4b70f4c7c74 Mon Sep 17 00:00:00 2001 From: Daniel Rosenwasser Date: Tue, 23 Feb 2016 20:18:35 -0800 Subject: [PATCH] Never elaborate errors when relating from intersections. --- src/compiler/checker.ts | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/src/compiler/checker.ts b/src/compiler/checker.ts index 28dd5406cc0..558489b6e33 100644 --- a/src/compiler/checker.ts +++ b/src/compiler/checker.ts @@ -5521,8 +5521,20 @@ namespace ts { // on either side that need to be prioritized. For example, A | B = (A | B) & (C | D) or // 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(source, target, reportErrors && !(target.flags & (TypeFlags.Union | TypeFlags.ObjectType)))) { + // Check to see if any constituents of the intersection are immediately related to the target. + // + // Don't report errors though. Checking whether a constituent is related to the source is not actually + // useful and leads to some confusing error messages. Instead it is better to let the below checks + // take care of this, or to not elaborate at all. For instance, + // + // - For an object type (such as 'C = A & B'), users are usually more interested in structural errors. + // + // - For a union type (such as '(A | B) = (C & D)'), it's better to hold onto the whole intersection + // than to report that 'D' is not assignable to 'A' or 'B'. + // + // - For a primitive type or type parameter (such as 'number = A & B') there is no point in + // breaking the intersection apart. + if (result = someTypeRelatedToType(source, target, /*reportErrors*/ false)) { return result; } }