current_scope's asr_owner is pointing to nullptr.

[arteevraina]

In this testcase, current_scope->asr_owner is pointing to nullptr when orientation dependency is being added.

This simplest way to reproduce it is by adding this log at https://github.com/lcompilers/lpython/blob/main/src/lpython/semantics/python_ast_to_asr.cpp#L1190.

std::cout << ASRUtils::symbol_name(stemp) << " " << current_scope->asr_owner << std::endl;

It should log this :

orientation 0x0

[certik]

Thanks! Let's create a minimal example out of this, and then fix it by adding an ASR verify check that asr_owner is present and points to the correct ASR node, as well as the actual fix.

[arteevraina]

Here is the minimal example for this issue :

from lpython import i32

def say_hello():
    print("Hello, World!")

def main():
    i: i32
    for i in range(10):
        say_hello()
        break

main()

cc: @certik

[arteevraina]

After investigating it more throughly, it's only the case when a function is called inside for loop is time when current_scope->asr_owner is pointing to nullptr.

[ubaidsk]

@arteevraina I am yet to investigate the issue deeply but assuming that the asr_owner is not checked for nullptr in ASRVerify, I would take the following steps in the specified order to solve this:

• Add check for asr_owner == nullptr in the ASR Verify. If the asr_owner is nullptr then the ASRVerify fails.
• With the above check, the ASRVerify is now stronger/robust. Now, the example shared at current_scope's asr_owner is pointing to nullptr. #2385 (comment) should fail with LPython (because of the asr_owner == nullptr check and assuming that the asr_owner in this case is nullptr, as you mentioned).
• Now, we have a test case that runs with CPython but fails for LPython in the ASRVerfiy stage. The last step would be to debug/support this in LPython.