-
Notifications
You must be signed in to change notification settings - Fork 323
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
Inferring types of method calls on Atoms #9812
Comments
Radosław Waśko reports a new STANDUP for the provided date (2024-06-14): Progress: Work on resolution of method types. Created StaticModuleScope prototype. Was able to resolve types of some method calls! 😁 still TODO: module methods, fixing lots of stuff that's not working and cleaning up the PoC to be actually ready for merge. It should be finished by 2024-06-18. Next Day: Next day I will be working on the #9486 task. Continue work on Snowflake dialect. |
Radosław Waśko reports a new 🔴 DELAY for today (2024-06-27): Summary: There is 40 days delay in implementation of the Inferring types of method calls on Atoms (#9812) task. Delay Cause: Hard to estimate when working just 1 day a week on this, and sometimes working even less than one day when prioritizing current tasks + past 3 Thursdays (the "Types" day) I was off (vacation, public holiday and sick day). Also working only a day a week makes me lose a bit more time in 'context switch' and remembering where I left off last time, especially if the break was longer than a week if I was off on a Thursday. Possible solutions: Working full time on this would make estimations easier and progress much much faster. But probably not proposing that for now, since I do understand our priorities. But since the delay form asks for this, I do note that fact :) |
Radosław Waśko reports a new STANDUP for today (2024-06-27): Progress: Prototyping resolution of methods. Added cases to ensure that we can resolve static methods defined in a module. Some other minor improvements to testing the inference. It should be finished by 2024-07-28. Next Day: Next day I will be working on the #9486 task. Next steps are: add tests for static methods on atom type and static syntax for member methods. Then I will need to extract needed abtstractions to ensure logic is synchronized between compiler and interpreter. Tomorrow I will continue work on Snowflake |
Radosław Waśko reports a new STANDUP for today (2024-07-12): Progress: Improved warning messages on No Such Method. Fixed some regressed tests. Fixed resolution of member method calls through static syntax. Resolving the self type correctly. It should be finished by 2024-07-31. Next Day: Next day I will be working on the #9486 task. Continue Snowflake work. |
…#10587) - This PR only re-arranges code, splitting the **huge** `processModule` function into a few smaller ones. - I decided to do it, because when I was working with `processModule` on #9812 I was constantly getting lost in this huge method (this **one** method had 570 lines!) - there is too much happening at once there. Now it's been split into smaller methods, each dealing with one thing.
Radosław Waśko reports a new STANDUP for the provided date (2024-07-26): Progress: Inferring calls of field getters on atoms. WIP on handling imports for extension methods. It should be finished by 2024-07-31. Next Day: Next day I will be working on the #10609 task. Work on fixing Upload Table for Snowflake |
Radosław Waśko reports a new STANDUP for yesterday (2024-08-12): Progress: Working on processing imports in static type analysis. Trying to understand our imports system. Found a bug while trying to understand unexpected logic: #10796 It should be finished by 2024-08-31. Next Day: Next day I will be working on the same task. Continue |
Radosław Waśko reports a new STANDUP for yesterday (2024-08-13): Progress: Got basic imports prototype working (with a workaround for the yesterday's bug) - we are now able to compile std-lib without warnings :) It should be finished by 2024-08-31. Next Day: Next day I will be working on the #10742 task. Work on next tickets: transient failures in tests, bugs in Snowflake |
Radosław Waśko reports a new STANDUP for the provided date (2024-08-14): Progress: Created and merged PR making HTTP tests more stable. Implemented and tested a fix for Next Day: Next day I will be working on the #10742 task. Work on next tickets: First/Last aggregations in Snowflake. |
Radosław Waśko reports a new STANDUP for yesterday (2024-10-23): Progress: Lot of time spend on code reviews. Added prototype of resolution through re-exported methods. Not entirely working yet. It should be finished by 2024-11-30. Next Day: Next day I will be working on the same task. Add unit test for re-exports, fix |
Radosław Waśko reports a new STANDUP for yesterday (2024-10-24): Progress: Added the unit test, fixed the resolution so now re-exported methods work. Number of warnings got down to ~4, 2 of which are surely bugs and 2 need some investigation. Started cleanup: added Builder for StaticModuleScope to align with runtime variant, starting to extract common logic. It should be finished by 2024-11-30. Next Day: Next day I will be working on the same task. Continue extracting common logic and cleaning |
Radosław Waśko reports a new STANDUP for the provided date (2024-10-25): Progress: Extracted common logic for resolving methods in scope and then some common parts for building the scope. It should be finished by 2024-11-30. Next Day: Next day I will be working on the same task. Fix some bugs and prepare PR. |
Radosław Waśko reports a new STANDUP for yesterday (2024-10-28): Progress: Cleaning up the code, also extracted common logic for conversions - unused yet on type-checker side but shows us how the overall shape looks and lays foundation for next steps. Prepared PR and scheduled benchmark runs. It should be finished by 2024-11-30. Next Day: Next day I will be working on the #11330 task. Start work on multipart upload |
This ticket is part of #9811.
We currently are able to propagate types through calls of local functions that have (checked) type signatures.
However, currently we do not have any information on calls on objects. Most of Enso code relies on such calls however.
The idea of this ticket is to:
foo.bar
when the type offoo
is known.The text was updated successfully, but these errors were encountered: