Parse with errors

[uncomputable]

Add infrastructure for relaying pretty errors to the user. Enable errors during parsing (the compiler still panics). Avoid unwraps.

Format the error messages similar to how the rust compiler does it.

  |
1 | let a1: List<u32, 2> = None;
  |              ^^^^^^ List bound must be a power of two greater one: 2, 4, 8, 16, 32, ...

Support multi-line errors.

  |
2 | let x: u32 = Left(
3 |     Right(0)
4 | );
  | ^^^^^^^^^^^^^^^^^^ Type mismatch: Expected value of type `u32`, got `Either<Either<_, u32>, _>`

An error (RichError) consists of an error variant (Error) and a context (spanned area inside a file). During parsing we attach the line/column position of the affected area. The parser works on local chunks and doesn't have access to the entire file. When parsing is done, we attach the entire file to enable pretty printing. The human encoding follows the same approach.

Supersedes #27

[apoelstra]

In 6bebb3862abbb93027cdbc5c4c5b575de7962c3d:

I think it'd be better to move TypeName into type.rs than to move innards of type.rs into the jet module and then have to expose a ton of private stuff.

[apoelstra]

In 5807df7fca538fd6f5e0a0a7f014ba174102c41e:

Why can't inference be a submodule of types. Then it would have access to the private data from types but you won't need to expose it. In particular making UnificationVar have public fields seems like a super bad idea.

[apoelstra]

Renames in 576a62cceb580e2dc7a5b3c59fab0956d137e204 looks good

[apoelstra]

In 705d2f6768e9a47b120aa6d68986ed888be9b03e:

How does this variable factor relate to the existing one in src/types/variable.rs? It seems like this commit partially reverts #133 which removed the old variable factory, but doesn't make any reference to it. Can you clarify this?

[apoelstra]

Ignore all the above comments. I was reviewing #34 in rust-simplicity, which looks weird because it's from 2022 and predates all the stuff that I'm mentioning :P.

[apoelstra]

dbd1196448d7342953a4f5e96511ceaf976731b6 looks good!

One nit is that I see you replaced an assert_eq with a debug_assert ... I am pretty sure there is a debug_assert_eq. But I guess you tried that.

[uncomputable]

I actually didn't know about debug_assert_eq. For some reason I thought it wasn't available, maybe because my IDE doesn't know it. It seems to exist since Rust 1.0.0. I will start using it from now.