rename the lint

Author: llogiq

text/0000-todo-overreach.md

@@ -6,7 +6,7 @@
 ## Summary
 [summary]: #summary
 
-The `todo!()` macro is meant as a placeholder, often used to make type check pass while still writing the code. However, since it diverges, all code that comes after it is marked as unreachable. The author proposes changing that to reduce the `unreachable_code` churn, while adding a `todo_macro_uses` lint that can be deactivated while the code is still work in progress and activated before pushing to production. 
+The `todo!()` macro is meant as a placeholder, often used to make type check pass while still writing the code. However, since it diverges, all code that comes after it is marked as unreachable. The author proposes changing that to reduce the `unreachable_code` churn, while adding a `todo_macro_calls` lint that can be deactivated while the code is still work in progress and activated before pushing to production.
 
 ## Motivation
 [motivation]: #motivation
@@ -50,7 +50,7 @@ fn test_external(x: Result<String, std::io::Error>) {
 ## Reference-level explanation
 [reference-level-explanation]: #reference-level-explanation
 
-To implement this, in the `rustc_hir_typeck` crate, there is one check for diverging code. There, we insert a check for a local `todo!()` macro call, and when that check returns `true`, we modify the result to "warned already" so that the code is marked as diverging (and e.g. the rest of type checking works as before), but the `unreachable_code` lint will no longer warn. To compensate for that, we emit the newly added `todo_macro_uses` lint for the expression.
+To implement this, in the `rustc_hir_typeck` crate, there is one check for diverging code. There, we insert a check for a local `todo!()` macro call, and when that check returns `true`, we modify the result to "warned already" so that the code is marked as diverging (and e.g. the rest of type checking works as before), but the `unreachable_code` lint will no longer warn. To compensate for that, we emit the newly added `todo_macro_calls` lint for the expression.
 
 A proof of concept implementation is in [#149543](https://github.com/rust-lang/rust/pull/149543).
 
@@ -66,16 +66,16 @@ A proof of concept implementation is in [#149543](https://github.com/rust-lang/r
 [rationale-and-alternatives]: #rationale-and-alternatives
 
 - We could do nothing. This leaves the users with the problem stated above.
-- We could make `unreachable_code` ignore `todo!()` without adding a `todo_macros_uses` lint. However, people would need to run clippy (or use a search or other such IDE feature) to get rid of their `todo!()` calls. This is deemed suboptimal from a user experience standpoint.
-- We could only add a `todo_macros_uses` lint without omitting the `todo!()` macro from `unreachable_code` warnings. That would allow people to allow the `unreachable_code` lint while fixing up all `todo!()`s and only then fix the other unreachable code. However, again, the user might forget reactivating the `unreachable_code` lint, potentially leaving their code in a subpar state
-- We could make `allow(unreachable_code)` also suppress `todo_macro_uses`. However, this doesn't seem like a logical parent group.
+- We could make `unreachable_code` ignore `todo!()` without adding a `todo_macro_calls` lint. However, people would need to run clippy (or use a search or other such IDE feature) to get rid of their `todo!()` calls. This is deemed suboptimal from a user experience standpoint.
+- We could only add a `todo_macro_calls` lint without omitting the `todo!()` macro from `unreachable_code` warnings. That would allow people to allow the `unreachable_code` lint while fixing up all `todo!()`s and only then fix the other unreachable code. However, again, the user might forget reactivating the `unreachable_code` lint, potentially leaving their code in a subpar state
+- We could make `allow(unreachable_code)` also suppress `todo_macro_calls`. However, this doesn't seem like a logical parent group.
 
 Please note that this is a language proposal only insofar as that a lint (which is technically part of the language) is changed in accordance with a standard library item. It is not possible to do this without compiler support. There may be a way to implement this so that users could write their own `placeholder!()` macros that do not trip up the `unreachable_code` lint, although at this point the author sees no value in that.
 
 ## Prior art
 [prior-art]: #prior-art
 
-In clippy, there is a `todo` lint that would be deprecated as soon as `todo_macro_uses` is available on stable. Also in clippy, we have done a lot of work to reduce low-benefit lint warnings churn over the last years, so this is merely an extension of that work to the compiler.
+In clippy, there is a `todo` lint that would be deprecated as soon as `todo_macro_calls` is available on stable. Also in clippy, we have done a lot of work to reduce low-benefit lint warnings churn over the last years, so this is merely an extension of that work to the compiler.
 
 ## Unresolved questions
 [unresolved-questions]: #unresolved-questions
@@ -85,4 +85,4 @@ none
 ## Future possibilities
 [future-possibilities]: #future-possibilities
 
-There could be a shortcut to disable the `todo_macros_used` lint while working on the code, or e.g. in a rust-analyzer configuration. Also we can document how to deactivate the `todo_macro_uses` lint on `Debug` builds, avoiding lint message churn during development while making sure no `todo!()` call makes it into a release build.
+There could be a shortcut to disable the `todo_macro_calls` lint while working on the code, or e.g. in a rust-analyzer configuration. Also we can document how to deactivate the `todo_macro_calls` lint on `Debug` builds, avoiding lint message churn during development while making sure no `todo!()` call makes it into a release build.