-
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
MethodCall
info for infix operators
#6374
Comments
Dmitry Bushev reports a new STANDUP for yesterday (2023-06-12): Progress: Started working on the issue. Was finishing the work on the replay tool POC. End up with a version that can work with a freshly created project. Started working on integration with engine VCS system. It should be finished by 2023-06-19. Next Day: Next day I will be working on the #6374 task. Continue working on the task |
Dmitry Bushev reports a new STANDUP for today (2023-06-13): Progress: Continue working on the issue. Was working on the library updates PR and making it ready to merge. It should be finished by 2023-06-19. Next Day: Next day I will be working on the #6374 task. Continue working on the task |
Dmitry Bushev reports a new STANDUP for yesterday (2023-06-14): Progress: Continue working on the issue. Added the test scenario. Started debugging where the method information comes from. Found that the IrToTruffle pass does not create the method node that contains the information require to build a method pointer It should be finished by 2023-06-19. Next Day: Next day I will be working on the #6374 task. Continue working on the task |
Dmitry Bushev reports a new STANDUP for today (2023-06-15): Progress: Continue working on the issue. Was debugging the codegen compiler pass. Added creation of the method node containing information about the method pointer. It didn't fix the issue. Continued debugging. Found that the method resolution returns the builtin function definition and not the one created in the codegen. Continued the debugging. It should be finished by 2023-06-19. Next Day: Next day I will be working on the #6374 task. Continue working on the task |
Dmitry Bushev reports a new STANDUP for yesterday (2023-06-16): Progress: Continue working on the issue. Figured out that the builtin methods were not redefined due to the auto-registration feature. Disabled the registration of builtin methods during the compilation. It fixed the method resolution but revealed a different error with method invocation. Continue debugging It should be finished by 2023-06-19. Next Day: Next day I will be working on the #6374 task. Continue working on the task |
Dmitry Bushev reports a new STANDUP for yesterday (2023-06-19): Progress: Continue working on the issue. Fixed the method invocation of wrapped builtin. Started working on fixing the tests. Had to re-enable the auto-registration of builtins because some getters of the builtin constructors are not generated in the codegen. Started looking for a fix with a method registration. It should be finished by 2023-06-19. Next Day: Next day I will be working on the #6374 task. Continue working on the task |
Dmitry Bushev reports a new 🔴 DELAY for today (2023-06-20): Summary: There is 2 days delay in implementation of the Delay Cause: A lot of unexpected issues came up after I changed the registration of builtin methods in the compiler. Had to resolve them one by one as they appear. |
Dmitry Bushev reports a new STANDUP for today (2023-06-20): Progress: Continue working on the issue. Allowed to redefine the builtin methods. Fixed another issue with the invocation of builtin method wrapper. Continue working on fixing the tests. It should be finished by 2023-06-21. Next Day: Next day I will be working on the #6374 task. Continue working on the task |
Dmitry Bushev reports a new STANDUP for yesterday (2023-06-21): Progress: Continue working on the issue. Debugged and fixed an issue when the compiler was unable to resolve some symbols after the clean build. Created the PR It should be finished by 2023-06-21. Next Day: Next day I will be working on the #6374 task. Continue working on the task |
Dmitry Bushev reports a new 🔴 DELAY for yesterday (2023-06-22): Summary: There is 2 days delay in implementation of the Delay Cause: Still resolving the issues that showed up after the registration of builtins was changed. Plenty of corner cases were covered, a bit more needs to be fixed |
Dmitry Bushev reports a new STANDUP for yesterday (2023-06-22): Progress: Continue working on the issue. Implemented a workaround for method dispatch override of Any methods. Started a discussion about how to fix that properly. Started working on the issue with the Meta.get_atom_constructor builtin. It should be finished by 2023-06-23. Next Day: Next day I will be working on the #6374 task. Continue working on the task |
Dmitry Bushev reports a new STANDUP for today (2023-06-23): Progress: Continue working on the issue. Debugged and fixed the issue with the suspended method invocation (...). Fixed more runtime tests. Started fixing the stdlib tests. It should be finished by 2023-06-23. Next Day: Next day I will be working on the #6374 task. Continue working on the task |
close #6374 In order to provide the method pointer information, the `IrToTruffle` pass sets the module name and the type name of the builtin node.
@farmaazon Just checked the latest state and while backend added the support, somehow we are not seeing the expected results in IDE still. @4e6 will investigate if the problem is in backend or GUI. |
When a binary operator application is present in the project source module, the backend should associate a
methodPointer
and method info with theOprApp
node. Currently it seems to do so occasionally (code making use of this information was introduced in 73487ad), but I'm not sure what circumstances reach it--usually themethodPointer
is missing.In particular, we need to receive the information reliably for a graph like this:
With method information for the
+
operator above, we will be able to display an appropriate placeholder argument similarly to how we create placeholders for non-operator method calls, fixing the secondary issue mentioned hereThe text was updated successfully, but these errors were encountered: