# Developer-provided compiler notes **URL:** \ **Category:** language design\ **Created:** [July 2, 2023, 5:03am UTC](https://internals.rust-lang.org/t/developer-provided-compiler-notes/19084 "2023-07-02T05:03:53Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![orowith2os](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/orowith2os/32/11023_2.png) [@orowith2os](https://internals.rust-lang.org/u/orowith2os)\ **Post date:** [July 2, 2023, 5:03am UTC](https://internals.rust-lang.org/t/developer-provided-compiler-notes/19084/1 "2023-07-02T05:03:53Z")
Rust right now has _very_ nice error messages, and can even suggest fixes for some common issues. What I think it's lacking, though, is the ability for a developer of a library to, say, for example, warn a user that their function should only be used in a specific context, may be subject to change, or other situations. What I propose is adding the ability for a compiler to add an error as such: ```rust #[vashta_nerada("This function is a bit hacky, and may be very buggy in practice. Tread carefully.")] fn do_something() { /// something } ``` The name is inspired by the [Vashta Nerada from Doctor Who](https://tardis.fandom.com/wiki/Vashta_Nerada), and I think it's fitting. It can be used to signify when something's dangerous, and the compiler can't feasibly warn the user with enough information. It's also flexible enough that it could remove the need for other, more specific, features. I'm not sure if just a crate-added attribute macro would be enough here. Name can probably be put up for discussion, but I'd like to focus more on the specifics of how to use this. ---
**Author:** ![dlight](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/dlight/32/8462_2.png) [@dlight](https://internals.rust-lang.org/u/dlight)\ **Post date:** [July 2, 2023, 8:55am UTC](https://internals.rust-lang.org/t/developer-provided-compiler-notes/19084/2 "2023-07-02T08:55:51Z")
Also, it's odd that rust has [`compile_error!()`](https://doc.rust-lang.org/std/macro.compile_error.html) but doesn't have `compile_warning!()`, it feels incomplete. ---
**Author:** ![jrose](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jrose/32/9591_2.png) [@jrose](https://internals.rust-lang.org/u/jrose)\ **Post date:** [July 2, 2023, 3:59pm UTC](https://internals.rust-lang.org/t/developer-provided-compiler-notes/19084/3 "2023-07-02T15:59:54Z")
`deprecated` is basically this today with some added semantics, so (a) you have a workaround, and (b) it’s clearly not too hard to implement. ---
**Author:** ![kpreid](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kpreid/32/8484_2.png) [@kpreid](https://internals.rust-lang.org/u/kpreid)\ **Post date:** [July 2, 2023, 4:22pm UTC](https://internals.rust-lang.org/t/developer-provided-compiler-notes/19084/4 "2023-07-02T16:22:24Z")
One of the things that _make_ Rust's error messages nice is that they each have a specific purpose and are actionable one way or another; the typical Rust project has _no warnings_ except momentarily, because they've all been either fixed or `allow`ed. Thus, there should not be a mechanism for generically saying “this is dangerous”. It should specify what the danger is. Otherwise people will (rightly) write `#[allow(vashta_nerada)]` and leave the reader of the code uninformed about what the hazard is unless _they_ also write a specific comment. At that point, you're better off if you just put the hazard in the function name. `do_something_flaky()`. > [@orowith2os](#): > > The name is inspired by the [Vashta Nerada from Doctor Who](https://tardis.fandom.com/wiki/Vashta_Nerada), and I think it's fitting. And I say: don't make people afraid of the dark; build lights. Be precise. * * * You may be interested to hear of plans for adding more ways to declare custom diagnostics: > > > \# Summary > > This RFC proposes to add a common \`#\[diagnostic\]\` attribute namesp…ace for attributes that can influence the error messages emitted by the compiler. It specifies a set of rules what attributes in this namespace are allowed to do, how these attributes must be handled by the compiler and what is disallowed in this namespace. > > In addition this RFC proposes a \`#\[diagnostic::on\_unimplemented\]\` attribute to influence error messages emitted by unsatisfied traits bounds. > > I would like to use this possibility to thank the rust foundation for supporting my work on this RFC through a project grant. > > > \--- > > \[Rendered\](https://github.com/weiznich/rfcs/blob/diagnostic\_attribute\_namespace/text/3366-diagnostic-attribute-namespace.md) ---
**Author:** ![8573](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/8573/32/4913_2.png) [@8573](https://internals.rust-lang.org/u/8573)\ **Post date:** [July 2, 2023, 6:10pm UTC](https://internals.rust-lang.org/t/developer-provided-compiler-notes/19084/5 "2023-07-02T18:10:35Z")
If there were a mechanism to `allow` (accept and dismiss) this warning for a specific third-party function to which the attribute has been attached, I can see it as possibly being useful, but a warning that applies to all uses of a function in one's API, if one intends for users to continue using that function, seems an unhelpfully blunt instrument. > [@orowith2os](#): > > The name is inspired by [...] The creatures described in the linked wiki article sound more dangerous than the warning does. While I've never read a Lovecraft book, I quickly think of [that](https://github.com/rust-lang/rust/pull/20944). ---
**Author:** ![orowith2os](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/orowith2os/32/11023_2.png) [@orowith2os](https://internals.rust-lang.org/u/orowith2os)\ **Post date:** [July 3, 2023, 7:04am UTC](https://internals.rust-lang.org/t/developer-provided-compiler-notes/19084/6 "2023-07-03T07:04:14Z")
> [@kpreid](#): > > And I say: don't make people afraid of the dark; build lights. Be precise. > > * * * > > You may be interested to hear of plans for adding more ways to declare custom diagnostics: > > [https://github.com/rust-lang/rfcs/pull/3368](https://github.com/rust-lang/rfcs/pull/3368) Fair enough, I made this suggestion when I was a bit tired (putting it lightly...) and stuck on some other stuff, I guess the name suggestion and whole idea was a tad affected by that. I'll save the Doctor Who references for when I inevitably try writing my own programming language 🙂 @dlight mentioned there not being a `compile_warning!()` macro, that would probably fix up this concern too, while being more specific and not so scary-sounding. ---
**Author:** ![Nemo157](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nemo157/32/11585_2.png) [@Nemo157](https://internals.rust-lang.org/u/Nemo157)\ **Post date:** [July 3, 2023, 8:07am UTC](https://internals.rust-lang.org/t/developer-provided-compiler-notes/19084/7 "2023-07-03T08:07:59Z")
`compile_warning!` would only be useful for macros, if you try to use it within your own code it will be suppressed by `—cap-lints`. ---
**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:** [July 3, 2023, 4:15pm UTC](https://internals.rust-lang.org/t/developer-provided-compiler-notes/19084/8 "2023-07-03T16:15:28Z")
> [@orowith2os](#): > > What I think it's lacking, though, is the ability for a developer of a library to, say, for example, warn a user that their function should only be used in a specific context, may be subject to change, or other situations. As alluded by the RFC that was linked earlier, the intention is to start adding such functionality over the course of the next 18 months, first to customize trait bound and type errors, and later to allow for further customization. There's some progress in [stabilizing the proc-macro diagnostics APIs that would let you create both errors and warnings](https://github.com/rust-lang/rust/pull/111571) with the full (almost) power that rustc has. I am also exploring the possibility to work on some mechanism for custom lints, with the intention of eventually producing an API that rustc can commit to and clippy use for this (so as to reduce the number of special tools needed). This would allow people to have per projects lints to enforce invariants that for some reason or another can't be represented in the type system. Please bear with us as we slowly make progress on this. I'm really interested in giving crate authors the tools necessary for an amazing developer experience. ---
**Author:** ![Kyuuhachi](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kyuuhachi/32/13179_2.png) [@Kyuuhachi](https://internals.rust-lang.org/u/Kyuuhachi)\ **Post date:** [August 21, 2023, 11:41pm UTC](https://internals.rust-lang.org/t/developer-provided-compiler-notes/19084/9 "2023-08-21T23:41:12Z")
> [@orowith2os](#): > > What I think it's lacking, though, is the ability for a developer of a library to, say, for example, warn a user that their function should only be used in a specific context, may be subject to change, or other situations. We do have an attribute for this: `#[doc]`. ---
**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:** [November 19, 2023, 11:41pm UTC](https://internals.rust-lang.org/t/developer-provided-compiler-notes/19084/10 "2023-11-19T23:41:55Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.