Windows fix - #16
Conversation
… parsing When a Gin handler is registered as a method value (e.g. s.login), Go generates a wrapper whose runtime source file is <autogenerated>. This prevented parseHandlerComments from reading method annotations. - Strip -fm suffix from method-value wrapper names - Properly extract method name from receiver-qualified names - Fall back to project-wide source scan when filePath is <autogenerated>
Add annotate-gen tool that scans Go source files for handler annotations (@summary, @description, @tags, @operationid, @PARAM, @return) and generates annotations_gen.go with hardcoded HandlerDoc maps. This makes annotations work in production where source files are not available. - Extract ParseAnnotationLines from parseHandlerComments for reuse - Add generatedAnnotations map + SetGeneratedAnnotations - ConvertRoutesToTools checks generated map first, falls back to source parsing only when missing - Remove findFunctionFile (obsoleted by the generated map approach) - New cmd/annotate-gen: go run .../cmd/annotate-gen ./...
…truct Add @Body annotation support so users no longer need to call RegisterSchema for request body types. - HandlerDoc gains BodyTypeName field, parsed from @Body comment line - annotate-gen now scans all struct definitions in the package - Structs with //ignore-mcp comment are skipped - Duplicate struct names trigger a warning - Generated annotations_gen.go includes SetGeneratedStructs with pre-computed FieldMeta (JSON name, type, description, required) - Runtime generateInputSchema resolves @Body types from the generated struct map, falling back only when registeredSchemas already covers the route - SetGeneratedAnnotations / SetGeneratedStructs use merge semantics so multiple packages can each contribute without overwriting
ckanthony
left a comment
There was a problem hiding this comment.
Thanks for this — I test-merged it onto main locally: clean merge, all 180 tests pass, vet/gofmt clean. The code itself works.
Before merging I need a few things:
-
Retitle the PR. "Windows fix" doesn't describe this — it's a compile-time annotation generator plus @Body support. Something like "feat: add annotate-gen code generator and @Body annotation" would be accurate.
-
README documentation. annotate-gen is a user-facing tool (go run github.com/ckanthony/gin-mcp/cmd/annotate-gen
) and @Body is a new annotation — both need a README section covering: what problem codegen solves (runtime reflection via FileLine being unreliable), how to run it, where the generated file lands, and the @Body syntax. -
Generated-file guidance. Should annotations_gen.go be committed or gitignored + regenerated in CI/go:generate? Please document the intended workflow.
Minor (non-blocking): consider a go:generate example in the docs once you add them.
I'm not sure whether these always work reliably:
So I added a code generator that scans the source code before build time and generates annotation metadata and struct information.
I also added an
@bodyannotation to make it easier to populate request body parameters.example:
That‘s enough. After startup, the body parameters and the information from the annotations can be displayed correctly.