When computing if a Map/Set key contains another Map/Set/List we need
to ensure that we are not hitting a recursive type or we hit an i-loop.
Partial fix for #320
Due to limitations in Go we cannot create a Def for a Map or Set that
has a key that is a Map, Set or a List. This is because the key if a Go
map needs to be a comparable and maps and slices are not comparable.
The codegen.go command line utility now detects the package name from
the file that it was invoked from if `--package` was not provided.
It also processes all `.noms` files in the current directory in case
the `--in` flag was not provided.
As arv pointed out, the parser should no longer generate TypeRefs
of UnionKind, so I made it stop doing that. Getting rid of UnionKind
has the side effect of making UnionDesc no longer capable of satisfying
TypeDesc, so one can no longer create a TypeRef that holds a UnionDesc.
That's correct for production, but I'd been using Field structs (which
contain a TypeRef) to define my test cases. Since I still need to test
that the parser correctly handles named union fields in structs, and
Field structs are no longer capable of expressing that, I needed to
create a new testField struct and some attendant types to allow me
to write all my test cases.
Arv pointed out that there's really no difference between a named
union struct field and a struct field whose type is a struct that
contains only an anonymous union. This patch makes the parser replace
the TypeRef of UnionKind in each named union field with a TypeRef of
StructKind that contains only an anon union.
Fixes Issue #286
These should be disallowed, so disallow them. This also makes
us use a map for fields and choices, which is probably the right
way to store that information in Noms anyway. This patch means
we'll be on better footing for converting datastructures to Noms.
Towards issue #281
