Treat Option<T> as Vec<T>

[Danil-Grigorev]

Naive implementation of the Option handling, as a regular slice of length either 0 or 1. This implementation allows to pass more complex structures with optional values, where golang treats such as a []T type objects.

[Copilot]

Pull Request Overview

This PR implements support for Option<T> types by treating them as slices of length 0 or 1, similar to how Vec<T> is handled. This allows passing optional values to Go code where they're represented as []T types.

• Adds Option<T> pattern matching alongside Vec<T> in type processing
• Implements ToRef and FromRef traits for Option<T> using slice-based conversion
• Updates macro and common type handling to recognize Option as a list type

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
rust2go-macro/src/lib.rs	Extends pattern matching to include "Option" alongside "Vec" for ListRef generation
rust2go-convert/src/convert.rs	Implements ToRef and FromRef traits for Option using slice-based conversion logic
rust2go-common/src/common.rs	Updates type processing to treat Option as a list type in two locations

[lirenjie95]

Hi @Danil-Grigorev , thank you for your kind contribution. Can you please resolve the lint issue and add related tests as well?

[lirenjie95]

LGTM

[ihciah]

One small regression: DataView::new intentionally sets ptr = null when len == 0, but Vec::to_ref and Option::to_ref now overwrite data.0.ptr unconditionally for MemType::Complex, which re‑introduces a non‑null (dangling) pointer for empty lists and changes nil/empty semantics on the Go side. Suggest a tiny follow‑up patch to only overwrite when len > 0. I’m OK to merge as‑is and fix right after.