# Idea: Mark code as "known dead" to silence dead-code lint

**URL:** <https://internals.rust-lang.org/t/idea-mark-code-as-known-dead-to-silence-dead-code-lint/7409>\
**Category:** language design\
**Created:** [April 27, 2018, 3:07pm UTC](https://internals.rust-lang.org/t/idea-mark-code-as-known-dead-to-silence-dead-code-lint/7409 "2018-04-27T15:07:11Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![nikomatsakis](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nikomatsakis/32/5410_2.png) [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)\
**Post date:** [April 27, 2018, 3:07pm UTC](https://internals.rust-lang.org/t/idea-mark-code-as-known-dead-to-silence-dead-code-lint/7409/1 "2018-04-27T15:07:11Z")

</div>

There should be a way to tag a function as “believed to be dead code”. This would silence the dead-code lint unless we actually found a use of the fn. This would be so useful when prototyping, when you have things that you know to be dead (because you didn’t write the consumer yet, or you commented it out). `#[allow(dead_code)]` isn’t quite right, because it tends to just hang out long after you’ve added the consumer (since you forget it’s there).

---

<div class="post-metadata">

**Author:** ![steven099](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/steven099/32/3871_2.png) [@steven099](https://internals.rust-lang.org/u/steven099)\
**Post date:** [April 27, 2018, 3:46pm UTC](https://internals.rust-lang.org/t/idea-mark-code-as-known-dead-to-silence-dead-code-lint/7409/2 "2018-04-27T15:46:02Z")

</div>

There’s still the danger of retaining a forgotten `allow` in the case where the code actually is still dead, but I guess this is ultimately handled by `forbid`. Something like `#[expect(dead_code)]` would still provide more immediate feedback to remove the annotation when it’s no longer needed, which makes for less work once you eventually add `forbid`. I suppose the question is whether this is only applicable to the `dead_code` lint, or if other lints would benefit from a general syntax like `expect`. I think any time you silence a lint locally during development, being reminded to remove the annotation when it’s no longer needed could be useful.

---

<div class="post-metadata">

**Author:** ![repax](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/repax/32/1342_2.png) [@repax](https://internals.rust-lang.org/u/repax)\
**Post date:** [April 27, 2018, 4:02pm UTC](https://internals.rust-lang.org/t/idea-mark-code-as-known-dead-to-silence-dead-code-lint/7409/3 "2018-04-27T16:02:40Z")

</div>

~~How about `#[not_used]`?~~

~~If found to be used the compiler should complain loudly.~~

~~(cf. `#[used]`, [rfc 2386](https://github.com/rust-lang/rfcs/pull/2386#issuecomment-384800026))~~

* * *

No wait, this becomes confusing:

```rust
#[not_used]
#[must_use]
fn foo() -> i32 { ... }

```

We already have `#[must_use]` so, probably an attribute with a completely different name.

---

<div class="post-metadata">

**Author:** ![nikomatsakis](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nikomatsakis/32/5410_2.png) [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)\
**Post date:** [April 27, 2018, 7:20pm UTC](https://internals.rust-lang.org/t/idea-mark-code-as-known-dead-to-silence-dead-code-lint/7409/4 "2018-04-27T19:20:48Z")

</div>

Right idea – but yeah wrong name =)

I was thinking `#[expect(dead_code)]` or something.

Oooh, we could generalize this! Something like `#[expect(lint)]`, which means that we expect a lint to fire on the annotated thing – and if it doesn’t, _that_ is a warning.

---

<div class="post-metadata">

**Author:** ![scottmcm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/scottmcm/32/2355_2.png) [@scottmcm](https://internals.rust-lang.org/u/scottmcm)\
**Post date:** [April 27, 2018, 7:34pm UTC](https://internals.rust-lang.org/t/idea-mark-code-as-known-dead-to-silence-dead-code-lint/7409/5 "2018-04-27T19:34:37Z")

</div>

> [@nikomatsakis](#):
>
> Something like #[expect(lint)], which means that we expect a lint to fire on the annotated thing – and if it doesn’t, that is a warning.

Which is exactly the second half of this RFC 😆

> <https://github.com/rust-lang/rfcs/pull/2383>
>
> This RFC makes two additions to the lint attributes in Rust code:
> 
> \- add a \`re…ason\` field to the attributes that permits custom text when rendering
> \- add an \`expect\` lint attribute that acts as \`#\[allow\]\`, but raises a lint when the lint it wants to allow is not raised.
> 
> \[Rendered\](https://github.com/rust-lang/rfcs/blob/master/text/2383-lint-reasons.md)
> \[Tracking issue\](https://github.com/rust-lang/rust/issues/54503)

---

<div class="post-metadata">

**Author:** ![nikomatsakis](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nikomatsakis/32/5410_2.png) [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)\
**Post date:** [April 27, 2018, 7:35pm UTC](https://internals.rust-lang.org/t/idea-mark-code-as-known-dead-to-silence-dead-code-lint/7409/6 "2018-04-27T19:35:16Z")

</div>

I confess I hadn’t even seen that =)

I’ve been kind of caught up lately.

---

<div class="post-metadata">

**Author:** ![steven099](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/steven099/32/3871_2.png) [@steven099](https://internals.rust-lang.org/u/steven099)\
**Post date:** [April 27, 2018, 8:35pm UTC](https://internals.rust-lang.org/t/idea-mark-code-as-known-dead-to-silence-dead-code-lint/7409/7 "2018-04-27T20:35:29Z")

</div>

> [@nikomatsakis](#):
>
> I was thinking #[expect(dead\_code)] or something.
> 
> Oooh, we could generalize this!

Um... yeah! 😅

> [@scottmcm](#):
>
> Which is exactly the second half of this RFC 😆

Weird, I hadn't seen that either. Must be a brainwave going around 😄

---

<div class="post-metadata">

**Author:** ![steveklabnik](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/steveklabnik/32/4524_2.png) [@steveklabnik](https://internals.rust-lang.org/u/steveklabnik)\
**Post date:** [April 27, 2018, 9:01pm UTC](https://internals.rust-lang.org/t/idea-mark-code-as-known-dead-to-silence-dead-code-lint/7409/8 "2018-04-27T21:01:21Z")

</div>

> [@nikomatsakis](#):
>
> #[allow(dead\_code)] isn’t quite right, because it tends to just hang out long after you’ve added the consumer (since you forget it’s there).

Some testing frameworks have an analogous concept; you mark a test as "pending", and then when it fails, it tells the runner it's passed. When it succeeds, however, it fails, alerting you that you thought this wasn't done yet, but it does actually work.

---

<div class="post-metadata">

**Author:** ![kornel](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kornel/32/2711_2.png) [@kornel](https://internals.rust-lang.org/u/kornel)\
**Post date:** [April 28, 2018, 1:30am UTC](https://internals.rust-lang.org/t/idea-mark-code-as-known-dead-to-silence-dead-code-lint/7409/9 "2018-04-28T01:30:38Z")

</div>

The `expect()` idea sounds nice.

But for the specific problem of compiler being annoying about _unfinished_ code, I use this:

```rust
#![cfg_attr(debug_assertions, allow(dead_code, bad_style, unused)]

```

The debug assertions **[hack](https://internals.rust-lang.org/t/pre-rfc-cfg-s-for-debug-profile-related-uses/7282)** is supposed to enable this only while I’m working on it, but still warn me about issues before I release it. I wish there was some smarter logic for unfinished code/not-yet-useful lints.

---

<div class="post-metadata">

**Author:** ![nikomatsakis](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nikomatsakis/32/5410_2.png) [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)\
**Post date:** [March 25, 2019, 8:30am UTC](https://internals.rust-lang.org/t/idea-mark-code-as-known-dead-to-silence-dead-code-lint/7409/10 "2019-03-25T08:30:08Z")

</div>

Closed on March 25, 2019, 8:30am UTC

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
