Refactor #82270 as lint instead of an error

This PR fixes several issues with #82270 which generated an error when `.intel_syntax` or `.att_syntax` was used in inline assembly:
- It is now a warn-by-default lint instead of an error.
- The lint only triggers on x86. `.intel_syntax` and `.att_syntax` are only valid on x86.
- The lint no longer provides machine-applicable suggestions for two reasons:
	- These changes should not be made automatically since changes to assembly code can be very subtle.
	- The template string is not always just a string: it can contain macro invocation (`concat!`), raw strings, escape characters, etc.

cc ``@asquared31415``

[rustdoc] Don't document stripped items in JSON renderer.

Fixes #80664, see [my comment there](https://github.com/rust-lang/rust/issues/80664#issuecomment-797557948) for why

Note that we already do something similar in `convert_item`:

https://github.com/rust-lang/rust/blob/bb4cdf8ec034dca5c056ec9295f38062e5b7e871/src/librustdoc/json/conversions.rs#L28-L31

``@rustbot`` modify labels: +T-rustdoc +A-rustdoc-json

r? ``@jyn514``
cc ``@CraftSpider``

Rework rustdoc const type

This PR is mostly about two things:
 1. Not storing some information in the `clean::Constant` type
 2. Using `TyCtxt` in the formatting (which we will need in any case as we move forward in any case).

Also: I'm very curious of the perf change in here.

Thanks a lot `@danielhenrymantilla` for your `Captures` idea! It allowed me to solve the lifetime issue completely. :)

r? `@jyn514`

Refactor rustc_resolve::late::lifetimes to resolve per-item

There are some changes to tests that I'd like some feedback on; so this is still WIP.

The reason behind this change will (hopefully) allow us to (as part of #76814) be able to essentially use the lifetime resolve code to resolve *all* late bound vars (including those of super traits). Currently, it only resolves those that are *syntactically* in scope. In #76814, I'm essentially finding that I would essentially have to redo the passing of bound vars through scopes (i.e. when instantiating a poly trait ref), and that's what this code does anyways. However, to be able to do this (ask super traits what bound vars are in scope), we have to be able to resolve items separately.

The first commit is actually partially orthogonal. Essentially removing one use of late bound debruijn indices.

Not exactly sure who would be best to review here.
Let r? `@nikomatsakis`

GenericParam does not need to be a HIR owner.

The special case is not required.

Universal impl traits design to regular generic parameters, and their content is owned by the enclosing item.

Existential (and opaque) impl traits generate their own enclosing item, and are collected through it.

Update the minimum external LLVM to 10

r? `@nikic`

Revert reverting of stabilizing integer::BITS.

Now that `lexical-core` has an updated version that won't break with this stabilization, let's try to stabilize this again.

See https://github.com/rust-lang/rust/issues/81654#issuecomment-778564715

Tracking issue with FCP: https://github.com/rust-lang/rust/issues/76904

RemoveZsts: don't touch unions

This should fix a Miri ICE

r? `@RalfJung`

coverage bug fixes and optimization support

Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to
address multiple, somewhat related issues.

Fixed a significant flaw in prior coverage solution: Every counter
generated a new counter variable, but there should have only been one
counter variable per function. This appears to have bloated .profraw
files significantly. (For a small program, it increased the size by
about 40%. I have not tested large programs, but there is anecdotal
evidence that profraw files were way too large. This is a good fix,
regardless, but hopefully it also addresses related issues.

Fixes: #82144

Invalid LLVM coverage data produced when compiled with -C opt-level=1

Existing tests now work up to at least `opt-level=3`. This required a
detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR
when compiled with coverage, and a lot of trial and error with codegen
adjustments.

The biggest hurdle was figuring out how to continue to support coverage
results for unused functions and generics. Rust's coverage results have
three advantages over Clang's coverage results:

1. Rust's coverage map does not include any overlapping code regions,
   making coverage counting unambiguous.
2. Rust generates coverage results (showing zero counts) for all unused
   functions, including generics. (Clang does not generate coverage for
   uninstantiated template functions.)
3. Rust's unused functions produce minimal stubbed functions in LLVM IR,
   sufficient for including in the coverage results; while Clang must
   generate the complete LLVM IR for each unused function, even though
   it will never be called.

This PR removes the previous hack of attempting to inject coverage into
some other existing function instance, and generates dedicated instances
for each unused function. This change, and a few other adjustments
(similar to what is required for `-C link-dead-code`, but with lower
impact), makes it possible to support LLVM optimizations.

Fixes: #79651

Coverage report: "Unexecuted instantiation:..." for a generic function
from multiple crates

Fixed by removing the aforementioned hack. Some "Unexecuted
instantiation" notices are unavoidable, as explained in the
`used_crate.rs` test, but `-Zinstrument-coverage` has new options to
back off support for either unused generics, or all unused functions,
which avoids the notice, at the cost of less coverage of unused
functions.

Fixes: #82875

Invalid LLVM coverage data produced with crate brotli_decompressor

Fixed by disabling the LLVM function attribute that forces inlining, if
`-Z instrument-coverage` is enabled. This attribute is applied to
Rust functions with `#[inline(always)], and in some cases, the forced
inlining breaks coverage instrumentation and reports.

FYI: `@wesleywiser`

r? `@tmandry`

Rollup of 8 pull requests

Successful merges:

 - #83041 (stabilize debug_non_exhaustive)
 - #83349 (Remove Option::{unwrap_none, expect_none}.)
 - #83420 (Add documentation for rustdoc-gui tests)
 - #83421 (Add Result::into_err where the Ok variant is the never type)
 - #83427 (small cleanups in rustc_errors / emitter)
 - #83434 (Update RELEASES.md)
 - #83440 (Use intra-doc link in core::cell)
 - #83442 (LLVMWrapper: attractive nuisance macros)

Failed merges:

 - #83438 (Update RELEASES.md)

r? `@ghost`
`@rustbot` modify labels: rollup

LLVMWrapper: attractive nuisance macros

This came up in the review of #83425: it's hard to imagine a use of
LLVM_VERSION_LE() or LLVM_VERSION_EQ() that's not asking for trouble
when a point release gets created, so let's just discard them to prevent
the issue.

Use intra-doc link in core::cell

``@rustbot`` label T-doc A-intra-doc-links

r? ``@jyn514``

Update RELEASES.md

This change was backed out in #83412 so we should remove the reference
to it from the release notes.

small cleanups in rustc_errors / emitter

This is either moving code around so it gets called less often or using if let instead of match in a few cases.

Add Result::into_err where the Ok variant is the never type

Equivalent of #66045 but for the inverse situation where `T: Into<!>` rather than `E: Into<!>`.

I'm using the same feature gate name. I can't see why one of these methods would be OK to stabilize but not the other.

Tracking issue: #61695

Add documentation for rustdoc-gui tests

I think a bit of documentation doesn't hurt in this case considering how "out of the ordinary" this is.

r? ``@jyn514``

Remove Option::{unwrap_none, expect_none}.

This removes `Option::unwrap_none` and `Option::expect_none` since we're not going to stabilize them, see https://github.com/rust-lang/rust/issues/62633.

Closes #62633

stabilize debug_non_exhaustive

tracking issue: https://github.com/rust-lang/rust/issues/67364

but it is still an open question whether the other `Debug*` struct's should have a similar method. I would guess that would best be put underneath a new feature gate, as this one seems uncontroversial enough to stabilize as is

Use `EvaluatedToOkModuloRegions` whenever we erase regions

Fixes #80691

When we evaluate a trait predicate, we convert an
`EvaluatedToOk` result to `EvaluatedToOkModuloRegions` if we erased any
regions. We cache the result under a region-erased 'freshened'
predicate, so `EvaluatedToOk` may not be correct for other predicates
that have the same cache key.

This reverts commit 22ae20733515d710c1134600bc1e29cdd76f6b9b.

Fixes #80691

When we evaluate a trait predicate, we convert an
`EvaluatedToOk` result to `EvaluatedToOkModuloRegions` if we erased any
regions. We cache the result under a region-erased 'freshened'
predicate, so `EvaluatedToOk` may not be correct for other predicates
that have the same cache key.

Caused by
https://github.com/rust-lang/rust/commit/b0659f9b1bfb92626c40dabceb3268f88bb26224#diff-ede26372490522288745c5b3df2b6b2a1cc913dcd09b29af3a49935afe00c7e6L464-R464

THis came up in the review of #83425: it's hard to imagine a use of
LLVM_VERSION_LE() or LLVM_VERSION_EQ() that's not asking for trouble
when a point release gets created, so let's just discard them to prevent
the issue.

Closes #80664

2229 migration: Don't try resolve regions before writeback

In the analysis use `resolve_vars_if_possible` instead of `fully_resolve`,
because we might not have performed regionck yet.

Fixes: #83176

r? `@nikomatsakis`