Propagate collection names and aliases through compilation

[dburgener]

Propagate collection names and aliases through compilation

[dburgener]

This is definitely an interaction of two bugs.

1. Something isn't handled right about aliases in collections, causing the function to incorrectly not be found.
2. When we're creating a no such function error, we've already discarded Collection specific information. The collection names have become part of their member functions. However, in this case, we don't have a member function, which is why we're making an error. Unfortunately we don't have a list of collections either. We either need to propagate the collection names forward to have them at this error point, or we need to do some sort of fudge like checking all functions or going back to the AST in order to get Collection names at this point. Probably the first is better, but propagating the collection names through cleanly without major refactors isn't particularly trivial. I tried just adding them to the TypeMap, but TypeInfos require TypeDecls and Collections have CollectionDecls instead. That's of course changeable, but the more we change the definition of TypeInfo to accomodate this the more we risk breaking something else. It might be cleaner to just save a list in build_func_map() or extend_type_map(), and pass that through to here, but I haven't looked that through yet.

As you may infer from the above lengths, I've spent most of my time so far on issue 2. I might sit on that for a bit and go back to issue 1 for now. That's arguably more important, and probably an easier fix, although I haven't dug into it too much. I was hoping to fix issue 2 first, so that I could use issue 1 to test it, but issue 2 should be independently testable. Just something like the below should cleanly repro issue 2 regardless of issue 1 being fixed:

collection foo {
    fn func(domain source) {
        allow(source, self, process, signal);
    }
}

domain bar {
    foo.doesnt_exist();
}

[dburgener]

Changed title. #198 should address directly the exact issue originally reported here.

In order to clean up the error message, and handle aliases on collections, we really need to store the list of collections and their aliases somewhere so that we can look back at them later.