Issue implicit any in JS files on widened inferred types from initializers in binding patterns #1064
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR ports missing logic from #60083 to improve how JS initializers produce widened types and report implicit any in empty literals.
- Adds
getWidenedLiteralTypeForInitializerto centralize literal widening. - Extends
widenTypeInferredFromInitializerto report and returnany/any[]for empty literals in JS files. - Updates binding-element handling to use the new helper.
Reviewed Changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| internal/checker/checker.go | Introduces getWidenedLiteralTypeForInitializer and adjusts widenTypeInferredFromInitializer; updates binding-element call site. |
| testdata/baselines/reference/.../*.types | Updates expected baselines to reflect any/any[] instead of never for empty initializers. |
| testdata/baselines/reference/.../*.errors.txt | Adjusts error baselines to include implicit-any diagnostics for empty literals. |
Comments suppressed due to low confidence (1)
internal/checker/checker.go:17022
- This change bypasses
widenTypeInferredFromInitializer, which includes JS-specific implicit-anydiagnostics for empty initializers. Consider callingwidenTypeInferredFromInitializerhere instead ofgetWidenedLiteralTypeForInitializerto preserve those diagnostics.
return c.addOptionality(c.getWidenedLiteralTypeForInitializer(element, c.checkDeclarationInitializer(element, CheckModeNormal, contextualType)))
|
Can you remerge main here? |
…y-widening-binding-patterns
|
done |
| json = [] | ||
| + ~~~~ | ||
| +!!! error TS7031: Binding element 'json' implicitly has an 'any[]' type. |
There was a problem hiding this comment.
I also tried porting this and hit these same issues. I'm pretty sure these are exactly the things that we are aiming to prevent, but now I think the fix doesn't quite work anymore?
There was a problem hiding this comment.
I'll take a look at this tomorrow~ then
There was a problem hiding this comment.
This PR aims to issue implicit any error - and it does that... to some extent 😉 It is overly eager though. From what I can see, this one is still not handled by the reparser - and that's why we are seeing errors here. The compiler thinks it doesn't have a type annotation
This is still imperfect because JSDoc types are still WIP. This just ports some of the missing logic and some of the adjustments made in microsoft/TypeScript#60083 .
This PR is an oddball so feel free to close this as it might be better to revisit this when JSDoc types are more complete. It already fixes a couple of baselines though.