-
-
Notifications
You must be signed in to change notification settings - Fork 30.2k
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
LOAD_GLOBAL instruction with wrong source position #91409
Comments
The LOAD_GLOBAL instruction has a different/wrong source position if it refers the name of an imported module. |
You should have pasted in the actual position tuples you saw that show the presumed bug.
I don't know why the Positions.lineno does not match starts_lines, but your report is about columns. Here they match. |
@terryjreedy The problem seems is be back in 3.11.0b4 (on ubuntu) import dis
dix = 5
def f():
dis.b() # wrong source range
dix.b() # correct source range
d = [bc for bc in dis.Bytecode(f) if bc.opname == "LOAD_GLOBAL"]
print(d)
assert len(d) == 2
# LOAD_GLOBAL has a wrong end column if the global value is an imported module
assert d[0].positions[2:] == d[1].positions[2:] == (4, 7) output:
can we open this issue again? |
You changed from 'global name is an imported module name' to 'global object is an imported module. I revised by example to cover both and ran with freshly updated and compiled 'main' and '3.11' and installed 3.11.0b4'.
Output on Win 10:
For all 3 names, end - start == 3. Same with each on separate line. Please run a pasted copy of the code above on your machine. If output is different, paste a copy. |
I got the same results like you and there are no problems if we only lookup the global variable. The source range extends to the name of the called function if we call an function on a imported module. import dis
dix = dis
dum = 5
def f():
dis.a()
dis.abc()
dis.a
dis
dix.a()
dum.abc()
for i in dis.Bytecode(f):
if i.opname == "LOAD_GLOBAL":
print(i.positions) output:
you can see that the method name gets included in the range. This should be not the case in my opinion. Or are there any reasons for this Behaviour? There is also no Problem for attribute lookups like I also bisected the bahavior change down to 3011a097bd. Maybe this helps. |
@markshannon @pablogsal LOAD_GLOBAL of a name bound by import has an erroneous end_col_offset if followed by LOAD_METHOD and calls. OP bisected to #31933, 3011a097bd. (15... Thanks for doing that.) Tests in additional to those already posted above:
outputs
|
…ions (pythonGH-95067). (cherry picked from commit 742d461) Co-authored-by: Brandt Bucher <brandtbucher@microsoft.com>
Thank you Brandt for the nice fix and tests. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: