[Yamashou]

Background

SourceGenerator.NewResponseField was a 198-line type switch (cognitive complexity 38) that handled *ast.Field, *ast.FragmentSpread, and *ast.InlineFragment in one body. Inside the inline fragment case, the path with a fragment spread and the path without one repeated the same struct registration, InlineFragmentAlwaysPointers handling, and graphql:"... on X" tag construction, so the two could drift independently. expandFragmentFields had no callers.

Changes

Pure refactor; the test suite is untouched.

• NewResponseField dispatches to newFieldResponseField, newFragmentSpreadResponseField, and newInlineFragmentResponseField.
• The field path is split further into fieldBaseType (scalar, fragment, or generated struct) and fieldTags (json and graphql tags, including the omitempty and omitzero options).
• The inline fragment path computes its field list once (own fields, then the fields of the spreads, exactly as before) and then runs a single tail; inlineFragmentType and inlineFragmentTags hold the shared pieces. The special case that reuses a lone fragment spread's type is kept as is.
• expandFragmentFields is deleted.
• The duplicate-field merge from fix(clientgenv2): merge duplicate fields between an inline fragment and its spread #358 is ported into a new mergeInlineFragmentFields helper; the inline_fragment_duplicate_fields golden case verifies it.

The order of side effects on r.StructSources and the point at which SortByName runs are preserved, which is what the generated struct field order depends on.

Testing

$ go test -race ./clientgenv2/ ./generator/
ok  	github.com/gqlgo/gqlgenc/clientgenv2
ok  	github.com/gqlgo/gqlgenc/generator
$ golangci-lint run ./...   # v2.13.2
0 issues.

The golden tests in generator pass unchanged, and regenerating the seven local-schema examples under example/ produces no diff. The workflow was also run locally with act and the Build job passed.