Resolve embedded-interface fields in get() builtin (match member access)

[mahirhir]

The builtin get(obj, "field") doesn't resolve fields on the concrete type behind an embedded interface, while member access (...).field does. So for a value whose static type is unknown at compile time, (cond ? x : y).Value returns the value but get((cond ? x : y), "Value") returns nil — inconsistent access for the same field.

PR #952 added fetchFromEmbeddedInterfaces to runtime.Fetch but left its sibling get() behind; #935 had previously kept the two in lockstep. The fix mirrors #952's logic into get().

Verified both ways with go test: old returns nil, fixed returns the value; a missing field still returns nil (no panic), zero regression across the suite.

[sanmaxdev]

The shared lookup keeps get() consistent with member access for fields behind embedded interfaces, while preserving nil for missing fields. The focused package tests and full suite pass.

Checked with:

• go test ./vm/runtime ./builtin ./test/issues/952
• go test ./...
• git diff --check upstream/master...HEAD

[mahirhir]

Thanks for looking at this. I would rather not lean on "the suite passes" from either of us, so here is what can be checked without taking anyone's word, plus the one design question this PR actually raises.

State on master today:

$ grep -n 'etchFromEmbeddedInterfaces' vm/runtime/runtime.go
92:      if result, found := fetchFromEmbeddedInterfaces(v, fieldName); found {
163: func fetchFromEmbeddedInterfaces(v reflect.Value, fieldName string) (any, bool) {
183:         if result, found := fetchFromEmbeddedInterfaces(fv, fieldName); found {

$ grep -c 'etchFromEmbeddedInterfaces' builtin/lib.go
0

runtime.Fetch resolves a field on the concrete type behind an embedded interface. The builtin get() has no reference to that lookup at all. So the same field access returns a value through member access and nil through get().

The part that makes this a bug rather than a design choice is in builtin/lib.go itself, at the end of get():

619    // Main difference from runtime.Fetch
620    // is that we return `nil` instead of panic.
621    return nil, nil

The file states the invariant, and the file breaks it. The two are supposed to agree on which fields exist and disagree only on what happens when one does not.

The reason they drifted is mechanical rather than anyone's oversight: the traversal is unexported, and get() lives in a different package, so it could not call the shared lookup even if someone wanted to. The functional part of this PR is one call; the rest is exporting the helper so that call is possible.

That export is the real review question, and it is yours to decide rather than mine:

• export FetchFromEmbeddedInterfaces as this PR does, which adds one symbol to the public surface of vm/runtime
• duplicate the traversal inside builtin, which keeps the surface unchanged and guarantees the next drift
• move it to an internal package that both import, which costs a file and keeps it private

I took the first because it is the smallest diff. If you prefer the third I am happy to redo it that way.

Two things I am not claiming:

$ gh pr checks 977 --repo expr-lang/expr
no checks reported on the 'fix/get-embedded-interface-field' branch

There is no CI evidence on this branch, and I have no Go toolchain on the machine I am on right now, so I have not re-run the suite against current master. The added test in test/issues/952 is the thing to run. It asserts the same field resolves through both paths and includes a genuinely missing field that must still come back nil, so the change cannot pass by resolving everything it is handed.