Fix locations in intermediate statements #253
Merged
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.
This PR fixes some spurious locations mismatches by extracting the recursive calls (such as
EtsAssignStmt(location = loc(), lhv = <recurse>, rhv = <recurse>)
) withensureOneAddress
inside them. Without extracting these sub-expressions,loc()
produces a location that might be "reused" by anotherloc()
call insideensureOneAddress
(which creates extra assignment statement for complex expressions, thus allocates and fills a location). The proper way of doing it is to ensure thatlhv
andrhv
are computed (and all necessary extra statements are already created and put insidecurrentStmts
) before callingloc()
for the newly created statement.In fact, not all extractions that were made in this PR are strictly necessary for the correctness, but I just made the code changes uniform and consistent.