Skip to content

[FEAT] Parse Generic#2

Merged
bbengfort merged 1 commit intomainfrom
parse-generic
Apr 3, 2026
Merged

[FEAT] Parse Generic#2
bbengfort merged 1 commit intomainfrom
parse-generic

Conversation

@bbengfort
Copy link
Copy Markdown
Contributor

@bbengfort bbengfort commented Apr 3, 2026

Scope of changes

Adds generics based parsing for multiple types.

Estimated PR Size:

  • Tiny
  • Small
  • Medium
  • Large
  • Huge

Acceptance criteria

This PR will be merged without review.

Author checklist

  • I have manually tested the change and/or added automation in the form of unit tests or integration tests
  • I have updated the dependencies list
  • I have added new test fixtures as needed to support added tests
  • I have added or updated the documentation
  • I have run go generate to update generated code

Note

Medium Risk
Introduces new generic parsing logic that accepts many input types and panics on invalid name schemas; while unit-tested, it could affect downstream behavior if relied on for input validation or error handling.

Overview
Adds a generic ParseFactory that builds enum parsers for ~uint8 enums, supporting case/whitespace-insensitive string parsing (via provided []string or [][]string name tables) and numeric conversions with bounds checking.

Introduces a central Enum interface bundling common enum behaviors (Stringer, JSON marshal/unmarshal, SQL scan/value), expands README with getting-started/theory docs, and adds comprehensive tests (plus testify) covering valid/invalid parse inputs and invalid name schemas.

Written by Cursor Bugbot for commit 1156df2. Configure here.

Copy link
Copy Markdown

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 2 potential issues.

Fix All in Cursor

Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

}
return T(v), nil
case int8:
if v < 0 || v >= int8(len(normalizedNames)) {
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Integer overflow in int8 bounds check

Medium Severity

The cast int8(len(normalizedNames)) silently overflows when the names slice has 128 or more entries. Since T is ~uint8 and can represent up to 256 enum values, this is a reachable scenario. When overflowed (e.g., 130 names → int8(130) = −126), the comparison v >= -126 becomes true for all non-negative int8 values, incorrectly rejecting every valid input.

Fix in Cursor Fix in Web

if v < 0 || v >= float64(len(normalizedNames)) {
return unknown, fmt.Errorf("invalid %T value: %f", unknown, v)
}
return T(v), nil
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Float values silently truncated to enum integers

Low Severity

Non-integer float values (e.g., float64(2.7)) pass the bounds check and are silently truncated by T(v), mapping them to an unrelated enum value. There's no check that the float is actually a whole number, so a value like 2.9 is quietly accepted as enum value 2.

Fix in Cursor Fix in Web

@bbengfort bbengfort merged commit 1cb67f6 into main Apr 3, 2026
4 checks passed
@bbengfort bbengfort deleted the parse-generic branch April 3, 2026 21:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant