Fixed incorrect handling of client-initiated progress reporting for "…

[erictraut]

…onReferences" and "onExecuteCommand" handlers in language server.

[rchl]

Looks as nice as it could to me, given the circumstances. :)

I suppose the library could expose some property (isNull?) on the common WorkDoneProgressReporter interface to make it cleaner. @dbaeumer

[dbaeumer]

Opened microsoft/vscode-languageserver-node#847

[jakebailey]

I'm not sure that this will work when we package (here or pylance), as webpack will run our code through terser which strips out names. It'd appear to work when just debugging as that runs unoptimized.

[erictraut]

Oh, that's a good point. Can you think of any other ways for us to do this check? If not, we may need to wait for a change in the LSP library.

[jakebailey]

The best hack I can come up with is to call attachWorkDone to get a NullProgressReporter, then compare the constructors for identity.

const nullProgressReporter = attachWorkDone(undefined as any, undefined);

// ...
private async _getProgressReporter(reporter: WorkDoneProgressReporter, title: string, token: CancellationToken) {
    if (reporter.constructor !== nullProgressReporter.constructor) { .... }
}

[erictraut]

That's clever. Very hacky, but clever.

[jakebailey]

Oop, no, that doesn't work.

> class Foo {}
undefined
> Foo.constructor === Foo.constructor
true
> class Bar {}
undefined
> Foo.constructor === Bar.constructor
true

[jakebailey]

No, I'm silly. Those are the class's constructors, which are of course equal because that's object.

> (new Foo()).constructor === (new Foo()).constructor
true
> (new Foo()).constructor === (new Bar()).constructor
false

The hack should work. Sorry for the noise.