gh-93691: fix too broad source locations of for statement iterators

[iritkatriel]

Before this PR the error location covers the entire for-block (with body).

• Issue: Bytecode positions seem way too broad #93691

[miss-islington-app]

Thanks @iritkatriel for the PR 🌮🎉.. I'm working now to backport this PR to: 3.12, 3.13.
🐍🍒⛏🤖

[miss-islington-app]

Sorry, @iritkatriel, I could not cleanly backport this to 3.12 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 97b69db167be28a33688db436551a6c3c3ea4662 3.12

[bedevere-app]

GH-120399 is a backport of this pull request to the 3.13 branch.

[bedevere-bot]

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot AMD64 Fedora Stable LTO + PGO 3.13 has failed when building commit 39825a7.

What do you need to do:

1. Don't panic.
2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/1426/builds/109) and take a look at the build logs.
4. Check if the failure is related to this commit (39825a7) or if it is a false positive.
5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/1426/builds/109

Summary of the results of the build (if available):

Click to see traceback logs

remote: Enumerating objects: 16, done. remote: Counting objects: 7% (1/13) remote: Counting objects: 15% (2/13) remote: Counting objects: 23% (3/13) remote: Counting objects: 30% (4/13) remote: Counting objects: 38% (5/13) remote: Counting objects: 46% (6/13) remote: Counting objects: 53% (7/13) remote: Counting objects: 61% (8/13) remote: Counting objects: 69% (9/13) remote: Counting objects: 76% (10/13) remote: Counting objects: 84% (11/13) remote: Counting objects: 92% (12/13) remote: Counting objects: 100% (13/13) remote: Counting objects: 100% (13/13), done. remote: Compressing objects: 8% (1/12) remote: Compressing objects: 16% (2/12) remote: Compressing objects: 25% (3/12) remote: Compressing objects: 33% (4/12) remote: Compressing objects: 41% (5/12) remote: Compressing objects: 50% (6/12) remote: Compressing objects: 58% (7/12) remote: Compressing objects: 66% (8/12) remote: Compressing objects: 75% (9/12) remote: Compressing objects: 83% (10/12) remote: Compressing objects: 91% (11/12) remote: Compressing objects: 100% (12/12) remote: Compressing objects: 100% (12/12), done. remote: Total 16 (delta 1), reused 6 (delta 1), pack-reused 3 
From https://github.com/python/cpython
* branch 3.13 -> FETCH_HEAD
Note: switching to '39825a7533ccf1aa0343d14fe88015db4ee6ef93'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c <new-branch-name>
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false
HEAD is now at 39825a7533 [3.13] gh-93691: fix too broad source locations of for statement iterators (GH-120330) (#120399)
Switched to and reset branch '3.13'
configure: WARNING: no system libmpdecimal found; falling back to bundled libmpdecimal (deprecated and scheduled for removal in Python 3.15)find: ‘build’: No such file or directoryfind: ‘build’: No such file or directoryfind: ‘build’: No such file or directoryfind: ‘build’: No such file or directorymake[2]: [Makefile:3121: clean-retain-profile] Error 1 (ignored)ar: unable to copy file 'libpython3.13.a'; reason: Successmake[2]: *** [Makefile:1047: libpython3.13.a] Error 1make[1]: *** [Makefile:877: profile-gen-stamp] Error 2make: *** [Makefile:889: profile-run-stamp] Error 2

[15r10nk]

hi @iritkatriel, I integraded the bytecode changes into executing and was confused why the source-ranges changed for for-loops but not for comprehensions?

classFoo:
def__iter__(self):
assertFalsea= [xforxinFoo()]

output (Python 3.12.5):

Traceback (mostrecentcalllast):
File"/home/frank/projects/executing/codi.py", line5, in<module>a= [xforxinFoo()]
^^^^^^^^^^^^^^^^^^File"/home/frank/projects/executing/codi.py", line3, in__iter__assertFalse^^^^^AssertionError

Is there a reason for this or have they simply been forgotten?

[iritkatriel]

That a different story. Let's reopen the issue or create a new one for compressions.

[iritkatriel]

New issue: #123142