Rule warns on overloads, and "fixes" overloads to make an *actual* error

[ChiriVulpes]

/**
 * Remove the context menu from this element
 */
public setContextMenu(): void; // lint warn on method name
/**
 * Set the context menu for this element
 */
public setContextMenu(generator: () => IContextMenu): void; // lint warn on method name
@Bound 
public setContextMenu(generatorOrContextMenu?: GetterOfOr<IContextMenu>) { // lint warn on method name

After fixer:

/**
 * Remove the context menu from this element
 */
@override public setContextMenu(): void; // ts error cause decorators here are invalid
/**
 * Set the context menu for this element
 */
@override public setContextMenu(generator: () => IContextMenu): void; // ts error cause decorators here are invalid
@override
@Bound
public setContextMenu(generatorOrContextMenu?: GetterOfOr<IContextMenu>) {

[hmil]

That is a weird edge case. Thanks for bringing it up. Indeed I did not consider overloaded methods, and even less overriden, overloaded methods.

From a pure type checking perspective, you don't really need to specify the overloaded versions of the function, you should only need the function implementation itself (which won't trigger this bug). But for some reason, intellisense doesn't report the function in its overloaded form when you override the implementation only.

I'll take a look at this