Tslint: Unexpected issue with adjacent-overload-signatures?

[jupl]

Bug Report

• TSLint version: 3.15.1
• TypeScript version: 2.0.3
• Running TSLint via: CLI
  

  TypeScript code being linted

interface X {
  (): number
  toString(): string
}

with tslint.json configuration:

{
  "rules": {
    "adjacent-overload-signatures": true,
    // ...
  },
  // ...
}

Actual behavior

Error: All 'toString' signatures should be adjacent.

Expected behavior

No error, unless I'm misunderstanding the error.

[adidahiya]

this is likely a bug, there are no test cases for it: https://github.com/palantir/tslint/blob/master/test/rules/adjacent-overload-signatures/test.ts.lint

accepting bugfix PRs!

[a-k-g]

I have another case that started failing only in 4.0.2 - this was fine in 4.0.1

• TSLint version: 4.0.2
• TypeScript version: 2.1.1
• Running TSLint via: CLI

TypeScript code being linted

export class TestClass {
    private static method() {
        // non-empty block
    };

    private state: string;

    public constructor() {
        // non-empty block
    }
}

Actual behavior

src/TestFile.ts[8, 5]: All 'null' signatures should be adjacent

Expected behavior
No errors

[a-k-g]

Also, it seems like the original bug reported on this ticket is fixed in 4.0.1 & 4.0.2. Adding the following to test/rules/adjacent-overload-signatures/test.ts.lint -

interface i7 {
    (): number
    toString(): string
}

class i8 {
    static method() {
    };
    state: string;
    constructor() {
    }
}

i7 passes on 4.0.1 and 4.0.2 both.
i8 fails on 4.0.2.

Interestingly, removing the semicolon at the end of the static method() results in a pass. So the following passes on 4.0.2 -

class i8 {
    static method() {
    }
    state: string;
    constructor() {
    }
}

[tdsmithATabc]

Class methods with trailing semicolons seem to trigger an incorrect error in this rule in 4.0.2. For me it keeps manifesting as:

All 'null' signatures should be adjacent

Admittedly the semicolons it found were unintentional, but I _think_ they're valid TypeScript (they're definitely valid ES6 and the TS spec doesn't mention them specifically, but states that TS classes extend JS classes) and that case should be handled by a different rule anyway. 😄

[andy-hanson]

I can't get All 'null' signatures should be adjacent to happen in 4.3.1.
As for the example in the original post, this method works just by examining the syntax, so it wouldn't complain about the toString() if that's the only one synactically located in that interface.

[m-wheeler]

I had this:

get foo():int {
return _foo;
}; // <--- trailing semi caused the error

set foo(value:int) {
_foo = value;
}

[ajafff]

Fixed by #2412 and #1944