Bug
`using Direction;` should bring enum members (NORTH, EAST, SOUTH, WEST) into the local scope so they can be used without the `Direction.` prefix. Currently, bare member names resolve to 0 instead of their enum values.
Reproduction
// examples/13/13.3_enum_flags.jai
Direction :: enum_flags {
NORTH;
EAST;
SOUTH;
WEST;
}
using Direction;
d: Direction;
d = WEST; // d should be 4 (bit 2), but is 0
d = .WEST; // d correctly gets 4 (dot-syntax works)
Expected: `d = WEST` sets d to 4
Actual: `d = WEST` sets d to 0
Lines 11-20 in the example: all assignments via bare names show d=0. Lines 22-25 using dot syntax (`.WEST`) work correctly.
Root Cause Analysis
The `using` statement for enum types likely doesn't register the individual enum members as identifiers in the resolver's symbol table. The bare `WEST` identifier isn't found via normal lookup, so it falls through to a default value of 0.
The resolver (`resolve.zig`) needs to handle `using EnumType` by iterating the enum's members and adding each as a local binding pointing to the enum member's value.
Files
- `bootstrap/src/resolve.zig` (using statement handling)
- `bootstrap/src/bytecode_gen.zig` (using statement codegen)
Bug
`using Direction;` should bring enum members (NORTH, EAST, SOUTH, WEST) into the local scope so they can be used without the `Direction.` prefix. Currently, bare member names resolve to 0 instead of their enum values.
Reproduction
Expected: `d = WEST` sets d to 4
Actual: `d = WEST` sets d to 0
Lines 11-20 in the example: all assignments via bare names show d=0. Lines 22-25 using dot syntax (`.WEST`) work correctly.
Root Cause Analysis
The `using` statement for enum types likely doesn't register the individual enum members as identifiers in the resolver's symbol table. The bare `WEST` identifier isn't found via normal lookup, so it falls through to a default value of 0.
The resolver (`resolve.zig`) needs to handle `using EnumType` by iterating the enum's members and adding each as a local binding pointing to the enum member's value.
Files