Regression in type inference?

[olydis]

TypeScript Version: 2.1.1, 2.1.4

Code

declare function func(callback: () => void): any;
declare function func(callback: (arg: number) => void): any;

func(argx => { });

Expected behavior:
Successfully compile, even if --noImplicitAny is set. This is the behavior we saw until 2.0.10 (which appears reasonable, the second overload of func allows inferring that argx: number).

Actual behavior:
error TS7006: Parameter 'argx' implicitly has an 'any' type

[mhegazy]

Previously the compiler silently gave argx a type any. The reason is how the compiler resolves function expressions while doing overload resolution. the change in #11905 just exposed the error. So there is no change in what types were inferred, the change is the new error being reported.

you can work around this by specifying an explicit type annotation on argx , or removing the first signature, since it does not add value here.

[olydis]

Thanks! I'm surprised the compiler silently gave argx type any, after all the tools (e.g. VSCode) show argx: number on hover, so there seems to be a difference between the TypeScript language server and compiler?!

Wait, as I understand #11905, it should skip func(callback: () => void) now during resolution? Doesn't that precisely mean that number instead of any should be inferred?

The workaround is no problem, just thought I'd let you know since this broke the unit tests of https://github.com/Azure/autorest/ today (thousands of errors). Note that we can not remove "the first signature", in our case this is owned by mochajs!

For example, see https://github.com/Azure/autorest/blob/master/src/generator/AutoRest.NodeJS.Tests/AcceptanceTests/validationTests.ts#L34
done is the thing that now supposedly has type any (while VSCode reports MochaDone), it has a number of overloads including the one that "does not add any value" (but that is mochajs code, not ours).
We based all our tests on https://mochajs.org/#asynchronous-code which worked great without type annotations so far, now everything broke.

Cheers from building 18.

[mhegazy]

Wait, as I understand #11905, it should skip func(callback: () => void) now during resolution? Doesn't that precisely mean that number instead of any should be inferred?

that was an earlier iteration of the fix. the final change did not do that.

The workaround is no problem, just thought I'd let you know since this broke the unit tests of https://github.com/Azure/autorest/ today (thousands of errors). Note that we can not remove "the first signature", in our case this is owned by mochajs!

I would change the definition in mocha.d.ts and send a PR to DT. so that other ppl do not have to run int this.

the issue is the compiler does not handle overload on arity for callbacks now, which is this case.

[olydis]

Ahhh I see, thanks!