Skip to content
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

S930 misinterpret class getter as function calls #614

Closed
fxOne opened this issue Jun 27, 2017 · 2 comments
Closed

S930 misinterpret class getter as function calls #614

fxOne opened this issue Jun 27, 2017 · 2 comments
Assignees
Labels
type: bug Exceptions and blocking issues during analysis
Milestone

Comments

@fxOne
Copy link

fxOne commented Jun 27, 2017

I want to report a bug.

SonarJS version: 2.21 (build 4409)
SonarQube version: 6.3.1 (build 21392)

Rule key: javascript:S930

Reproducer

class {
  /**
   * @return {Function}
   */
  get callback() { 
    return this._callbackFn;
  }

  executeCallback(param) {
    this.callback(param);
  }
}

I'm getting the error: "callback" expects 0 arguments, but 1 was provided.

Expected behavior
There shouldn't be any error as the callback getter can return a function.

@inverno inverno added type: bug Exceptions and blocking issues during analysis code modelization labels Jun 29, 2017
@inverno
Copy link
Contributor

inverno commented Jun 29, 2017

@fxOne thanks. It's not the rule itself, it looks like our type model associates the getter to a FunctionType because accessors declarations are a special case of function declaration, but upon use they don't behave like functions : invoking this.callback does not return the get callback() {...} function as any other unparenthesized call to a method would, but rather the value returned by get callback() {}.
The type model does not reflect this peculiarity.

@inverno
Copy link
Contributor

inverno commented Sep 28, 2017

@vilchik-elena vilchik-elena added type: false positive Issue is reported when it should NOT be and removed type: false positive Issue is reported when it should NOT be labels Sep 29, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug Exceptions and blocking issues during analysis
Projects
None yet
Development

No branches or pull requests

3 participants