[Feature]Variable loc info PR1 : Fix main #loc storage key conflict #186
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR fixes a critical bug where the main
#locdirective was stored with key"1", which caused a collision with#loc1when both exist in the same IR file. The fix changes the storage key for the main#locfrom"1"to""(empty string).Problem
In TTIR/TTGIR files, location directives can appear in two forms:
#loc = loc("file.py":10:5)(no number suffix)#loc1 = loc("file.py":20:10),#loc2 = loc("file.py":30:15), etc.Previously, the main
#locwas stored with key"1", which conflicts with#loc1. When both exist,#loc1would overwrite the main#locentry, causing incorrect source mapping.Solution
#locfrom"1"to""(empty string)extract_code_locations()to map bare#locreferences to"0"(preserved for backward compatibility)#locand#loc1are stored separately without collisionChanges
File:
tritonparse/ir_parser.pylocations["1"]→locations[""]Impact
#locand#loc1existTesting
Existing tests pass. The change is minimal and focused on the key conflict issue.
Related PRs