This CL documents that StructOf currently does not generate wrapper
methods for embedded fields.

Updates golang#15924

Change-Id: I932011b1491d68767709559f515f699c04ce70d4
Reviewed-on: https://go-review.googlesource.com/23681
Reviewed-by: David Crawshaw <crawshaw@golang.org>

When StructOf is used with an anonymous field that has methods, and
that anonymous field is not the first field, the methods we generate
are incorrect because they do not offset to the field as required.
If we encounter that case, panic rather than doing the wrong thing.

Fixes #20824
Updates #15924

Change-Id: I3b0901ddbc6d58af5f7e84660b5e3085a431035d
Reviewed-on: https://go-review.googlesource.com/47035
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The current implementation does not generate wrappers for methods of
embedded non-interface types. We can only skip the wrapper if
kindDirectIface of the generated struct type matches kindDirectIface
of the embedded type. Panic if that is not the case.

It would be better to actually generate wrappers, but that can be done
later.

Updates #15924
Fixes #24782

Change-Id: I01f5c76d9a07f44e1b04861bfe9f9916a04e65ca
Reviewed-on: https://go-review.googlesource.com/121316
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

When generating an interface wrapper, lookup existing wrappers by method
to get the one with the biggest set of methods implemented by interpreter.

A string method is also added to wrappers, in order to provide a string
representation of the interpreter value rather than the wrapper itself
(at least for %s and %v verbs).

This allows the runtime to pickup an interpreter method automatically
even if the conversion to the interface is not specified in the script. As
in Go spec, it is enough for the type to implement the required methods.

A current limitation is that only single wrappers can be instantiated,
not allowing to compose interfaces.

This limitation can be removed when the Go reflect issue
golang/go#15924 is fixed.

Fixes #435.

* fix: make interpreter methods discoverable by runtime

When generating an interface wrapper, lookup existing wrappers by method
to get the one with the biggest set of methods implemented by interpreter.

A string method is also added to wrappers, in order to provide a string
representation of the interpreter value rather than the wrapper itself
(at least for %s and %v verbs).

This allows the runtime to pickup an interpreter method automatically
even if the conversion to the interface is not specified in the script. As
in Go spec, it is enough for the type to implement the required methods.

A current limitation is that only single wrappers can be instantiated,
not allowing to compose interfaces.

This limitation can be removed when the Go reflect issue
golang/go#15924 is fixed.

Fixes #435.

* test: add a simpler test

This change implements a workaround to better support composed
interfaces in yaegi and let the interpreter to define objects which
impletment multiple interfaces at once.

We use the existing MapTypes to store what possible composed interfaces
wrapper could be used for some interfaces. When generating an interface
wrapper, the wrapper with the highest number of implemented methods is
chosen.

This is still an imperfect solution but it improves the accuracy of
interpreter in some critical cases.

This workaround could be removed in future if/when golang/go#15924
is resolved.

Fixes traefik#1425.

This change implements a workaround to better support composed
interfaces in yaegi and let the interpreter define objects which
implement multiple interfaces at once.

We use the existing MapTypes to store what possible composed interface
wrapper could be used for some interfaces. When generating an interface
wrapper, the wrapper with the highest number of implemented methods is
chosen.

This is still an imperfect solution but it improves the accuracy of
interpreter in some critical cases.

This workaround could be removed in future if/when golang/go#15924
is resolved.

Fixes #1425.

Only structures with one embedded field can be marked anonymous,
due to golang/go#15924. Also check only that the method is defined,
do not verify its complete signature, as the receiver may or not
be defined in the arguments of the method.

Fixes traefik#1537.

Only structures with one embedded field can be marked anonymous, due to golang/go#15924. Also check only that the method is defined, do not verify its complete signature, as the receiver may or not be defined in the arguments of the method.

Fixes #1537.

…o present all the pieces at the same time.

This PR creates a system for supporting YAML files using different `api_version`s from a single binary. This is implemented by having a separate set of structs for each `(kind,api_version)` pair. Each api_version can change the semantics or existence of YAML fields. The structs are stored in `templates/model/$KIND/$APIVERSION`.

Instructions for adding a new `api_version` are in `templates/model/README.md`, that might be a good starting point for review.

Old versions are automatically converted to new versions before being used: old structs define an Upgrade() method that define how to upgrade them.

There's a registry of `api_version`s in decode.go that defines which versions exist and which structs are associated with each.

To demonstrate that this all actually works, this PR creates a new API version `v1beta1`. The only change in this new version is adding the optional `if` field for each step in spec.yaml (#220).

Alternatives considered to try to avoid this huge copy-pasting of structs:
- Struct embedding to reduce copy-pasta: this would expose a more complicated API to the rest of the code that has to use the structs. It makes creating a new version more painful. It also triggers golang/go#15924 since we use `reflect.StructOf`.
- Use github.com/mitchellh/mapstructure` to avoid so much double-parsing: we'd lose YAML position information, and our users really appreciate getting line numbers on their error messages.
- Use `switch(apiVersion)` within a single struct instead of copy-pasting structs: high risk of accidentally changing the behavior of old API versions and generally creating fragile code.

I've marked files that are mostly copy-pasted so you can mostly skip reviewing them

Apologies for the large PR, but I think in this case it's important to
present all the pieces at the same time.

This PR creates a system for supporting YAML files using different
`api_version`s from a single binary. This is implemented by having a
separate set of structs for each `(kind,api_version)` pair. Each
api_version can change the semantics or existence of YAML fields. The
structs are stored in `templates/model/$KIND/$APIVERSION`.

Instructions for adding a new `api_version` are in
`templates/model/README.md`, that might be a good starting point for
review.

Old versions are automatically converted to new versions before being
used: old structs define an Upgrade() method that define how to upgrade
them.

There's a registry of `api_version`s in decode.go that defines which
versions exist and which structs are associated with each.

To demonstrate that this all actually works, this PR creates a new API
version `v1beta1`. The only change in this new version is adding the
optional `if` field for each step in spec.yaml (#220).

Alternatives considered to try to avoid this huge copy-pasting of
structs:
- Struct embedding to reduce copy-pasta: this would expose a more
complicated API to the rest of the code that has to use the structs. It
makes creating a new version more painful. It also triggers
golang/go#15924 since we use
`reflect.StructOf`.
- Use http://github.com/mitchellh/mapstructure to avoid so much
double-parsing: we'd lose YAML position information, and our users
really appreciate getting line numbers on their error messages.
- Use `switch(apiVersion)` within a single struct instead of
copy-pasting structs: high risk of accidentally changing the behavior of
old API versions and generally creating fragile code.
 
I've marked files that are mostly copy-pasted so you can mostly skip
reviewing them