GitLab

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.

This is full of mundane plonking away at adding stars and ampersands,
of which approximately none are interesting.

(I'm particularly frustrated by this because these are all placeholder
types, and we're getting *very* close to replacing them, as we get
closer and closer to self-hosting... at which point all of this bonking
about will be made totally irrelevant.  And yet to close the last mile,
these "small" fixes are surprisingly irritating.  Ah well.)

The bits that *are* interesting:

- the Spawn functions for type info now take strings rather than types
(so that they don't provoke a cycle problem for the user when
constructing the information to describe cyclic type info);

- all of the Type info structure hold a pointer to the TypeSystem, and
use that to look up reified Type info for related types, so that their
methods don't force the caller to do that themselves.

(The TypeSystem pointer was already there, amusingly; just never before
initialized, because it hadn't turned out to be load-bearing yet.)

It also would've been possible to just change all the methods on the
Type types to return TypeName rather than full Type info.  That would
avoid the need to use a TypeSystem pointer.  I didn't because:

Overall, this was done in such a way as to minimize the diff that
impacts within the templates.  This was a goal because updating
templates is a fair bit more work than other code due to the weak
compiler support.  And we'll end up reviewing and changing these
methods when we get to our goal of self-hosting generation of the
schema types from the schema-schema, so, it's not worth pushing around
diffs in that same area when they'd be sure to be churned under soon.

These were apparently never used, or their users got churned under
at some point and I failed to clean these up at the same time.

It's a good idea to have tests that are agnostic to codegen vs
runtime type semantics implementations... but at this point we should
reengage with that by just extracting the stuff currently in the
codegen package's tests, because it's much more comprehensive and
also almost entirely abstracted already (it just happens to be in the
wrong place in the file/package hierarchy for no particular reason).