Skip to content

feat(go): support nested field annotation type specs#3640

Merged
chaokunyang merged 7 commits intoapache:mainfrom
chaokunyang:support_nested_container_field_for_go
May 1, 2026
Merged

feat(go): support nested field annotation type specs#3640
chaokunyang merged 7 commits intoapache:mainfrom
chaokunyang:support_nested_container_field_for_go

Conversation

@chaokunyang
Copy link
Copy Markdown
Collaborator

@chaokunyang chaokunyang commented Apr 30, 2026

Why?

Go nested field annotations were still limited to shallow cases, which left generated fory tags and runtime field metadata unable to express nested container element/value overrides consistently. This PR closes that gap so nested Go field specs can carry explicit container, encoding, nullability, and reference-tracking semantics through codegen and runtime resolution.

What does this PR do?

  • Extends the Go compiler generator to emit type= hints for nested list/map field specs instead of the older ad hoc array/ref tags.
  • Adds runtime support in Go to parse and apply nested type hints, resolve declared serializers from TypeSpec, and preserve declared encoding, nullability, and ref semantics for nested containers.
  • Updates Go type compatibility checks so nested slice/array/map element shapes compare structurally during compatible reads.
  • Refreshes Go generated-code and struct-tag documentation to describe the new type=list(...), type=map(...), and _ placeholder override syntax.
  • Expands generator and xlang coverage for nested annotated containers and fixes the xlang ref-override expectation so list/map elements marked ref=false round-trip without shared references.

Related issues

#1017
#3630
#3625
#3630
#3636
#3639

AI Contribution Checklist

  • Substantial AI assistance was used in this PR: yes / no
  • If yes, I included a completed AI Contribution Checklist in this PR description and the required AI Usage Disclosure.
  • If yes, my PR description includes the required ai_review summary and screenshot evidence of the final clean AI review results from both fresh reviewers on the current PR diff or current HEAD after the latest code changes.

Does this PR introduce any user-facing change?

  • Does this PR introduce any public API change?
  • Does this PR introduce any binary protocol compatibility change?

Benchmark

@chaokunyang chaokunyang merged commit a88a8a6 into apache:main May 1, 2026
71 checks passed
chaokunyang added a commit that referenced this pull request May 2, 2026
## Why?

Python currently loses declared integer encoding aliases inside nested
containers, so schemas such as `Dict[pyfory.fixed_int32,
List[pyfory.tagged_int64]]` can fall back to runtime inference or
incompatible local assignment behavior. This breaks cross-language
schema fidelity for nested map/list/set elements, especially in
compatible mode.

## What does this PR do?

- Preserves declared Python field schema metadata for nested container
keys, values, and elements in both pure Python and Cython serializers.
- Extends primitive container fast paths to write/read fixed, varint,
tagged, signed, unsigned, bool, and float schema-owned primitive
encodings directly.
- Adds compatible-read assignment planning and validation so remote
nested integer encodings are consumed with remote metadata and assigned
only when they satisfy the local schema.
- Updates Python code generation to keep nested integer schema aliases
in generic containers instead of converting those lists to numpy array
hints.
- Adds Python unit coverage, compiler generation coverage, and
Java/Python xlang tests for signed and unsigned nested annotated
containers.
- Documents nested Python collection aliases and compatible-read
behavior in README and Python guide pages.

## Related issues

#1017 
#3630 
#3625 
#3630 
#3636
#3639 
#3640
#3642

## AI Contribution Checklist



- [ ] Substantial AI assistance was used in this PR: `yes` / `no`
- [ ] If `yes`, I included a completed [AI Contribution
Checklist](https://github.com/apache/fory/blob/main/AI_POLICY.md#9-contributor-checklist-for-ai-assisted-prs)
in this PR description and the required `AI Usage Disclosure`.
- [ ] If `yes`, my PR description includes the required `ai_review`
summary and screenshot evidence of the final clean AI review results
from both fresh reviewers on the current PR diff or current HEAD after
the latest code changes.



## Does this PR introduce any user-facing change?



- [ ] Does this PR introduce any public API change?
- [ ] Does this PR introduce any binary protocol compatibility change?

## Benchmark
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.

2 participants