Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
as part of my Rust Foundation Project Grant I'm currently working on improving error messages emitted by rustc for type mismatched based on the usage of trait heavy crates. The general idea here is to provide tools for crate authors to influence at least some error messages by themself. There are quite a lot of places where crate authors can provide much more context than a general rustc heuristic, just based on their knowledge onto how their crate is structured. My project goal is to collect different examples of such errors occurring in practice, classifying them based on what would be required to improve these messages and try various existing ideas on how such a integration in rustc's error reporting system could work in practice. With this post I'm looking forward to learn about cases of bad error messages you encountered in the past. I've created a repository to collect examples here. Please open an issue or even a PR with an example there or report them here inline.
uom, uncomment line 15 of the si.rs example and run. The actual error is that you cannot add a length and a time. The rustc error message isn't so easy to read:
Those points generally aligns quite well with my goals. For the scope of the rust foundation grant project I want to collect some examples for #[rustc_on_unimplemented] and implement #[do_not_recommend] (as outlined in RFC-2397). For now my focus is just on showing that these attributes can be helpful for crates as well and have some concrete examples there. This hopeful enables a discussion about some sort of stabilization. In the context of stabilization I had the idea that it might be meaningful to "stabilize" those attributes as tool attribute, rather than as general language attribute. I assume they will likely be rustc specific for quite a while, so #[rustc::on_unimplemented] seems to be fitting.
It's been a while so I don't have a specific example but I remember being really confused with errors coming from Diesel.
git clone https://github.com/vlmutolo/tower-biscuit-auth git checkout dccb812c825ad1969169199f1b1fd7508da15b0c cargo check --examples --features http
I can open a PR if desired but typed-builder is a big example for me of where this would be super useful. It's a good example of using traits/type safety for compile-time guarantees but the error messages are really subpar compared to the standard Rust experience, so feels like a very arbitrary compromise on Rust's strengths.
Related posts
- SQLite + Rust: Building a CLI Password Vault 🦀
- How moving from Pandas to Polars made me write better code without writing better code
- Proton, a fast and lightweight alternative to Apache Flink
- What I Talk About When I Talk About Query Optimizer (Part 1): IR Design
- Solutions to manage runaway Snowflake costs?