If two files depend on the same file we ended up overwriting the
first written file which is problematic because the "internal" types
would not be written the second time.
The generated code for typed structs now uses a Go struct which
implements Value directly. The fields in this struct uses the "user"
type. (The union value still uses types.Value though.)
When a typed struct is created by the decoder, it asks for a struct
builder which returns a channel that the values of the fields of the
struct are sent to.
The output file should always be emitted relative to -out-dir. I was
incorrectly appending the path to the input file onto that provided in
-out-dir to construct the path to the output file.
1) truncate filenames containing hash to only use first 7 chars of hash.
2) change output filename from <base>.go to <base>_noms.go
3) check for includes of file in same directory and don't generate twice.
We'd wound up in a spot where serialization code used 'TypeRefKind' to
mean one of two very different things...either an actual value that
describes some Noms type, or a reference to a type definition that
lives somewhere else. To get rid of this ambiguity, we introduce
'UnresolvedKind' to take over the latter meaning. Now, TypeRefKind
means _only_ a value that describes a type. If you want to point off
to a type definition elsewhere in the type package, or in another
type package, use UnresolvedKind.
Sets, Lists, Refs and Maps of imported types work now.
This PR also factors some of codegen.go into a separate package, to slim down
that file a bit.
Towards issue #294
The new serialization format use "t " as in typed. The rest of the
message is a JSON array describing the typed data. The type is
described by types.TypeRef
Fixes#384
Issues #281, #304
This adds code for finding imported type packages and generating
code for them, but does not yet handle generating code that uses
those types.
Towards issue #294
Also, switch to using a ref.Ref when getting/setting the package
ref in a TypeRef. Using a types.Ref just led to lots of manual
boxing and unboxing every time I wanted to use the reference.
Toward issue #294
This patch mostly merges parse.Package and types.Package, though it
can't quite go all the way. A types.Package doesn't have 'using'
declarations, while the parsed representation of a .noms file needs to
have that information. Hence, the parse package is moved to the 'pkg'
package, and pkg.Parsed is introduced. This type embeds types.Package
and adds the necessary additional information.
To make inroads on handling imports, I enhanced ParsePackage() (now
called ParseNomDL()) to actually process the 'alias' and 'import'
statements in the input and go replace namespaced type names in the
package with refs of imported packages. For example, the TypeRef for
'Bar' generated in the following package
alias Foo = import "sha1-ffffffff"
struct Bar {
f: Foo.RockinStruct
}
will actually return types.Ref{sha1-ffffffff} when you call PackageRef()
on it.
In addition, I've added a function to the new 'pkg' package,
which allows the caller to get the dependencies of a type package
from a chunk store.
Fixes issue #353, towards issue #294
These were two representations of, essentially, the same information.
They were separate because they provided different APIs to similar
information, but the APIs became more similar once we started using
native types (as opposed to Noms types) for the various Make*TypeRef()
functions.
Unifying these is a big step to unifying parse.Package and types.Package,
which is pretty necessary for dealing with imported packages.
Fixes issue #338
This make Commit a typed struct with a Set(Commit).
This also fixes a case where the recursive detection for determining
if a Def can be created was not working.
We want to explore encoding type information about Noms data in
the Noms database. So, we need some way to describe types. This
takes the shortest path to making a Noms type called "TypeRef" that
is a peer of Set, Map et al and can describe all the types we currently
use.
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.
