Forbid unmarshaling non-scalars into a TextUnmarshaler

[WGH-]

This is a breaking change.

Previously an attempt to unmarshal a YAML mapping into a struct implementing encoding.TextUnmarshaler would succeed, but likely do the wrong thing.

Consider this example:

type Foo struct {
    IP netip.Addr `yaml:"ip"`
}

netip.Addr is a struct type implementing TextUnmarshaler, but containing no exported fields. So unmarshaling {"ip": "127.0.0.1"} would use TextUnmarshaler (as expected), but {"ip": {"whatever": 123}} would silently do nothing.

With this commit, it will now result in a type error.

encoding/json/v2 documentation states:

If the value type implements encoding.TextUnmarshaler, then the input
is decoded as a JSON string and the UnmarshalText method is called with
the decoded string value. This fails with a SemanticError if the input
is not a JSON string.

encoding/json documentation is somewhat ambiguous on this, but it also behaves the same way (https://go.dev/play/p/z9okIXkUzvQ).

[ingydotnet]

This PR seems good to me but I'd like to see more discussion.
It's technically breaking but do people think it will actually break anything?
Is there any way to search for public code that it would possibly break?

[WGH-]

This PR seems good to me but I'd like to see more discussion. It's technically breaking but do people think it will actually break anything? Is there any way to search for public code that it would possibly break?

I've been thinking about this for a bit, but I have no good ideas how to do so.

We could port this patch to v3, and run tests across popular repositories with go mod replaced dependency, but I doubt that YAML unmarshalling is covered by unit tests well.

Going the conservative way, we could add a deprecation warning, and an option to opt in immediately.

[SVilgelm]

I would suggest to do same as json/v2 - unmarshal to a string first, then pass it to TextUnmarshaler

[SVilgelm]

@copilot create an issue based on this PR

[WGH-]

I would suggest to do same as json/v2 - unmarshal to a string first, then pass it to TextUnmarshaler

This PR already does the same thing as json/v2.

[WGH-]

The only difference perhaps is that handling of TextUnmarshaler is somewhat less explicit. encoding/json/v2 switches on target type, whereas go-yaml switches on YAML value type first, and only then methods (*decoder).mapping, (*decoder).sequence, etc. check the target type.

...now that I spelled this out, I think odd cases like unmarshaling a YAML sequence into a slice type implementing TextUnmarshaler might be handled differently to encoding/json/v2. Thanks for pointing that out, I'll check it again.

[WGH-]

I've updated this by making the check more explicit.