Proc macros allowed to modify error information as well as source code

language design
#1

I was discussing the designing of APIs for a UI framework, and the issue came up that error messages can be very opaque. As the API designers, we have more information than the compiler, and we could use this information to modify the error messages to be more useful to the downstream user. So the question is: could rustc expose some way of modifying errors before reporting them, similar to how proc macros work on source code.

This is definitely a raw idea rather than a developed proposal. I'm just interested if the same idea has come up before?

#2

How would this work? The vast majority of error messages are excellent, imo.

#3

I agree, and this isn't about dealing with some defficiency with rustc error messages themselves. The problem comes when you have types that use a lot of generics. A contrived example might be a tree, where a Child trait is implemented by tuples. You could imagine how this could cause a type explosion.

A real-world example of the error messages that we would like to avoid is

the trait `ElementTree<u16, ButtonPressed>` is not implemented for `Row<ElementTuple_4<WithEvent<u16, &ButtonPressed, capitaine::elements::Button<u16, &ButtonPressed>, [closure@examples/list.rs:31:42: 34:10]>, capitaine::elements::Label<u16, &ButtonPressed>, capitaine::elements::Label<u16, &ButtonPressed>, capitaine::elements::Label<u16, &ButtonPressed>, u16, &ButtonPressed>, u16, &ButtonPressed>`

The user will have used the wrong type somewhere in the tree, and we as the API writers will be able to work out where, but since rustc knows nothing about our API it's not reasonable to expect it to give the optimal error message.

#4

I think that rusc still has room for improvements wrt tuple trait errors. I think there are only a couple of patterns for performing generic variadic type gymnastics. Maybe if you point out what the missing link was, we'll be able to come up with an error pattern that can find and point out those sorts of missing links.

I was sort of in the same boat, but we found better errors messages without needing user defined errors: Better user-definable error messages

We probably won't be able to fix it all the way, but Im guessing other things run into the same type of ugly messages.

#5

I read that the link you posted, and it looks like the second item you mention is the same as what I'm getting at. The buy-in it needs from rustc is some kinda of minimal stability on error messages, in any format, and possibly the cargo support you talk about.