Repository navigation
fix: track local map range keys and values precisely - #69
Merged
Merged
Conversation
picatz
marked this pull request as ready for review
October 9, 2026 02:57
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
Follow map iterator keys and values separately at each
Next; status stays untainted. Local reaching definitions preserve entry-specific overwrite/delete/clear behavior, scalar copies, loop-carried writes, and map identity across Phi reexecution.The implementation uses finite CFG worklists and query-local scratch storage. Direct local pointee reads have a closed-use guard; unknown aliases and helper effects retain the existing limitations. Existing map-lookup behavior, package/model scope, dependencies, and precision expectations are unchanged.
Validation
Final head:
41e8c08e1c28c39508aa9c6d5d242173a759a807.Cost and limits
48 benchmark shapes/sizes passed, with SSA construction excluded. Seven existing Linear/StringRange workloads retain identical median B/op and allocs/op. Isolated 1024-read allocation fell from about 623 MB in the initial implementation to 17.2 MB after scratch reuse. Timings were measured under concurrent load and do not support a speedup claim.
Work is O(W 脳 (I + E)) per read, plus alias/indexing/type-comparison costs. Repeated reads still repeat this work; no whole-analyzer linearity claim is made. Helper map summaries, general pointee aliases, and iteration-order/key correlations remain limited and may cause misses or conservative reports. See map-range scope and cost.
One redundant local aggregate root run was OS-killed under shared-runner load. Duplicate local work was canceled after the exact-source hosted gates passed; the hosted full logs are the integration evidence.