GitLab

(This type isn't really "embedded" in the others directly, so those
docs were somewhat confusing.)

More code sections.  Parts of this paragraph were being rendered as
italics.

fix(cidlink): check for byte buffer

Use interface rather than concrete type for byte buffer checker

CI: test with Go 1.14 and 1.15, drop 1.12

The common policy is to support the two latest versions of Go. Do that,
since our previous state meant a version of Go that's pretty old and
unused at this point.

Also simplify the travis yaml. First, GO111MODULE=on hasn't been needed
for a while, since it defaults to "on" if go.mod exists. We also don't
need redundant steps like "go mod download" or "go build"; "go test"
already does all of that for us. The "go fmt" check is also pointless,
as it only formats the code without actually complaining if it isn't
properly formatted.

Finally, update the Go version in go.mod to 1.14, since that's the
oldest version we test against and support at this point. This version
sets, for example, what language features we can use.

And, while at it, "go mod tidy".

linking/cid: check a previously unused error

all: make 'go test ./...' pass on Go 1.15

...to actually run tests.

Ow.

(You can tell I don't really look to travis for meaningful results.)

I am embarrassed to say I ripped out the *actual* running of tests
back during 804a1336, when cleaning
up codecov tools.

Thanks to @mvdan for looking at the CI and CI config!

As spotted by staticcheck. While at it, remove punctuation from another
couple of errors, as per
https://github.com/golang/go/wiki/CodeReviewComments#error-strings:

	Error strings should not be capitalized (unless beginning with
	proper nouns or acronyms) or end with punctuation, since they
	are usually printed following other context.

There were two vet errors in two packages containing tests, resulting in
'go test' erroring out before any tests were run. Both were due to the
same reason - an Error method that ends up calling itself forever, thus
a panic.

While at it, 'gofmt -w -s' everything, which removes a redundant type.

Add traversal.Get function

(This should've been committed earlier.  I have too much WIP standing
uncommitted in my working tree.  Ow.  Mea cupla.)

This doesn't add much in the way of coverage, since it's internally
quickly convergenced with what the Focus tests cover, but in testing,
explicitness is good.

Kinded union gen

The AssignNode method is now supplied; and the previous hacky shrug
regarding switch statements with no applicable cases also had to go.
(Turns out that the no-applicable-cases thing coincidentally worked
for the "embedall" internal implementation mode; but didn't fly for
the "interface" internal style, because that would end up with
variable declarations made but not referenced.  Harrumph.)

This template munging business got nastier as time proceded.
I think we could drastically reduce the amount of redundancy in the
arugments to `kindedUnionNodeMethodTemplateMunge` if we re-did that
function with a more structural understanding of what's going on,
and made some basic understanding of what zero values are per golang
type, etc.

That can be future work, though.  Today, I want working kinded unions,
and I just want them done enough to use; kludge tolerance high.

So far, the generation itself runs, but the result will not yet compile.
I just want a checkpoint here.  (Most of this was written a few days ago already.)

Struct tuple representation codegen

This will become relevant when we have structs with tuple representation!

Fix a somewhat horrendous parity break in struct assembly between the AssembleEntry shortcut and AssembleKey+AssembleValue.

Self-hosting gen of the schema-schema.

... With a few minor alterations.

I've taken the opportunity to make a few tweaks to naming as I went.

A few cases use keyed unions when they should be kinded; this is a
significant todo.

A few cases use keyed unions where the schema-schema declaration says
they should use inline representations!  In these, I've come to believe
the schema-schema made a mistake; we probably will update it.

The overall structure, however, is not significantly diverged.

The whole specification is still written in code: the 'SpawnFoo'
placeholder methods are in heavy use.  (This might herald the beginning
of the end, for them, though!)  (We're also still making little
hacks to dodge the current placeholder typeinfo's lack of support
for inline defns; but this is purely a problem of the placeholder
typeinfo structures, and can disappear the instant we replace them.)

If you run this generation, the emitted code is (aside from those
caveats listed above) suitable for parsing schema declarations.

...!

Which means... we can soon turn around and start using this to build
up tooling which actually uses schema JSON as a config mechanism.
Which will then bring us quite a bit closer to being able to make
free-standing usable CLI tools for working with further codegen.

There's a few other bits to go.  For starters, right now, this is
just generating output into a demo output dir.  I've made no attempt
in this commit to rig it up as a proper snake-eating-its-tail by
replacing the 'SpawnFoo' methods and placeholder type info; that'll
come in due time.  (And I think we may still have fun choices coming
up with that, incidentally; the distinction between string type names
and reified pointers is still looming, and we need to figure out what
the story is for gen outputs containing their own type descriptions
(which may touch on the same interface design choices); etc.)  I'll
probably move somewhat cautiously with this, and only cut over after
polishing the gen outputs some more... but it's now near in reach.

The size of the generated output is also very likely to need work.
We're looking something on the order of 1.6MB of generated output.
(It's *highly* redundant: if you gzip it, it's 95kb.)  Mind: I've made
*no* effort whatsoever to bring this down.  So, it's probably safe to
assume we'll find some low-hanging fruit when we actually look into it.
(I'm not yet sure what the bar will be for satisfaction with this:
I regard the current number as vaguely "seems rather high", but it's
also for a fairly sizable schema and for a lot of features provided,
so maybe some size trades are just what we're going to face in golang.)

That's it.  There will probably be some PRs to the schema-schema
documents in the specs repo shortly.  Other than those, this should
also be about ready to line up with and parse JSON output created
by the other IPLD Schema DSL->JSON parsers we already have, which
could start unlocking some really neat stuff.  🎉

Codegen: approaching self-host

This thing need to be replaced with non-placeholder code soon; it's
getting pretty nasty.