-
Notifications
You must be signed in to change notification settings - Fork 171
Implemented ASR checks for function dependencies #2167
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
Implemented ASR checks for function dependencies #2167
Conversation
src/libasr/asr_verify.cpp
Outdated
@@ -440,6 +440,20 @@ class VerifyVisitor : public BaseWalkVisitor<VerifyVisitor> | |||
verify_unique_dependencies(x.m_dependencies, x.n_dependencies, | |||
x.m_name, x.base.base.loc); | |||
|
|||
// Dependencies of the function should be from same symbol table. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@certik Do you think this logic is on the right track for checking the that dependencies & function should be from same symbol table ?
bead745
to
8d8bbc7
Compare
|
||
require(dep_sym != nullptr, | ||
"Dependency " + found_dep + " does not belong to same parent symbol table of " + std::string(x.m_name)); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am trying to understand the logic here.
Are we ensuring that all dependencies are from the same parent symbol table?
It seems this logic is testing that all the symbols (except ExternalSymbol) are NOT from the parent symbol table. Tests pass, so I guess this is the correct logic, but I don't understand it. Once I understand it, let's document this as a comment.
ASR verify fails in Here is the stacktrace:
cc: @certik @czgdp1807 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these changes should be simultaneously applied to LFortran as well. And then both the PRs should be merged together.
Sure. I would be happy to do that. I think there are still some things left to correct in this PR. As, few tests like https://github.com/lcompilers/lpython/blob/v0.19.0/integration_tests/callback_01.py are still having dependencies that are not from same parent symbol table. As, in this one, Can this be due to some of the checks that I implemented in this PR actually fail or am I missing some places to implement the same checks ? @czgdp1807
|
Now there are two things that can be done,
Second option makes more sense to me. Defining |
@arteevraina Will you be working on this? Please let us know the status. I am marking it as draft for now. However whenever you are done, please mark it ready for review. Thanks for your work. |
Yes, I will be continuing my work on this. I was away for few days due to some work but now I will continue working on this. |
I am still reviewing this. Before we can merge, can you please also send exactly the same PR against LFortran? We have to see that it passes all the tests there as well. @czgdp1807 do you see any issues with this PR? |
Sure @certik , I will do that meanwhile. |
@czgdp1807 I have resolved all of the comments on this PR. |
@arteevraina can you please submit a PR against LFortran as well? Let's see if things work there. |
Sure @certik , I am on it. |
Regarding the lfortran PR, I replicated the changes in the lfortran for libasr folder as it is and there were some dependency checks required in ast_common_visitor class as it is unique to lfortran. After applying changes, I got some failures in integration tests, need to debug that. Will create the PR after fixing the tests locally. |
Perfect! You can submit a PR to LFortran even if it doesn't work yet. I expected there would be some fixes needed, so we can just work on it iteratively. |
PR -> lfortran/lfortran#2327 A total of 15 test cases are failing in lfortran in this PR. I am working to resolve the issues with them one by one. @certik |
@czgdp1807 can you please review this? |
warning: The module 'numpy' located in $DIR/src/bin/../runtime/lpython_intrinsic_numpy.py cannot be loaded | ||
--> tests/../integration_tests/array_01_decl.py:2:1 | ||
| | ||
2 | from numpy import empty, int16, int32, int64, float32, float64, complex64, complex128 | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ imported here | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems there are several errors like above that got committed in this PR. Are these reference errors expected or is it a bug?
ASR::symbol_t* dep_sym = x_symtab->resolve_symbol(found_dep); | ||
|
||
require(dep_sym != nullptr, | ||
"Dependency " + found_dep + " is inside symbol table " + std::string(x.m_name)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be "Dependency " + found_dep + " is not* inside symbol table "
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
correct, "not inside".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, you both are right.
I assumed the resolve_symbol
checks in parent scope only and not in the current_scope
. Now that i checked it's documentation, it checks both in current & parent scopes.
The check should will be updated like this :
SymbolTable *x_parent_symtab = x.m_symtab->parent;
instead of SymbolTable* x_symtab = x.m_symtab;
and then "inside" phrase will make sense here.
This was committed by a mistake in lcompilers#2167.
This was committed by a mistake in lcompilers#2167.
Towards: #2006
LFortran: lfortran/lfortran#2327