False-positive void-return in dtslint after adding awaited

[Maxim-Mazurok]

TypeScript Version: from 3.9.0-dev.20200321 to 3.9.0-dev.20200324

Code

declare namespace gapi.client {
    function load(name: "abusiveexperiencereport", version: "v1"): PromiseLike<void>;
    function load(name: "abusiveexperiencereport", version: "v1", callback: () => any): void;
}

Expected behavior:
dtslint uses rule void-return which didn't fail for the above code and shouldn't fail.

Actual behavior:
When dtslint is paired with typescript version since this commit: e3ec7b1 which was merged in #35998 - it fails:

ERROR: 17:80  void-return  Use the `void` type for return types only. Otherwise, use `undefined`. See: https://github.com/Microsoft/dtslint/blob/master/docs/void-return.md
ERROR: 18:89  void-return  Use the `void` type for return types only. Otherwise, use `undefined`. See: https://github.com/Microsoft/dtslint/blob/master/docs/void-return.md

---

Related to Maxim-Mazurok/google-api-typings-generator#101

[Maxim-Mazurok]

Sorry, it seems like a dstlint issue actually.
It's using bundled TS (node_modules/dtslint/nodemodules/typescript) for rules, but project's TS (node_modules/typescript) for parsing sources before running rules on them.
So, node kinds reported by older TS version are not matching with the new ones (for example, SyntaxKind.VoidKeyword). That's what was causing problems, as node kinds were updated in this PR.
Probably it would be great to have backward-compatibility in this matter, so I'm not closing the issue.

[RyanCavanaugh]

We don't support this kind of back compat

[Maxim-Mazurok]

@RyanCavanaugh I hear you. But what if we could support it?
From what I understand, it would require changing

TypeScript/src/compiler/types.ts

Lines 124 to 127 in a1c8608

	export const enum SyntaxKind {
	Unknown,
	EndOfFileToken,
	SingleLineCommentTrivia,

to

export const enum SyntaxKind { 
     Unknown = "Unknown", 
     EndOfFileToken = "EndOfFileToken", 
     SingleLineCommentTrivia = "SingleLineCommentTrivia",

Kind of like it was did in

TypeScript/src/compiler/types.ts

Lines 4207 to 4210 in a1c8608

	export const enum InternalSymbolName {
	Call = "__call", // Call signatures
	Constructor = "__constructor", // Constructor implementations
	New = "__new", // Constructor signatures

Another approach is to do this like for different flags

TypeScript/src/compiler/types.ts

Lines 4163 to 4166 in a1c8608

	export const enum CheckFlags {
	Instantiated = 1 << 0, // Instantiated symbol
	SyntheticProperty = 1 << 1, // Property in union or intersection type
	SyntheticMethod = 1 << 2, // Method in union or intersection type

so it will look like

export const enum SyntaxKind { 
     Unknown                 = 1 << 0, 
     EndOfFileToken          = 2 << 0, 
     SingleLineCommentTrivia = 3 << 0,

or even simpler:

export const enum SyntaxKind { 
     Unknown                 = 0, 
     EndOfFileToken          = 1, 
     SingleLineCommentTrivia = 2,

Any of these approaches will preserve enum values and make TS even more back compat :) What do you think?

[Maxim-Mazurok]

@rbuckton what do you think about #37551 (comment) ?
I think if we use this approach - we can eliminate potential issues when updating SyntaxKind in the future.