forst-lang / forst / 16034193780 / 1
40%
main: 41%

LAST BUILD BRANCH: generator-ts
DEFAULT BRANCH: main
Ran
Files 108
Run time 4s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 37.619% (+0.3%) from 37.308%
16034193780.1

Pull #17

github

haveyaseen 
fix(typechecker): implement proper nested field path traversal for shape guards

The typechecker was failing to handle nested field access with dot notation (e.g., op.input.name) in shape guards and other contexts. The root cause was that field lookup functions were not properly handling multi-segment field names and were incorrectly recursing into nested shapes for single-segment lookups.

This commit adds new path-aware field lookup functions (lookupFieldPath, lookupFieldPathOnShape, lookupFieldPathOnMergedFields) that properly handle dot notation by splitting field names and recursively traversing the path. The existing field lookup functions have been updated to use these new functions where appropriate, ensuring consistent behavior across type definitions, assertions, and variable lookups.

The fix specifically addresses the bug where looking up a field like "input" in a shape containing {input: {name: String}} would incorrectly try to find "input" in the nested shape instead of returning the shape type. For multi-segment paths like "input.name", the new logic properly splits the path and recurses into the nested shape to find "name".

All typechecker tests now pass, confirming that nested field access works correctly for shape guards and other use cases. The shape guard feature can now properly handle expressions like op.input.name where op is a shape with nested fields.
Pull Request #17: feat: Shape guards

3081 of 8190 relevant lines covered (37.62%)

6.35 hits per line

Source Files on job 16034193780.1