Support manually-created and generated conversion functions

[wojtek-t]

Part of #6800

This was mentioned in #7556 (comment)
Motivated by #7814, where a lot of unnecessary boilerplate had to be written.

cc @smarterclayton @lavalamp @fgrzadkowski

[smarterclayton]

Test case that proves a generated conversion is overriden?

[wojtek-t]

Test case that proves a generated conversion is overriden?

Good point - test added.
PTAL

[mbforbes]

Without digging into the code, I'm assuming the motivation sprung from #7343 (of which #7814 is the un-revert), and so @erictune and @pmorie are good candidates for review. Assigning to @pmorie for now; please feel free to shuffle around.

[smarterclayton]

I'm going to grab this

[smarterclayton]

LGTM

[wojtek-t]

Thanks @smarterclayton !

I think that it would be good for @lavalamp to also take a look into it.

[lavalamp]

nit: missing r

[wojtek-t]

Will fix that in a subsequenct PR

[lavalamp]

Thanks for fixing this!

[thockin]

Is there somewhere I can read an overview of this changeset? I was very familiar with the state before autogeneration, and I want to understand what this is buying us and how I interact with it for manual conversion functions...

[lavalamp]

@thockin see the list of PRs on the end of #6800. This is an... expedient... way to cut the reflection out of the critical path so we can meet our performance goals. I think we can probably come up with a more user friendly mechanism but that's going to have to be post 1.0.

[lavalamp]

The overview is that we're autogenerating conversion functions--while allowing manual override--instead of using the conversion logic.

[thockin]

As an occasional author of manual conversion functions, what has changed
for me?

On Wed, May 6, 2015 at 3:49 PM, Daniel Smith notifications@github.com
wrote:

The overview is that we're autogenerating conversion functions--while
allowing manual override--instead of using the conversion logic.

—
Reply to this email directly or view it on GitHub
#7832 (comment)
.

[lavalamp]

@wojtek-t can confirm (and we'll want to write this up really soon), but I believe the steps will be:

1. Move the auto-generated function from the list in newer.Scheme.AddGeneratedConversionFuncs(...) to the list in newer.Scheme.AddConversionFuncs(...) (soon: move the body of the function out of the file containing the auto-generated functions)
2. Edit it.
3. Regenerate the conversion functions.

[smarterclayton]

I did this today for the etcd portal ip allocator and was easy (not quite fully documented yet).

On May 6, 2015, at 7:44 PM, Daniel Smith notifications@github.com wrote:

@wojtek-t can confirm (and we'll want to write this up really soon), but I believe the steps will be:

Move the auto-generated function from the list in newer.Scheme.AddGeneratedConversionFuncs(...) to the list in newer.Scheme.AddConversionFuncs(...) (soon: move the body of the function out of the file containing the auto-generated functions)
Edit it.
Regenerate the conversion functions.
—
Reply to this email directly or view it on GitHub.

[wojtek-t]

Yes - this is exactly what @lavalamp wrote above. There is one more significant PR #7556 that will come (it's already under review) and as soon as it's in I will update documentation.
I already kind of updated it at some point (docs/devel/api_changes.md), but I agree it's again outdated :)