Error post-processor

[paholg]

Dimensioned has terrible error messages. For example,

extern crate dimensioned as dim;
use dim::si::{M, S};

fn main() {
    M + S;
}

produces the following message:

 --> tests/dim-ops.rs:22:9
   |
22 |     M + S;
   |         ^ expected struct `dim::<unnamed>::PInt`, found struct `dim::<unnamed>::Z0`
   |
   = note: expected type `dim::si::SI<_,
      dim::<unnamed>::TArr<dim::<unnamed>::PInt<dim::<unnamed>::UInt<dim::<unnamed>::UTerm, dim::<unnamed>::B1>>,
      dim::<unnamed>::TArr<dim::<unnamed>::Z0,
      dim::<unnamed>::TArr<dim::<unnamed>::Z0,
      dim::<unnamed>::TArr<dim::<unnamed>::Z0,
      dim::<unnamed>::TArr<dim::<unnamed>::Z0,
      dim::<unnamed>::TArr<dim::<unnamed>::Z0,
      dim::<unnamed>::TArr<dim::<unnamed>::Z0,
      dim::<unnamed>::ATerm>>>>>>>>`
   = note:    found type `dim::si::SI<f64,
      dim::<unnamed>::TArr<dim::<unnamed>::Z0,
      dim::<unnamed>::TArr<dim::<unnamed>::Z0,
      dim::<unnamed>::TArr<dim::<unnamed>::PInt<dim::<unnamed>::UInt<dim::<unnamed>::UTerm, dim::<unnamed>::B1>>,
      dim::<unnamed>::TArr<dim::<unnamed>::Z0,
      dim::<unnamed>::TArr<dim::<unnamed>::Z0,
      dim::<unnamed>::TArr<dim::<unnamed>::Z0,
      dim::<unnamed>::TArr<dim::<unnamed>::Z0,
      dim::<unnamed>::ATerm>>>>>>>>`

where I have added line breaks to increase legibility.

I would like it to look something like this:

 --> tests/dim-ops.rs:22:9
   |
22 |     M + S;
   |         ^ expected  `m`, found `s`
   |
   = note: expected type `f64 m`
   = note:    found type `f64 s`

I imagine this could be accomplished by having a post-processor that creates a short Rust program which just creates variables with those type signatures and then prints them, then replaces the text.

It might only end up working for units created in dimensioned, but that's a start. It might also get hard to parse with other types mixed in there. Perhaps there's a better way?

[droundy]

This sounds like something that could be built into the compiler (I'm thinking through an RFC) where if a type had a specific method defined it is used by the compiler in error messages?

[paholg]

Yeah, that would be ideal. I was just trying to think of a way I could do it without editing the compiler.

[droundy]

That is reasonable. On the other hand, writing code to parse rust error messages might be considerably more challenging and more fragile, than editing the compiler. I'm not sure if a compiler plugin could manage this, but if so that would be nice.

Can you think of any other examples of a library that might have multiple representations of types, where users might prefer a particular representation? I guess typenum would be a good example that could also benefit from the same treatment, but it'd be lovely if there were another library (you didn't create) that could benefit from this sort of error-message simplification.

btw, contrary to your example, I would recommend using a syntactically correct representation in the error message, which even though it might seem less "physical" than f64 m, could be easier for uses to make use of Meter to fix their code.

[paholg]

I would recommend using a syntactically correct representation in the error message, which even though it might seem less "physical" than f64 m, could be easier for uses to make use of Meter to fix their code.

I agree that this would be better, but I'm not sure how it would work. Meter<f64> is just an alias for that more convoluted type; I see no way to convert back to it.

An option would be to display the type like SI<f64, [1, 0, 0, 0, 0, 0, 0]> (which it may someday be, if type numbers get added to the compiler), but the only way I can think of to get at anything that "looks metery" would be to use the print token, "m".

[jonysy]

@paholg have you seen @killercup's latest post? "A way to customize Rust error messages"

[paholg]

@jonysy I had, but thanks for pointing it out! I was meaning to mention it here, but now I don't have to. :)

[paholg]

An error-post processor has been written for typenum that could be leveraged here: https://github.com/auxoncorp/tnfilt