You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 478eb94
Browse filesBrowse the repository at this point in the historyBrowse files
Resolve field reads by declaring type and target object (#321, #322)
A field read first looked up the field's simple name in the context. Since
#327 fields live there only under their qualified name, so that lookup could
only find an unrelated local with the same name: Format.JPG was read as the
local JPG (#321). That branch is removed.
The context variable this#C.f tracks the value of the field of the current
object, but reads of the same field on another object (other.val) used it
too, so facts about this.val leaked into other.val (#322). Utils gains
accessesTrackedField, true for static fields and for this/super/Outer.this
targets; field reads on any other target use the field's declared
refinement instead, in visitCtFieldRead and in the operand and compound
assignment paths of OperationsChecker. Limits.max vs this.max (the first
#322 reproducer) was already fixed by the qualified names of #327 and gets
a regression test.
Fixes#321Fixes#322
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: liquidjava-verifier/src/main/java/liquidjava/processor/refinement_checker/general_checkers/OperationsChecker.java
0 commit comments