[bug] golang client: calling prompt inputs `context` breaks compilation

[invakid404]

Product

BAML

Describe the bug

Basically the title. If you have a prompt that takes a parameter with the name context (or, for that matter, any package name in scope), compilation will fail with an error along the lines of

baml_client/functions_stream.go:1062:26: context.Background undefined (type *string has no field or method Background)

This occurs because the parameter name shadows the package name.

Reproduction Steps

1. Add a prompt that takes a parameter with name context of any arbitrary type
2. Try to generate Go client
3. Try to build project

BAML Version

0.204.0

Language/Framework

Go

LLM Provider

None

LLM Model

No response

Operating System

None

Browser

None

Code Editor

None

[linear[bot]]

BAML-478 [bug] golang client: calling prompt inputs `context` breaks compilation

[aaronvg]

great catch -- we can add a linter error for that name if you are using a Go generator

[imalsogreg]

What would you recommend here? Should we throw an error during codegen when any popular package is used as a parameter name? Is context a popular package?

It would be nice to analyze the user's Go client code to pull their imported package names and forbid them from use in BAML parameters, but at the time we generate Go code from BAML, we don't have access to the Go client code. It's also a normal workflow to generate your BAML code early, and then modify your Go code later - adding a package whose name would be shadowed by a parameter would break at a time when our compiler doesn't have the opportunity to run and catch the issue.

[invakid404]

What would you recommend here? Should we throw an error during codegen when any popular package is used as a parameter name? Is context a popular package?

It would be nice to analyze the user's Go client code to pull their imported package names and forbid them from use in BAML parameters, but at the time we generate Go code from BAML, we don't have access to the Go client code. It's also a normal workflow to generate your BAML code early, and then modify your Go code later - adding a package whose name would be shadowed by a parameter would break at a time when our compiler doesn't have the opportunity to run and catch the issue.

My take would be to just alias the imports in generated code to names that are unlikely to collide for any practical purposes. In other words, instead of importing context directly, import it as, e.g., pkg__context. It's not particularly pretty, but it's generated code, I personally wouldn't expect it to be.