Typescript: Unhelpful error "Two different types with this name exist, but they are unrelated."

[andy-ms]

TypeScript Version: 2.6.0-dev.201xxxxx

Code

interface I {
    m(
        a: number,
        b: number,
        c: number,
        d: number,
        e: number,
        f: number,
        g: number,
        h: number,
        i: number,
    ): number;
}

const x: I = {
    m(a, b, c, d, e, f, g, h, i) { x; }
};

Expected behavior:

A less confusing error message.

Actual behavior:

src/a.ts(15,7): error TS2322: Type '{ m(a: number, b: number, c: number, d: number, e: number, f: number, g: number, h: number, i: nu...' is not assignable to type 'I'.
  Types of property 'm' are incompatible.
    Type '(a: number, b: number, c: number, d: number, e: number, f: number, g: number, h: number, i: numbe...' is not assignable to type '(a: number, b: number, c: number, d: number, e: number, f: number, g: number, h: number, i: numbe...'. Two different types with this name exist, but they are unrelated.
      Type 'void' is not assignable to type 'number'.

[DanielRosenwasser]

This should be a matter of just making sure the stringified types are fully displayed before comparing them.

[DanielRosenwasser]

Also potentially only doing this on type references.

[MhdTlb]

Can I work on this issue?

[andy-ms]

@MhdTlb sure.

[gcnew]

@DanielRosenwasser Isn't full stringification meant to be controlled by --noErrorTruncation?

[mhegazy]

Isn't full stringification meant to be controlled by --noErrorTruncation?

--noErrorTruncation just disables cutting the message if it is too long, before it is written. it does not change how messages are built.

[gcnew]

Maybe I've misunderstood something. I thought

This should be a matter of just making sure the stringified types are fully displayed before comparing them.

was referring to the truncated types in the message. I tested with --noErrorTruncation and they seemed to be printed in full.

[mhegazy]

Sorry i miss understood your question.. yes the issue here is caused by truncation. the comparison of the strings should not happen on a truncated one, so the error should not be disabled regardless if --noErrorTruncation is on or not.

[estaub]

I really, really need this error message to point at the files containing the two conflicting definitions!