Slew of builtin-attribute gating tests

[pnkfelix]

Slew of builtin-attribute "gating" tests for issue #43106.

Some stray observations:

• I don't know if its a good thing that so many attributes allow inputs which are silently discarded. (I made heavy use of that in writing my tests, but that was more out of curiosity than necessity.)
• The difference between crate-level and non-crate-level behavior is quite significant in some cases. Definitely worth making sure one has tests for both cases. (Not as clear whether it was worthwhile trying the various other AST forms like fn f() vs struct S;)
• #[no_builtins] and #[no_mangle] occur twice on the BUILTIN_ATTRIBUTES list. Thats almost certainly a bug. (Filed as #![no_builtins] attribute occurs twice on BUILTIN_ATTRIBUTES list #43148)
• We are maximally liberal in what we allow for #[test] and #[bench] when one compiles without --test.
• We allow #[no_mangle] on arbitrary AST nodes, but only warn about potential misuse on fn
• We allow #[cold], #[must_use], #[windows_subsystem], and #[no_builtins] on arbitrary AST nodes. I don't know off-hand what the semantics are for e.g. a #[cold] type T = ...;
• We allow crate-level #![inline]. That's probably a bug since its otherwise restricted to fn items

[rust-highfive]

r? @aturon

(rust_highfive has picked a reviewer for you, use r? to override)

[pnkfelix]

Oh, and just in case there's any debate about what the "point" is of these tests, this comment from issue-43106-gating-of-builtin-attrs.rs is probably worth quoting explicitly:

This test enumerates as many compiler-builtin ungated attributes as possible (that is, all the mutually compatible ones), and checks that we get "expected" (*) warnings for each in the various weird places that users might put them in the syntax.

(*): The word "expected" is in quotes above because the cases where warnings are and are not emitted might not match a user's intuition nor the rustc developers' intent. I am really just trying to capture today's behavior in a test, not so that it become enshrined as the absolute behavior going forward, but rather so that we do not change the behavior in the future without even being aware of the change when it happens.

[Mark-Simulacrum]

@aturon Looks like this is waiting on a review from you. Also pinged on IRC.

[aturon]

@bors: r+

[bors]

📌 Commit 39b8aaf has been approved by aturon

[bors]

⌛ Testing commit 39b8aaf with merge 16068c512dcfc0dea5290f625b93b1da49702b61...

[bors]

💔 Test failed - status-travis

[est31]

@bors retry

[bors]

⌛ Testing commit 39b8aaf with merge cbbf509e94e1b24a3c4026963544918a85f8e03c...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: aturon
Pushing cbbf509e94e1b24a3c4026963544918a85f8e03c to master...

[bors]

👀 Test was successful, but fast-forwarding failed: 422 Update is not a fast forward

[Mark-Simulacrum]

@bors retry

[bors]

⌛ Testing commit 39b8aaf with merge 88e2c39...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: aturon
Pushing 88e2c39 to master...