-
Notifications
You must be signed in to change notification settings - Fork 200
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
Better function scanning. #1579
Comments
I think finding |
Note: mixins may also be annotated with |
Note to self: Methods are implemented here: https://github.com/Polymer/polymer-analyzer/blob/master/src/javascript/esutil.ts Functions are implemented here: https://github.com/Polymer/polymer-analyzer/blob/master/src/javascript/function-scanner.ts |
Ah ok, good call. @justinfagnani was advocating for an explicit |
How about |
After starting to implement this, I found that we actually already support |
That's functions inside object literals though, do we have it for top-level statements too? edit: sorry, I mixed this up with another issue related to |
You're right that we don't support it for top-levels, though. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Analyzer doesn't currently find functions that are declared by assignment, which is a common pattern in Polymer core.
For example, we find
Polymer.Async.timeOut.after
, but notPolymer.Async.timeOut.run
. The former is declared with a normal function declaration, while the latter is with an assignment with abind
call.This is why the Polymer API docs are incomplete for some namespaces. For example, https://www.polymer-project.org/2.0/docs/api/namespaces/Polymer.Async.timeOut is missing
run
andcancel
. Similar story for https://www.polymer-project.org/2.0/docs/api/namespaces/Polymer.Async.animationFrame and others.I think what's going on is that Analyzer just looks for function declarations, so because the actual expression doesn't look like a function, it's not scanned at all. Scope analysis could solve this in a more principled way, but the simpler fix is to either pick up on the
@return
and@param
annotations and assume that a function has been defined regardless of the actual expression syntax, or to require that such cases are annotated explicitly with something like@type {Function}
.As part of this, I think we should try to unify the function and method scanning logic, which obviously has a large overlap. A few features (e.g. rest parameters, optional parameters) are currently only supported for methods, so we'd also get those extended to functions by doing this refactoring.
The text was updated successfully, but these errors were encountered: