-
Notifications
You must be signed in to change notification settings - Fork 12.9k
Report error on method name for chained method calls #31414
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
@@ -28,19 +28,19 @@ tests/cases/conformance/expressions/functionCalls/callWithMissingVoid.ts(75,1): | |||
|
|||
declare const xAny: X<any>; | |||
xAny.f() // error, any still expects an argument | |||
~~~~~~~~ | |||
~ |
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 think the idea was that the argument list was supposed to be included in the range.
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.
Ah, just saw your comment in the PR.
Spoke with @RyanCavanaugh - we think just erroring on the name itself is fine, but we'd like to error on the invoked expression itself even when it's not a property access. In other words, if you don't have a property access as the target, use |
@DanielRosenwasser I'm not quite sure I understand. function getCallErrorNode(node: CallLikeExpression): Node {
if (isCallExpression(node)) {
if (isPropertyAccessExpression(node.expression)) {
return node.expression.name;
} else {
return node.expression
}
}
return node;
} Because this is breaking a lot of error messages (and they look worse IMO). Ideally, the error should include the final method name and its argument list which could be done by including a span in |
Yeah, something like that code.
Maybe we'd do this for only |
I've updated the PR so you can see for yourself. Most call argument arity errors exclude the argument list. It is more uniform with the new change though. Is there a way to report diagnostics on spans instead of nodes? |
I think this is a great first step. If we want to iterate further, we'll take another PR. |
1. When calling a non-callable expression the error span is on the call target not on the whole call 2. When calling a method, the error for overload resolution now includes the arguments (this was previously regressed by microsoft#31414)
1. When calling a non-callable expression the error span is on the call target not on the whole call 2. When calling a method, the error for overload resolution now includes the arguments (this was previously regressed by microsoft#31414)
Fixes #31365
This is a first stab at fixing the issue. It reports the error at the name of the final method call.
Ideally, the error would be reported at the argument list span for the call but I couldn't find a straightforward way to get a span for the argument list. I'm willing to the PR if we really need reporting at the argument list.