Type-level programming - how to provide better compiler errors?

Centril · June 25, 2019, 6:09pm

I think a large part of the blame here can be attributed to:

The compiler should report publicly exported type names if possible

opened 04:04PM - 04 Feb 15 UTC

E-hard C-enhancement A-diagnostics A-resolve P-medium T-compiler D-newcomer-roadblock

If a private type is reexported at some public location, the Rust compiler will …report the private location when referring to the type. It'd be more helpful if the compiler reported the public alias for it. This was reported by Coda Hale on Twitter. ---- Update by pnkfelix: here is a standalone bit of code illustrating the problem. ([play](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=ba6fa8cd0b3b03f756ebc8cbd95597a4)): ```rust mod a { mod m { pub struct PrivateName; } pub use m::PrivateName as PublicName; } fn main() { // a::m::PrivateName; // would error, "module `m` is private" a::PublicName; a::PublicName.clone(); } ``` As of nightly 2019-06-17, this issues the diagnostic: ``` > error[E0599]: no method named `clone` found for type `a::m::PrivateName` [...] ^^^^^^^^^^^^^^^^^ | (author of `fn main` wants to see `a::PublicName` here) ```

Topic		Replies	Views
Error ergonomics language design	34	3642	March 25, 2019
Better user-definable error messages language design	5	1415	February 13, 2021
Idea: Type error chains compiler	1	548	January 10, 2020
There needs to be some way to debug exploding type lengths	4	858	June 18, 2020
Mechanical suggestions for some borrow checker errors compiler	4	1144	May 9, 2019

Type-level programming - how to provide better compiler errors?

Related Topics