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

Add type resolution to function calls, properties, etc... #73

Open
angelolloqui opened this issue Apr 15, 2018 · 4 comments
Open

Add type resolution to function calls, properties, etc... #73

angelolloqui opened this issue Apr 15, 2018 · 4 comments
Labels

Comments

@angelolloqui
Copy link
Owner

This is a big epic as it will require a lot of work on top of the AST to perform type resolutions. From a very high level point of view, this will require:

  1. Allow to find the declaration node of a local variable/constant: It will require to traverse the local AST and all parent siblings until it finds the declaration variable/constant node.
  2. Allow to extract the type from a declaration node: If type is explicit, we can use it as resolved type. If not, then we should look me able to look at the called function/property/expression and restart the type resolution from there
  3. Index all code files from a project: When the expression/function/property found in 2 is from an outer file, we should be able to find it in a previously indexed list of project files and ASTs.
  4. Include code from Foundation and other popular Swift modules to the type resolution index.

Number 1 and 2 are to some extent workable (although big work), but right now all others will require huge amounts of effort and big changes in the way the tool and the AST works. Nevertheless, if ever achieved, it could help to:

  • Add override keywords when implementing protocol methods (required in Kotlin)
  • Make proper translations of common foundation methods like count, first, etc over arrays, dictionaries,...
  • Prefix enum names to the enum case and match casing (ex: replace .present by Animation.PRESENT)
  • Fix primary constructors (Kotlin requires () pattern in the main constructor when using inheritance but only on those that are classes and not protocols, but currently the AST does not know if it is one or the other)
  • .... many other subtle improvements....
@daxios-learn
Copy link

@angelolloqui : have you managed to find an approach for 3 ?

@namanhams
Copy link

Switching account from daxios-learn .

I'm trying to do (3) for my open source project here : https://github.com/grab/swift-leak-check

@angelolloqui
Copy link
Owner Author

Interesting @namanhams ! I have abandoned a little the project in last months (but not discontinued, I have plans to continue improving it), and I have not even started with this. Can you post your findings when your are done? Or even better if you also point me to your implementation! 👏

Thanks!

@namanhams
Copy link

Sure @angelolloqui !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants