Soundness: a local variable with a constant's name shadows the constant (Format.JPG read as local JPG) #321

Description

A field read of a constant such as Format.JPG is resolved to a local variable with the same simple name (JPG), if one is in scope, instead of the constant. The refinement of the local is then used, so real violations are accepted.

Minimal reproducer

import liquidjava.specification.Refinement;

public class Repro {
    enum Format { JPG, PNG }

    static void onlyPng(@Refinement("_ == Format.PNG") Format f) {}

    public static void main(String[] args) {
        Format JPG = Format.PNG;       // a local that happens to share the constant's name
        Format g = Format.JPG;         // the enum constant JPG, not the local
        onlyPng(g);                    // expected error: g is JPG
    }
}

Expected

A refinement error at onlyPng(g): g holds Format.JPG.

Actual

Correct! Passed Verification.

Removing the line Format JPG = Format.PNG; gives the expected error (g == JPG is not a subtype of g == Format.PNG), so the name clash is what hides it.

Reproduced on main at fbfb4e2.

Where

RefinementTypeChecker.visitCtFieldRead: its first branch looks the field up by simple name in the context (where the local lives) without checking that the variable found is the field being read. A candidate fix (about 5 lines, found during the review of #319) only uses the context variable when it really is that field, and otherwise falls through; it keeps all 347 tests passing.

Context

Found by the adversarial review of #319 (fix for #302): with #319 the same clash inside an if condition (if (f == Format.JPG)) turns a former crash into an accepted violation, so this should be fixed before or with #319.