Use "goldenfiles" for some tests about pikelet HOT 11 CLOSED

Oh damn! That's because there is a global name generator that makes a special name that is unique for the entire program. The global state is in the nameless crate, which makes it quite hard to find!

I didn't want to use dependency injection for it, but perhaps I might need to.

Perhaps we could just leave those tests for now?

from pikelet.

Would you be interested in picking this up @adrianwong?

from pikelet.

Sure, I'll give it a shot @brendanzab!

from pikelet.

As some extra info, I'm expecting we'll probably want to use the fmt::Debug trait like so:

#[test]
fn ann_ann_right() {
     // Do we want this to be relative to the current test directory?
    let mut mint = Mint::new("tests/goldenfiles");
    let mut file = mint.new_goldenfile("ann_ann_right").unwrap();

    let term = parse(r"Type : (Type : Type)");

    write!(file, "{:#?}", term).unwrap();
}

The funny {:#?} will tell Rust to print out the value using an indented/pretty-printed output. This should work nicely for diffs when snapshot testing.

from pikelet.

Seems that this repo does all the golden tests in one test: https://github.com/slava-sh/rust-bundler/blob/master/tests/golden.rs

It would be interesting to see what the test failures looked like!

from pikelet.

I've hit a bit of a snag with the snapshot testing of the arrow, lam_ann, and pi tests in the desugar module. All three consistently fail snapshot testing due to the generation of a unique GenId(u32) struct on each run.

From what I am able to tell, the presence of the GenId node in the AST corresponds with nameless::bind( Name::user("_") ), but the rest is a bit beyond me.

Thoughts? What I've done so far can be found here.

from pikelet.

If you're curious, this is where the ids are generated (on the call to GenId::fresh):

from pikelet.

Super neat thing is that it's showing that arrow types, eg. Int -> Int are actually just special cases of dependent functions/pi types/foralls: (x : Int) -> Int, where the parameter is not mentioned in the return type.

from pikelet.

Ah, whoops, I had it backwards. So in the tests when we parse, e.g. r"(x : Type -> Type) -> x", we then assert that the first Type has name x, whereas the second type doesn't have one, hence the Name::user("_")?

from pikelet.

Ok I'll leave the snapshot testing out for those three tests then!

from pikelet.

yup, spot on!

from pikelet.