Improve binding element type inference using CheckMode - #50586
Improve binding element type inference using CheckMode #50586Babak K. Shandiz (babakks) wants to merge 4 commits into
CheckMode #50586Conversation
Signed-off-by: Babak K. Shandiz <babak.k.shandiz@gmail.com>
Signed-off-by: Babak K. Shandiz <babak.k.shandiz@gmail.com>
Signed-off-by: Babak K. Shandiz <babak.k.shandiz@gmail.com>
Signed-off-by: Babak K. Shandiz <babak.k.shandiz@gmail.com>
| // pattern. | ||
| const contextualType = isBindingPattern(element.name) ? getTypeFromBindingPattern(element.name, /*includePatternInType*/ true, /*reportErrors*/ false) : unknownType; | ||
| return addOptionality(widenTypeInferredFromInitializer(element, checkDeclarationInitializer(element, CheckMode.Normal, contextualType))); | ||
| return addOptionality(widenTypeInferredFromInitializer(element, checkDeclarationInitializer(element, reportErrors ? CheckMode.Normal : CheckMode.SkipContextSensitive, contextualType))); |
There was a problem hiding this comment.
I don't get why this'd be SkipContextSensitive, since that sets a lot of other stuff to skip work. Contextual would be the one that basically just means non-cacheable and no errors.
|
Babak K. Shandiz (@babakks) Do you want to keep working on this? I'd like to close it otherwise to avoid stale PRs. |
|
Nathan Shively-Sanders (@sandersn) I'll try to address Wesley Wigham (@weswigham)'s comment soon (before the weekend). Is that okay? |
|
Sure, no big rush, it's been months since I looked at this =) |
|
Nathan Shively-Sanders (@sandersn) Since this PR was based on an old commit of the |
Fixes #49989
Alternative to PR #50241.
Here, to prevent false circular-relationship on binding elements initialized with their siblings (like the code segment below), we've utilized
CheckModevalues other thanNormalas an indicator of suppressing type-checking errors.One gotcha in this PR was to revert the updated links (i.e.,(Sorry, that was not up-to-date)links.type) of a symbol. Because once a circular relationship error was encountered the type of the symbol is inferred to beanyand then somewhere in the call stack, the symbol's associatedlinks.typewould be assigned to that returnedanytype. So, in cases other thanCheckMode.Normalwe'd replace back thelinks.typeold value.The gotcha is that I had to suppress updating the symbol's
links.type(toanytype) for other thanCheckMode.Normalcases, because that would block further efforts to find the correct type for the symbol. Now, I'm thinking maybe it's better to also check if the returned type isanyand then do the suppression. I didn't find any better approach than this, so let me know if there's one:Further issues
Although this PR resolves common cases like the one above, but in cases like below false errors still occur. I didn't dig more to fix such issues because handling them would, in my opinion, clutter the type-checker without significant value in return due to the rarity of such usages. Please correct me if I'm wrong.