-
Notifications
You must be signed in to change notification settings - Fork 12.9k
Simplify call resolution logic #26481
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@sheetalkamat No, this has no effect on #26426. |
@typescript-bot test this por favor |
Heya @RyanCavanaugh, I've started to run the extended test suite on this PR at bfe7f02. You can monitor the build here. It should now contribute to this PR's status checks. |
Running RWC locally to get diffs |
@weswigham running the tests locally doesn't yield any diffs. Ideas? |
@RyanCavanaugh the test fails if rwc on master isn't clean. The bot should open a PR on our RWC repo with the diff if there is one. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the code change.
I'm a bit surprised no more of our baselines relied on the progressive retry of unexcluding arguments.
Also I assume performance improves noticeably for some code bases? Might be interesting to know if that's true.
return getLiteralType(name.text); | ||
case SyntaxKind.ComputedPropertyName: | ||
const nameType = checkComputedPropertyName(name); | ||
return isTypeAssignableToKind(nameType, TypeFlags.ESSymbolLike) ? nameType : stringType; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should probably be handling late bound names.
eg,
const methodName = "method";
class Foo {
@dec [methodName] {}
}
Unless I'm mistaken and for some reason checking with the more specific name is undesirable.
This PR simplifies our call resolution logic. Over time the
resolveCall
function had gotten quite unwieldy, particularly in thegetEffectiveArgumentXXX
functions that abstracted over access to the argument list. We now always construct an argument list and useSyntheticExpression
nodes to represent synthetic arguments. Also, for reasons not entirely clear, we would include context sensitive arguments one at a time, with intervening full rounds of inference and applicability checking, instead of just including all of them in one go. The code is now easier to follow and about 250 lines shorter.