Change a few rule names

These are some misc rule name changes. Some of them are to give the
rules more specific names (indicating what they do, instead of using
generic terms).

The `allowed-positions` name is intended to be used for all attributes
to have a specific rule that defines where an attribute may be used. It
is not consistently used, yet. Also, some of the paragraphs mix "where
it goes" with "what it does" that should probably be teased apart so
that we can label those independently.

I expect us to do some more cleanup to bring some consistency to the
attribute rules since there are a lot of attributes, and they generally
have the same requirements of what needs to be specified.

Author: ehuss

src/attributes.md

@@ -54,7 +54,7 @@ Attributes can be classified into the following kinds:
 * [Derive macro helper attributes]
 * [Tool attributes](#tool-attributes)
 
-r[attributes.application]
+r[attributes.allowed-position]
 Attributes may be applied to many things in the language:
 
 * All [item declarations] accept outer attributes while [external blocks],

src/attributes/codegen.md

@@ -80,7 +80,7 @@ Each [target architecture] has a set of features that may be enabled. It is an
 error to specify a feature for a target architecture that the crate is not
 being compiled for.
 
-r[attributes.codegen.target_feature.precondition]
+r[attributes.codegen.target_feature.target-ub]
 It is [undefined behavior] to call a function that is compiled with a feature
 that is not supported on the current platform the code is running on, *except*
 if the platform explicitly documents this to be safe.
@@ -344,7 +344,7 @@ in the standard library for runtime feature detection on these platforms.
 
 r[attributes.codegen.track_caller]
 
-r[attributes.codegen.track_caller.restriction]
+r[attributes.codegen.track_caller.allowed-positions]
 The `track_caller` attribute may be applied to any function with [`"Rust"` ABI][rust-abi]
 with the exception of the entry point `fn main`.
 
@@ -478,7 +478,7 @@ trait object whose methods are attributed.
 
 r[attributes.codegen.instruction_set]
 
-r[attributes.codegen.instruction_set.restriction]
+r[attributes.codegen.instruction_set.allowed-positions]
 The *`instruction_set` [attribute]* may be applied to a function to control which instruction set the function will be generated for.
 
 r[attributes.codegen.instruction_set.behavior]

src/attributes/diagnostics.md

@@ -326,7 +326,7 @@ The `deprecated` attribute has several forms:
     message. This is typically used to provide an explanation about the
     deprecation and preferred alternatives.
 
-r[attributes.diagnostic.deprecated.application]
+r[attributes.diagnostic.deprecated.allowed-positions]
 The `deprecated` attribute may be applied to any [item], [trait item], [enum
 variant], [struct field], [external block item], or [macro definition]. It
 cannot be applied to [trait implementation items]. When applied to an item
@@ -354,13 +354,16 @@ The [RFC][1270-deprecation.md] contains motivations and more details.
 
 r[attributes.diagnostic.must_use]
 
-r[attributes.diagnostic.must_use.application]
+r[attributes.diagnostic.must_use.intro]
 The *`must_use` attribute* is used to issue a diagnostic warning when a value
-is not "used". It can be applied to user-defined composite types
+is not "used".
+
+r[attributes.diagnostic.must_use.allowed-positions]
+The `must_use` attribute can be applied to user-defined composite types
 ([`struct`s][struct], [`enum`s][enum], and [`union`s][union]), [functions],
 and [traits].
 
-r[attributes.diagnostic.must_use.syntax]
+r[attributes.diagnostic.must_use.message]
 The `must_use` attribute may include a message by using the
 [_MetaNameValueStr_] syntax such as `#[must_use = "example message"]`. The
 message will be given alongside the warning.
@@ -486,7 +489,7 @@ r[attributes.diagnostic.on_unimplemented]
 r[attributes.diagnostic.on_unimplemented.intro]
 The `#[diagnostic::on_unimplemented]` attribute is a hint to the compiler to supplement the error message that would normally be generated in scenarios where a trait is required but not implemented on a type.
 
-r[attributes.diagnostic.on_unimplemented.application]
+r[attributes.diagnostic.on_unimplemented.allowed-positions]
 The attribute should be placed on a [trait declaration], though it is not an error to be located in other positions.
 
 r[attributes.diagnostic.on_unimplemented.syntax]

src/attributes/limits.md

@@ -8,7 +8,7 @@ The following [attributes] affect compile-time limits.
 
 r[attributes.limits.recursion_limit]
 
-r[attributes.limits.recursion_limit.application]
+r[attributes.limits.recursion_limit.intro]
 The *`recursion_limit` attribute* may be applied at the [crate] level to set the
 maximum depth for potentially infinitely-recursive compile-time operations
 like macro expansion or auto-dereference.

src/attributes/testing.md

@@ -17,7 +17,7 @@ The *`test` attribute* marks a function to be executed as a test.
 r[attributes.testing.test.enabled]
 These functions are only compiled when in test mode.
 
-r[attributes.testing.test.target]
+r[attributes.testing.test.allowed-positions]
 Test functions must be free, monomorphic functions that take no arguments, and the return type must implement the [`Termination`] trait, for example:
 
 * `()`
@@ -78,7 +78,7 @@ fn mytest() {
 
 r[attributes.testing.should_panic]
 
-r[attributes.testing.should_panic.target]
+r[attributes.testing.should_panic.intro]
 A function annotated with the `test` attribute that returns `()` can also be
 annotated with the `should_panic` attribute.
 

src/attributes/type_system.md

@@ -12,7 +12,7 @@ r[attributes.type-system.non_exhaustive.intro]
 The *`non_exhaustive` attribute* indicates that a type or variant may have
 more fields or variants added in the future.
 
-r[attributes.type-system.non_exhaustive.application]
+r[attributes.type-system.non_exhaustive.allowed-positions]
 It can be applied to [`struct`s][struct], [`enum`s][enum], and `enum` variants.
 
 r[attributes.type-system.non_exhaustive.syntax]