Add inference for 'Promise' based on call to 'resolve' #40466
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
typescript-bot
added
Author: Team
For Uncommitted Bug
|
@typescript-bot perf test |
|
Heya @rbuckton, I've started to run the perf test suite on this PR at 56a9871. You can monitor the build here. Update: The results are in! |
rbuckton
changed the title
|
@rbuckton Here they are:Comparison Report - master..40466
System
Hosts
Scenarios
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master. |
|
From the user test baselines:
|
|
For our RWC test suite, this fixes (and thus removes) a number of errors due to the improved inference. |
|
DT Tests passed, and the perf tests show no major perf regressions (numbers look about the same). |
| @@ -6903,4 +6903,77 @@ namespace ts { | |||
| return bindParentToChildIgnoringJSDoc(child, parent) || bindJSDoc(child); | |||
| } | |||
| } | |||
|
|
|||
| export function getPossibleSymbolReferencePositions(sourceFile: SourceFile, symbolName: string, container: Node = sourceFile) { | |||
There was a problem hiding this comment.
This won't work on something with Unicode escapes. It's not a blocker, but it'd be very strange.
new Promise(resolve => {
\u0072\u0065\u0073\u006f\u006c\u0076\u0065(100);
})There was a problem hiding this comment.
True, and that's documented in the find-all-references code where this function originally came from. Its unfortunate, but this heuristic is intended to improve inference in a very specific case. It might be feasible to rewrite the function to be a bit smarter (though possibly slower), by scanning the text instead of using .indexOf. That would likely help with find-all-references as well.
There was a problem hiding this comment.
(Though I'm not sure a reasonable change based on scanning could be made prior to 4.1-beta)
There was a problem hiding this comment.
Actually, scratch that. Its feasible to do. The implementation that supports unicode escapes depends on using a regular expression, so is costlier. I have a version I can push that actually tracks on the source file whether it contains identifiers with unicode escapes, and if it doesn't then it can use the existing indexOf logic, which should be faster:
I might wait on that until after this PR, however, as I'd need to also add fourslash tests for find-all-references which could be time consuming and could possibly wait until after 4.1-beta.
|
With my limited insight, this heuristic seems similar to what I requested in #36456. Would that be feasible if this PR is the way to go forward? |
sandersn
added
the
Experiment
8 tasks
|
This experiment is pretty old, so I'm going to close it to reduce the number of open PRs. |
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In #39817, we introduced a breaking change in the signature of
PromiseConstructorto ensure it is more type-safe. This unfortunately results in new errors. One class of these errors relates to code like the following:This is now an error due to the fact the type we infer for an untyped
Promisewith no contextual type isunknown. While this can be addressed by annotatingPromisewith the typevoid(i.e.,new Promise<void>(resolve => ...)), this PR looks to address this case by introducing an inference heuristic around the "revealing constructor" pattern used by thePromiseconstructor.A "revealing constructor" is a class that accepts a callback in its constructor that the constructor then invokes, providing access to one or more privileged callbacks passed as arguments:
When you create a new
Promise, the constructor will invoke theexecutorcallback with two callbacks of its own:resolveandreject.This PR introduces inference for this very specific heuristic, such that:
The specific heuristic used for inference is as follows:
Attempt to solve for
Tinnew C<T>(f => f(t)):NewExpressionTmust only accept a single parameter (pA)executor: (resolve: (value: T | PromiseLike<T>) => void) => void)resolve: (value: T | PromiseLike<T>) => void)value: T | PromiseLike<T>)If the above conditions are met then:
These inferences are given a very low priority so that inference from contextual types will have a higher priority.
Related #40231, #39817