An OptionInstance enum default chosen by a condition is recorded as the else-arm constant

Crate: tools/minecraft-options

Commit: f844b107

Behavior

analyse_option_window records enum_default_constant from the last getstatic of an enum-typed field in the window tail. It does not check whether that getstatic is a jump target or inside a branch (Insn.join / Insn.conditional, set by mark_control_flow). A definition such as new OptionInstance<>(..., cond ? Mode.A : Mode.B, ...) gets the else-arm constant as a high-confidence default, either through the enum default resolution in analyse_option_window or through the later string-token pass in analyze_jar (record.get('default') is None and constant).

The valueOf, Boolean.valueOf, boolean factory and constructor field-initializer sites already refuse conditional constants (#581); the enum site does not.

Expected behavior

An enum default constant is accepted only when its getstatic runs unconditionally (runs_unconditionally on the getstatic and its consumer). Otherwise the default stays unproven with the conditional-default note. A regression test covers a ternary enum constant.

Impact

A scan of all 52 cached release JARs found no window where this happens today, so shipped data is unaffected, and the fix must not change either committed data file for those releases. A future release with a conditional enum default would get a wrong proven default.

Locations

• tools/minecraft-options/analyze_options.py analyse_option_window (enum getstatic in the tail loop, enum default resolution), analyze_jar (string-token default pass)