Add support for nested element type

[MisLink]

Recursively find all Struct types, covering the containment of pointer types in the container.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[Copilot]

Pull Request Overview

This PR enhances the native type provider to recursively unwrap nested pointer/slice/array/map containers down to their underlying struct types, and adds a new test to verify that behavior for a slice of pointers.

• Recursively handle multiple container layers in newNativeTypes
• Add TestNativeNestedStruct to validate nested element support

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
ext/native.go	Changed unwrapping logic to recurse through nested containers
ext/native_test.go	Introduced TestNestedStruct and TestNativeNestedStruct test case

Comments suppressed due to low confidence (1)

ext/native_test.go:949

• To ensure full container support, consider adding test cases for nested maps, arrays, and multiple pointer layers, not just slices of pointers.

	var nativeTests = []struct {

[TristonianJones]

@MisLink I was able to successfully run an equivalent expression using the existing object structure without the nested type traversal. Perhaps you need to test a different case to exercise how the PR impacts users?

[MisLink]

@TristonianJones Could you please share the test cases you used? I tried with the one I added myself, but it throws an error unless I apply this modification.

=== RUN   TestNativeNestedStruct
=== RUN   TestNativeNestedStruct/[0]
    /Users/mi/projects/cel-go/ext/native_test.go:985: env.Check(test.ListVal.exists(x, x.custom_name == "name")) failed: ERROR: <input>:1:25: unexpected failed resolution of 'ext.TestNestedType'
         | test.ListVal.exists(x, x.custom_name == "name")
         | ........................^
--- FAIL: TestNativeNestedStruct (0.00s)
    --- FAIL: TestNativeNestedStruct/[0] (0.00s)

[TristonianJones]

@MisLink, my apologies, that wasn't a very good reply on my part. I added the following case to the TestNativeTypes function in ext/native_test.go:

{
	expr: `t.ListVal.exists(x, x.custom_name == "name")`,
	in: map[string]any{
		"t": TestAllTypes{ListVal: []*TestNestedType{{NestedCustomName: "name"}}},
	},
	out:     true,
	envOpts: []any{cel.Variable("t", cel.ObjectType("ext.TestAllTypes")), ParseStructTags(true)},
},

[MisLink]

@TristonianJones The TestAllTypes struct includes a field of type *TestNestedType at the beginning. The previous logic was able to handle this case correctly, which ensured that the TestNestedType type was included during the parsing phase. I didn’t trace the execution phase in detail, but in practice, both this type and its nested types could be handled properly at runtime.

However, if a struct contains only deeply nested types (as is the case in the new struct I added for testing), the parser is unable to detect those types, which leads to runtime errors during execution. This is exactly why I added that specific struct for testing purposes (apologies—I should have mentioned that earlier!)

[TristonianJones]

@MisLink ah, I see, thanks for the explanation. I didn't catch that the first time.