Reorg and update attributes

[ehuss]

• Move "Attributes" out of the "Items" chapter.
• Move each attribute out of attributes.md, scattered to various locations throughout the reference, including a few new dedicated pages. Each attribute gets a dedicated section to make it easier to link to, and enough room to fully document.
• See attributes.md for the consolidated built-in index.
• Document the syntax for the inputs of every built-in attribute.
• Minor updates and additions to various attributes.
• Removed no_start, it is no longer used. Removed when runtime/green threads were removed Finish runtime removal rust#18967.

Things reserved for future PRs:

• Expanding individual attributes. Some are too brief or slightly wrong.
• Documenting the remaining undocumented attributes.
• Finish the "Attributes on" sections to specify where each attribute may be used.

Some of the new locations seem a little awkward or arbitrary, but I couldn't think of better choices. I wanted to open this up to start getting feedback.

This is written assuming rust-lang/rust#58899 will get merged. Also, some attributes are not very strict about validating their inputs (for example, link ignores any unknown field). I documented with what I think they are intended, not what they actually accept.

Closes #534

[Havvy]

😍 😍 😍

@ehuss and I discussed parts of this PR on the Discord. I asked about why some new pages are under attributes.md and others are in the top-level index. @ehuss said he's like feedback on it. I'll give my specific feedback later on in the review. Next up, @ehuss asked if we should have a file system directory for each attributes page and I thought he meant like a listing of all attributes. While writing this, I figured out what he meant and I said I'd prefer one, but others may differ on opinions. After mostly just being confusing with that topic, I went to point out that "compiler attributes" is offly generic and got agreement. If anybody has a better name, let us know. I also said I think crate_name goes with recursion_limit but the actual effects of setting crate_name on the compiled code are not something I know nor does @ehuss. We finished up talking about derive, but that topic is worthy of its own issue.

With that, onto the critique parts of the review.

For the page structure (SUMMARY.md), all pages should go under attributes, or none should. If we don't make an attributes/ directory, each page name should have -attributes in the name. But I'd rather see an attributes directory. Don't do both like expressions and some items do though.

Given the only content for the code generation, testing, and diagnostics pages are attributes, it makes sense to keep them under the attributes page in the listing. The code generation page is especially confusing because we don't actually discuss what code generation happens. Are there plans to put more there? If so, we should open an issue for such a page. Same with testing and diagnostics.

I have no opinion on the attributes redirect JS.

I like making the examples for the syntaxes of attributes into a table. I was initially disliking linking the to the syntactic name for the syntax of each individual attribute, but with the examples of each attribute also being there, I'm okay with it being a bit technical.

I don't want the TODOs to be merged in. File issues for those.

[Centril]

Do you have any method to the ordering of the bullets?

[ehuss]

:) I was wondering if anyone would notice that. The sections are ordered based on how many crates on crates.io use the attributes. It's somewhat arbitrary, and not really intended as a formal ordering (mostly just "important things towards the top"). I liked the idea of grouping them, but alphabetizing the groups didn't seem satisfying. I'm up for any ordering, though.

[Centril]

=P

The sections are ordered based on how many crates on crates.io use the attributes.

This was not a possibility I had considered 😂

I liked the idea of grouping them, but alphabetizing the groups didn't seem satisfying.

Yeah I alphabetized in my head but it felt unsatisfying to me also.

I'm up for any ordering, though.

Cool, let's perhaps file as an issue to consider later?

[ehuss]

I think I got most of Centril's points. I renamed the section with no name to "Limits". Still can't think of anything better.

The main points still not addressed:

• must_use with traits needs an explanation (waiting for clarification on trait objects)
• lint controls should document how they behave with macros. Expand on lints with macro spans. #544

I'll file some issues for some of the todo items soon. (done)

[Centril]

I think perhaps B-unstable is more accurate. Consider linking to it as well?

[Centril]

(The comment below is not relevant for this PR)

@varkor @oli-obk We could reasonably make this do something by having the #[must_use] trigger when the concrete type is known? E.g.

trait A { fn b() -> usize; }

struct C;

impl A for C {
    #[must_use]
    fn b() -> usize { 0 }
}

fn main() {
    C::b();
//  ^--- We know statically that `C::b` references the function
//       on `impl A for C { ... }` and so we may trigger the lint...?
}

Done

[petrochenkov]

test is always active, when not compiling for tests it transforms its input into nothing and disappears itself too.
Also, derive is an active attribute too.