# Custom messages for compilation errors **URL:** \ **Category:** compiler\ **Created:** [March 18, 2022, 1:01pm UTC](https://internals.rust-lang.org/t/custom-messages-for-compilation-errors/16343 "2022-03-18T13:01:33Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![mr\_rustbot](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/mr_rustbot/32/9200_2.png) [@mr\_rustbot](https://internals.rust-lang.org/u/mr_rustbot)\ **Post date:** [March 18, 2022, 1:01pm UTC](https://internals.rust-lang.org/t/custom-messages-for-compilation-errors/16343/1 "2022-03-18T13:01:33Z")
One of the biggest benefits of Rust is that it allows API authors to use the type system to enforce domain invariants at compile time. However, currently compiler errors only convey the reason for the error from the language perspective (ownership, borrow checker, etc.). They don't help with explaining WHY the author may have chosen to use `self` vs `&self`. As a result, a lot of people, even those who aren't so new to Rust, may feel like the language is being unnecessarily complex (i.e. fighting the compiler) instead of grateful that the compiler stopped them from doing something wrong. I think it would be really nice to allow us to annotate functions with a macro to allow us to hook into certain compiler errors to add custom messages. E.g. Trying to do `file.read()` after you called `file.close` already currently just yells at you about ownership. With this feature, the `File::close()` function could be annotated with a macro specifying that if there is a use after move error for self, it should also say "File handles shouldn't be read / written to after they have been closed." I think this would be useful, not just for conveying that Rust's rules are often there for good reason, but also to clarify the kinds of things Rust's affine type system can be used for instead of just memory safety / systems programming stuff. ---
**Author:** ![davidhewitt](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/davidhewitt/32/5902_2.png) [@davidhewitt](https://internals.rust-lang.org/u/davidhewitt)\ **Post date:** [March 18, 2022, 1:53pm UTC](https://internals.rust-lang.org/t/custom-messages-for-compilation-errors/16343/2 "2022-03-18T13:53:14Z")
I had a related idea recently for traits. Because they encode behaviour, having an error message explaining the value not satisfying a trait bound is described in behaviour terms may be helpful. For example, imagine some trait `ToFoo`. Maybe there could be some annotation like "converts to a Foo", and errors could read something like "i32 cannot be converted to a Foo" before the usual trait bound unsatisfied error. It's possible this could be extracted from the doc comment if formatted in a certain way. Maybe all of this is just wishful thinking. Food for thought, at least. ---
**Author:** ![ekuber](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ekuber/32/1646_2.png) [@ekuber](https://internals.rust-lang.org/u/ekuber)\ **Post date:** [March 18, 2022, 4:27pm UTC](https://internals.rust-lang.org/t/custom-messages-for-compilation-errors/16343/3 "2022-03-18T16:27:01Z")
Within the compiler (and in nightly if you are so inclined) we can use [`rustc_on_unimplemented`](https://doc.bccnsoft.com/docs/rust-1.36.0-docs-html/unstable-book/language-features/on-unimplemented.html) for traits, but [it can get unwieldy](https://github.com/rust-lang/rust/blob/43769af69e43d0fb9770f0a392671f000595df78/library/core/src/ops/try_trait.rs#L226-L314). I wasn't so much designed as it was grown in an adhoc depending on the needs of the compiler itself, so I wouldn't expect a potentially stabilized attribute to look like it, but I would love it if the functionality were provided in some way. Having some support for annotating state machines would also be lovely so when you call `file.read()` you get something like "`file` was consumed when it was closed by calling `File::close`", or something. ---
**Author:** ![mr\_rustbot](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/mr_rustbot/32/9200_2.png) [@mr\_rustbot](https://internals.rust-lang.org/u/mr_rustbot)\ **Post date:** [March 18, 2022, 5:29pm UTC](https://internals.rust-lang.org/t/custom-messages-for-compilation-errors/16343/4 "2022-03-18T17:29:33Z")
Is this something you think I should write an RFC for? ---
**Author:** ![yaahc](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/yaahc/32/6606_2.png) [@yaahc](https://internals.rust-lang.org/u/yaahc)\ **Post date:** [March 18, 2022, 6:26pm UTC](https://internals.rust-lang.org/t/custom-messages-for-compilation-errors/16343/5 "2022-03-18T18:26:08Z")
related, I would also love to use this on negative trait impls. I'd use it to attach a message for why `&str` and `String` don't impl `Error` I'd also want to use this on `Box` not implementing `Error`, but in this case it's harder because we don't want to make the API commitment to never implement it via a negative impl, the issue is currently insufficient support for specialization, though it might be hard to compress this explanation into a compiler error message. I'd probably prefer to use an `--explain EXXXX` for this case. ---
**Author:** ![yaahc](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/yaahc/32/6606_2.png) [@yaahc](https://internals.rust-lang.org/u/yaahc)\ **Post date:** [March 18, 2022, 6:31pm UTC](https://internals.rust-lang.org/t/custom-messages-for-compilation-errors/16343/6 "2022-03-18T18:31:11Z")
I don't think it needs an RFC at this point. The lang team is already actively working on this problem From their 2022 roadmap draft > ## Theme: Help users help each other > > - _The vision:_ > - Library authors (and consumers) have tools to manage portability. > - Library authors have tools to manage their development lifecycle. > - Library authors can tailor the developer experience. > > - We achieve this by empowering library authors with new language capabilities, including those previously reserved for the compiler and standard library, such as lints, diagnostics, and stability attributes. > > Libraries are key part of how Rust empowers its users, but developing and maintaining a Rust library should be easier. The standard library and compiler have access to a number of unique capabilities, ranging from diagnostics integration to the stable/nightly development cycle, that other Rust libraries cannot take advantage of. For Rust 2024, we want to empower library authors with new capabilities that make it easier to author and maintain Rust libraries. IMO you should go straight to [the lang zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang) and open a topic to express your interest in participating with their planned effort ---
**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\ **Post date:** [June 16, 2022, 6:32pm UTC](https://internals.rust-lang.org/t/custom-messages-for-compilation-errors/16343/7 "2022-06-16T18:32:09Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.