GitLab

This one was particularly aimed at making sure I hit all the hardest
situations as trying to write the generators for NodeBuilders.

It certainly did so!  I found enough conceptual/design work to do that
I'm actually going to park this here for a while, probably land this
branch back to master before it gets any longer, and then approach
things from some other angles for a while.

In particular: We're going to need several *different* NodeBuilders
for schema-typed nodes.  The astute reader probably already noticed
this, as it's implied by the `typed.Node{}.Representation() Node`
method: that adds a second Node instance, and that means a second
NodeBuilder.  What's a little more fun yet is there might be more than
two: for example, if we want the serial mode to support variation in
field order for structs, that's another branch we need to account for
somewhere... and, ordered vs unordered modes might need different
structures of memory to do their job efficiently, so that means wholly
different implementations of the interface.  Whee.

So.  I'm thinking I might switch tack to knocking around in the
(non-codegen) typed Node package for a while and making sure nothing
looks wildly amiss over there while exploring these same features
Then, when coming back here: looks like we're due for that breakdown
of `EmitNodeBuilder{Detail...}` methods: and perhaps that's
actually going to belong on a new type rather than glommed on flatly
to `typeGenerator`... since there may be a n:1 relationship there!

A bit fun; wish there was a way to compress that block of ifdefs about
optional vs nullable stuff, but so far nothing clearer has emerged.

Added ErrIteratorOverread while at it.  Should refactoring other node
types to use it too, I suppose.  But perhaps we'll just accumlate those
todos for a while, since there's already one other error refactor with
a chain of blocks in front of it.

The comment in the ipld.Node type about IsUndefined has been there
quite a while; today we're finally using it.

With this set of changes, the generated code for structs now compiles
successfully again: the Undef and Null thunks are both used there.

The latter isn't used yet; that's not the main goal of this branch (and
I think I'd rather do the refactor to use ipld.ErrNotExists after
moving the PathSegment types from the selector package into the root...
which in turn I'm not going to do while some of the other current work
on Selectors is in progress in other branches.  So!  Latur.); I just
wanted it around for documentation and clarity of intent.

This also adds a couple of other dummy references to the 'typed'
package.  I know keeping a set of packages-used-in-this-file is a
common step in the development of codegen systems targetting golang,
but I'm going to try to avoid it until the need is really forced.

Generates the struct itself (including the variations of pointers
and/or extra fields necessary),

There are several major TODOs outstanding; and the generated code
doesn't *quite* compile due to several missing references, namely:

- ipld.ErrNoSuchField
- ipld.Nil
- ipld.Undefined

The other issues remaining:

- The reason ErrNoSuchField is missing is because it needs to be
decided where an error like that should go.  Is it meaningfully
distinct from a general "key absent" error, like a map can return?
If it is indeed a distinct thing, does it go in the schema package,
or will that just make things annoying until the end of time since
every occurence-site-sibling error is in the ipld main package?

- We need to think about typed nil / typed undefined.  I suspect they
are an idea to be avoided (but doing so means using the NodeBuilder()
method on the nil or undefined values from a struct will *not* "DTRT",
which may be problematic; this can in turn be avoided by "knowing"
you're working on a typed node, but, erm.  It turns into a question of
which of these things is less annoying).

- We'll need to backtrack up to the main ipld.Node interface and add
that 'IsUndefined() bool' method now!  (Or, take a radical approach of
using a magic const for that.  But... no, that doesn't sound fun.)

- Haven't even touched the NodeBuilder yet.  (And the typeGenerator
interface needs to have those bits broken down, as well, so that we can
do good stuff with error path codesharing as with funcs for Node.)

- Haven't filled in MapIterator.  But that's probably just easy chug.

Lots to do, in short.  I just need a checkpoint.

Note how we've had this on the clipboard for a while already, heh --
the info_test.go file and TestUnderstandingStructMemoryLayout have been
aimed at this; notice how any extra bool fields are generated at the
bottom of the emitted struct.  Many yaks have been shaved in the
meanwhile, and yet look at how many we have to go.  Isn't this fun?
Signed-off-by: Eric Myhre <hash@exultant.us>

Signed-off-by: Eric Myhre <hash@exultant.us>

Fields in these structs are now named.  Embedding is reserved for
things that are very explicitly supposed to carry their methods along.

At some earlier point, I embedded the Type field in some of the
generate structs because it saved me a few keystrokes in refactoring
template strings.  This was not important.

Today I learned: if you have embeddings which cause a name to be
shadowed -- as the generateKindedRejections_String.Type field
could shadow the generateKindString.Type field, for example -- if those
resolve "neutrally" (I don't know if there's a better technical term
for this), then... in that case, the templating system will be like
"yeah, fine, whatev", and it works.  If you give one of those two
fields a *separate type*, the templating system will now reject it as
if no field of that name can be found.

I encountered this while working on the generator for structs (which I
*swear* I will commit any second now, when I stop finding prerequisite
yaks to shave -- there have been many) and trying to use a more
specialized TypeStruct instead of the Type interface.  Whee.

I get the logic of this.  The error message could be better.

Anyway: even though it technically didn't affect generateString (yet),
making the change here for consistency with what's to come
(including specializing the field even though there's currently no
actual need for it).

This isn't a net negative size diff yet, but it certainly will have
that effect momentarily when we add a generator for another kind.
More importantly, it reduces the set of functions in the real
generator file to *just* the relevant ones.

We'll almost certainly extend this to cover the NodeBuilder half of
things as well, later; I just haven't gotten there yet.

The Go Playground is also often a perfectly good home for these things;
I've also used "_rsrch" directories in other projects, especially if
benchmarks of nontrivial runtime and setup get involved; but this
will suffice for this quick factcheck here and now.

I'm solving the decorum problem by making "temporary" builder methods for the
schema.Type values as necessary.  This will allow the gengo package to use
them freely for now.  When we're done with all this, I want to restrict building
of schema.Type values to a single method in the schema package which takes the
"ast" types -- the ones we're hoping to codegen (!) -- and do lots of checks
and cross-linking; the temporary builder methods will do *none*, and *of course*
they can't take the "ast" types yet since they don't exist yet.

Boom, cycle broken.

Also: fix generateStringKind from taking a TypeName redundantly.

This was triggered by an experiment about generating even more 'minima'
like this, such as a batch of helper structs which would hold all the
common "no, you can't do operation X on something of kind Y" methods.
However, that diff isn't here; and is probably going to turn out to be
abandoned, because after trying it out, I found that it was pretty hard
to do good error messages (which... was pretty central to the point)
with that approach.  So, more on those attempts later.
Signed-off-by: Eric Myhre <hash@exultant.us>

Generating these tiny thunks seems much cheaper than expanding the
exported surface of our most essential package.

Exercise unmarshal against our generated "Strang" type.  Works!

(Note: this will fail if you *haven't* run the codegen yet; but it's in
an underscore-prefixed package, so it won't run unless you dive in here
intentionally.  Overall, this continues to be early-days hijinx, and
does not represent a good long-term testing strategy.)

The generated package now compiles completely happily.  Neat.

Signed-off-by: Eric Myhre <hash@exultant.us>

typed.Node.Representation(), which returns another Node, should address
most of the infelicies we've found so far in trying to plan nice code
that works over the schema layer.

Also added in this comment: ipld.ReprKindSet, primarily for use in the
ErrWrongKind error.  It comes up often enough we might as well formalize
the thing.

What was left in this last file was mostly docs; and while some of
that text might be good, we can either write it fresh or come
dredge it out of history when we re-build something like this package.

Fix the few remaining references to declaration by switching them
to refer to the reified equivalents in the schema package (which is
what all those references should have been anyway).
Signed-off-by: Eric Myhre <hash@exultant.us>

Dropped older PoC/draft codegen code at the same time; that
was a stale idea and the draft that followed it is already
clearly shaping up better.
Signed-off-by: Eric Myhre <hash@exultant.us>