Repository navigation
Spurious TS7024 (Function implicitly has return type 'any'...) and TS2577 (Return type annotation circularly references itself) in TS 5.1.x #55145
Description
Bug Report
🔎 Search Terms
- TS7024: Function implicitly has return type 'any' because it does not have a return type annotation and is referenced directly or indirectly in one of its return expressions
- TS2577: Return type annotation circularly references itself
- 5.1.6 regression
🕗 Version & Regression Information
- I see the issue with TS 5.1.3-5.1.6 and the latest nightly.
- I do not see the issue with TS 5.0.4.
- This changed between versions 5.0.4 and 5.1.3
⏯ Playground Link
Variant 1 (no return type annotations, 2x TS7024)
Variant 2 (I added one return type annotation, I get TS7024 + TS2577):
💻 Code
Variant 1
function f<T extends any[]>(v: ReadonlyArray<T>) { }
f([
[
undefined,
() => { },
],
[
1,
() => {
console.log('Hello')
},
],
])Variant 2
function f<T extends any[]>(v: ReadonlyArray<T>) { }
f([
[
undefined,
(): void => { },
],
[
1,
() => {
console.log('Hello')
},
],
])🙁 Actual behavior
The code doesn't compile.
What's strange is from my tests it seems that if I run tsc filewithcode.ts it compiles fine but if I run tsc on the whole project it produces errors.
🙂 Expected behavior
I expected the code to compile.
Activity
MartinJohns commentedon Jul 25, 2023
Most likely you're having a
tsconfig.jsonwithnoImplicitAnyenabled. When runningtscon individual files the compiler won't use your project configuration, and the default value fornoImplicitAnyisfalse.jstasiak commentedon Jul 25, 2023
Oh yes,
noImplicitAnyis very much enabled (in the local project and in the playground).Andarist commentedon Jul 25, 2023
Bisected this to this diff. It should be safe to say that this has been changed by #53607
ahejlsberg commentedon Jul 25, 2023
I'll take a look.
Andarist commentedon Jul 26, 2023
For what it's worth, this circularity was introduced by this call that tries to choose between
undefinedandvoidbased on the contextual return type. That leads to requesting the other signature's return type and it requests the first one again (here) because it is in itscompositeSignatures.jstasiak commentedon Jul 28, 2023
Thank you all, I can confirm the problem is gone in the current nightly (
5.2.0-dev.20230728).