Skip to content

fix(gen): literal go_value in to_where generates &true for pointer type systems - #780

Open
theluckystrike wants to merge 1 commit into
stephenafamo:mainfrom
theluckystrike:fix/553-literal-go-value-pointer
Open

theluckystrike wants to merge 1 commit into
stephenafamo:mainfrom
theluckystrike:fix/553-literal-go-value-pointer

Conversation

@theluckystrike

Copy link
Copy Markdown

With type_system set to database/sql or github.com/aarondl/opt/null, a relationship whose to_where uses a literal go_value still generates code that does not compile. #553 reported it as IsPrimaryVersion = &true in the generated setters, and as &1 when the value is unquoted. #556 fixed the other errors in that issue, but this one is still on main.

The relationship templates pass the go_value string to Types.ToOptional. For the two pointer type systems, the non null branch of optionalTypePointers built func () *T { return &SRC }(), and Go can't take the address of a constant. The nullable branch in the same function already assigns to a local first, so this change uses that form for the non null branch too. A column value passed as SRC behaves the same as before.

The new test in gen/drivers/types_test.go calls ToOptional with true and 1 under both type systems. It fails on main with return &true and return &1 and passes with the change. go test ./gen/drivers/ and go vet ./gen/drivers/ pass, and gofmt is clean. I also added a line to the changelog.

Michael

The non-null branch of optionalTypePointers built &SRC, which does not
compile when SRC is a literal from a relationship to_where go_value
(&true, &1). Assign to a local first, as the nullable branch does.

Refs stephenafamo#553
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