Add underscore expressions for destructuring assignments

Co-authored-by: varkor <github@varkor.com>

Rollup merge of #78836 - fanzier:struct-and-slice-destructuring, r=petrochenkov

Implement destructuring assignment for structs and slices

This is the second step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909, tracking issue: #71126). This PR is the second part of #71156, which was split up to allow for easier review.

Note that the first PR (#78748) is not merged yet, so it is included as the first commit in this one. I thought this would allow the review to start earlier because I have some time this weekend to respond to reviews. If ``@petrochenkov`` prefers to wait until the first PR is merged, I totally understand, of course.

This PR implements destructuring assignment for (tuple) structs and slices. In order to do this, the following *parser change* was necessary: struct expressions are not required to have a base expression, i.e. `Struct { a: 1, .. }` becomes legal (in order to act like a struct pattern).

Unfortunately, this PR slightly regresses the diagnostics implemented in #77283. However, it is only a missing help message in `src/test/ui/issues/issue-77218.rs`. Other instances of this diagnostic are not affected. Since I don't exactly understand how this help message works and how to fix it yet, I was hoping it's OK to regress this temporarily and fix it in a follow-up PR.

Thanks to ``@varkor`` who helped with the implementation, particularly around the struct rest changes.

r? ``@petrochenkov``

Auto merge of #78782 - petrochenkov:nodoctok, r=Aaron1011

Do not collect tokens for doc comments

Doc comment is a single token and AST has all the information to re-create it precisely.
Doc comments are also responsible for majority of calls to `collect_tokens` (with `num_calls == 1` and `num_calls == 0`, cc https://github.com/rust-lang/rust/pull/78736).

(I also moved token collection into `fn parse_attribute` to deduplicate code a bit.)

r? `@Aaron1011`

Implement destructuring assignment for structs and slices

Co-authored-by: varkor <github@varkor.com>

Fix typo in comment

occurences -> occurrences

Rollup merge of #78710 - petrochenkov:macvisit, r=davidtwco

rustc_ast: Do not panic by default when visiting macro calls

Panicking by default made sense when we didn't have HIR or MIR and everything worked on AST, but now all AST visitors run early and majority of them have to deal with macro calls, often by ignoring them.

The second commit renames `visit_mac` to `visit_mac_call`, the corresponding structures were renamed earlier in https://github.com/rust-lang/rust/pull/69589.

Do not collect tokens for doc comments

Merge commit 'b20d4c155d2fe3a8391f86dcf9a8c49e17188703' into clippyup

Auto merge of #78662 - sexxi-goose:add_expr_id_to_delegate, r=nikomatsakis

Provide diagnostic suggestion in ExprUseVisitor Delegate

The [Delegate trait](https://github.com/rust-lang/rust/blob/981346fc07dd5ef414c5b1b21999f7604cece006/compiler/rustc_typeck/src/expr_use_visitor.rs#L28-L38) currently use `PlaceWithHirId` which is composed of Hir `Place` and the
corresponding expression id.

Even though this is an accurate way of expressing how a Place is used,
it can cause confusion during diagnostics.

Eg:

```
let arr : [String; 5];

let [a, ...]     =   arr;
 ^^^ E1 ^^^      =  ^^E2^^
 ```

 Here `arr` is moved because of the binding created E1. However, when we
 point to E1 in diagnostics with the message `arr` was moved, it can be
 confusing.  Rather we would like to report E2 to the user.

Closes: https://github.com/rust-lang/project-rfc-2229/issues/20
r? `@ghost`

s/Scalar::Raw/Scalar::Int

Split the "raw integer bytes" part out of `Scalar`

rustc_ast: `visit_mac` -> `visit_mac_call`

rustc_ast: Do not panic by default when visiting macro calls

Provide diagnostic suggestion in ExprUseVisitor Delegate

The [Delegate
trait](https://github.com/rust-lang/rust/blob/981346fc07dd5ef414c5b1b21999f7604cece006/compiler/rustc_typeck/src/expr_use_visitor.rs#L28-L38)
currently use `PlaceWithHirId` which is composed of Hir `Place` and the
corresponding expression id.

Even though this is an accurate way of expressing how a Place is used,
it can cause confusion during diagnostics.

Eg:

```
let arr : [String; 5];

let [a, ...]     =   arr;
 ^^^ E1 ^^^      =  ^^E2^^
 ```

 Here `arr` is moved because of the binding created E1. However, when we
 point to E1 in diagnostics with the message `arr` was moved, it can be
 confusing.  Rather we would like to report E2 to the user.

Closes: https://github.com/rust-lang/project-rfc-2229/issues/20

Auto merge of #75534 - Aaron1011:feature/new-future-breakage, r=pnkfelix

Implement rustc side of report-future-incompat

cc https://github.com/rust-lang/rust/issues/71249

This is an alternative to `@pnkfelix's` initial implementation in https://github.com/pnkfelix/rust/commits/prototype-rustc-side-of-report-future-incompat (mainly because I started working before seeing that branch :smile: ).

My approach outputs the entire original `Diagnostic`, in a way that is compatible with incremental compilation. This is not yet integrated with compiletest, but can be used manually by passing `-Z emit-future-incompat-report` to `rustc`.

Several changes are made to support this feature:
* The `librustc_session/lint` module is moved to a new crate `librustc_lint_defs` (name bikesheddable). This allows accessing lint definitions from `librustc_errors`.
* The `Lint` struct is extended with an `Option<FutureBreakage>`. When present, it indicates that we should display a lint in the future-compat report. `FutureBreakage` contains additional information that we may want to display in the report (currently, a `date` field indicating when the crate will stop compiling).
* A new variant `rustc_error::Level::Allow` is added. This is used when constructing a diagnostic for a future-breakage lint that is marked as allowed (via `#[allow]` or `--cap-lints`). This allows us to capture any future-breakage diagnostics in one place, while still discarding them before they are passed to the `Emitter`.
* `DiagnosticId::Lint` is extended with a `has_future_breakage` field, indicating whether or not the `Lint` has future breakage information (and should therefore show up in the report).
* `Session` is given access to the `LintStore` via a new `SessionLintStore` trait (since `librustc_session` cannot directly reference `LintStore` without a cyclic dependency). We use this to turn a string `DiagnosticId::Lint` back into a `Lint`, to retrieve the `FutureBreakage` data.

Currently, `FutureBreakage.date` is always set to `None`. However, this could potentially be interpreted by Cargo in the future.

I've enabled the future-breakage report for the `ARRAY_INTO_ITER` lint, which can be used to test out this PR. The intent is to use the field to allow Cargo to determine the date of future breakage (as described in [RFC 2834](https://github.com/rust-lang/rfcs/blob/master/text/2834-cargo-report-future-incompat.md)) without needing to parse the diagnostic itself.

cc `@pnkfelix`

Update Clippy path to `Lint`

Remove implicit `Continue` type

Use `ControlFlow::is{break,continue}`

TypeVisitor: use `ControlFlow` in clippy

Merge commit '645ef505da378b6f810b1567806d1bcc2856395f' into clippyup

Remove lint from clippy

Rollup merge of #78326 - Aaron1011:fix/min-stmt-lints, r=petrochenkov

Split out statement attributes changes from #78306

This is the same as PR https://github.com/rust-lang/rust/pull/78306, but `unused_doc_comments` is modified to explicitly ignore statement items (which preserves the current behavior).

This shouldn't have any user-visible effects, so it can be landed without lang team discussion.

---------
When the 'early' and 'late' visitors visit an attribute target, they
activate any lint attributes (e.g. `#[allow]`) that apply to it.
This can affect warnings emitted on sibiling attributes. For example,
the following code does not produce an `unused_attributes` for
`#[inline]`, since the sibiling `#[allow(unused_attributes)]` suppressed
the warning.

```rust
trait Foo {
    #[allow(unused_attributes)] #[inline] fn first();
    #[inline] #[allow(unused_attributes)] fn second();
}
```

However, we do not do this for statements - instead, the lint attributes
only become active when we visit the struct nested inside `StmtKind`
(e.g. `Item`).

Currently, this is difficult to observe due to another issue - the
`HasAttrs` impl for `StmtKind` ignores attributes for `StmtKind::Item`.
As a result, the `unused_doc_comments` lint will never see attributes on
item statements.

This commit makes two interrelated fixes to the handling of inert
(non-proc-macro) attributes on statements:

* The `HasAttr` impl for `StmtKind` now returns attributes for
  `StmtKind::Item`, treating it just like every other `StmtKind`
  variant. The only place relying on the old behavior was macro
  which has been updated to explicitly ignore attributes on item
  statements. This allows the `unused_doc_comments` lint to fire for
  item statements.
* The `early` and `late` lint visitors now activate lint attributes when
  invoking the callback for `Stmt`. This ensures that a lint
  attribute (e.g. `#[allow(unused_doc_comments)]`) can be applied to
  sibiling attributes on an item statement.

For now, the `unused_doc_comments` lint is explicitly disabled on item
statements, which preserves the current behavior. The exact locatiosn
where this lint should fire are being discussed in PR #78306

Fix inconsistencies in handling of inert attributes on statements

When the 'early' and 'late' visitors visit an attribute target, they
activate any lint attributes (e.g. `#[allow]`) that apply to it.
This can affect warnings emitted on sibiling attributes. For example,
the following code does not produce an `unused_attributes` for
`#[inline]`, since the sibiling `#[allow(unused_attributes)]` suppressed
the warning.

```rust
trait Foo {
    #[allow(unused_attributes)] #[inline] fn first();
    #[inline] #[allow(unused_attributes)] fn second();
}
```

However, we do not do this for statements - instead, the lint attributes
only become active when we visit the struct nested inside `StmtKind`
(e.g. `Item`).

Currently, this is difficult to observe due to another issue - the
`HasAttrs` impl for `StmtKind` ignores attributes for `StmtKind::Item`.
As a result, the `unused_doc_comments` lint will never see attributes on
item statements.

This commit makes two interrelated fixes to the handling of inert
(non-proc-macro) attributes on statements:

* The `HasAttr` impl for `StmtKind` now returns attributes for
  `StmtKind::Item`, treating it just like every other `StmtKind`
  variant. The only place relying on the old behavior was macro
  which has been updated to explicitly ignore attributes on item
  statements. This allows the `unused_doc_comments` lint to fire for
  item statements.
* The `early` and `late` lint visitors now activate lint attributes when
  invoking the callback for `Stmt`. This ensures that a lint
  attribute (e.g. `#[allow(unused_doc_comments)]`) can be applied to
  sibiling attributes on an item statement.

For now, the `unused_doc_comments` lint is explicitly disabled on item
statements, which preserves the current behavior. The exact locatiosn
where this lint should fire are being discussed in PR #78306

Remove duplicate import of `Target`

Merge commit 'bf1c6f9871f430e284b17aa44059e0d0395e28a6' into clippyup

Fix clippy tests

Rollup merge of #77851 - exrook:split-btreemap, r=dtolnay

BTreeMap: refactor Entry out of map.rs into its own file

btree/map.rs is approaching the 3000 line mark, splitting out the entry
code buys about 500 lines of headroom.

I've created this PR because the changes I've made in #77438 will push `map.rs` over the 3000 line limit and cause tidy to complain.

I picked `Entry` to factor out because it feels less tightly coupled to the rest of `BTreeMap` than the various iterator implementations.

Related: #60302

Appease the almightly lord clippy, hallowed be thy name

Handle ExprKind::ConstBlock on clippy

Rollup merge of #77493 - hosseind88:ICEs_should_always_print_the_top_of_the_query_stack, r=oli-obk

ICEs should always print the top of the query stack

see #76920

Remove rustc_session::config::Config

The wrapper type led to tons of target.target
across the compiler. Its ptr_width field isn't
required any more, as target_pointer_width
is already present in parsed form.

fix stderr file of clippy/custom_ice_message test

Auto merge of #77796 - jonas-schievink:switchint-refactor, r=oli-obk

Refactor how SwitchInt stores jump targets

Closes https://github.com/rust-lang/rust/issues/65693

Auto merge of #77649 - dash2507:replace_run_compiler, r=matthewjasper

Replace run_compiler with RunCompiler builder pattern

Fixes #77286. Replaces rustc_driver:run_compiler with RunCompiler builder pattern.

Refactor how SwitchInt stores jump targets

rebase with master

add new line

fix clippy custom_ice_message test

run full query stack print just when RUST_BACKTRACE is set

ICEs should print the top of the query stack

Merge commit '2f6439ae6a6803d030cceb3ee14c9150e91b328b' into clippyup

Replace run_compiler with RunCompiler builder pattern.
RunCompiler::new takes non-optional params, and optional
params can be set using set_*field_name* method.
finally `run` will forward all fields to `run_compiler`.

Fix tools

Rollup merge of #77560 - rschoon:fix-litkind-rc-bytebuf, r=lcnr

Fix LitKind's byte buffer to use refcounted slice

While working on adding a new lint for clippy (see https://github.com/rust-lang/rust-clippy/pull/6044) for avoiding shared ownership of "mutable buffer" types (such as using `Rc<Vec<T>>` instead of `Rc<[T]>`), I noticed a type exported from rustc_ast and used by clippy gets caught by the lint. This PR fixes the exported type.

This PR includes the actual change to clippy too, but I will open a PR directly against clippy for that part (although it will currently fail to build there).

Rollup merge of #77534 - Mark-Simulacrum:issue-70819-disallow-override-forbid-in-same-scope, r=petrochenkov

Disallow overriding forbid in same scope

Rebased #73379.

Fixes #70819.

clippy: `(Body, DefId)` -> `Body`

Change clippy's Constant back to refcount clone byte strings

Prevent forbid from being ignored if overriden at the same level.

That is, this changes `#[forbid(foo)] #[allow(foo)]` from allowing foo to
forbidding foo.

Deprecate clippy lint

Rollup merge of #76474 - bjorn3:driver_selected_codegen, r=oli-obk

Add option to pass a custom codegen backend from a driver

This allows the driver to pass information to the codegen backend. For example the headcrab debugger may in the future want to use cg_clif to JIT code to be injected in the debuggee. This would PR make it possible to tell cg_clif which symbol can be found at which address and to tell it to inject the JITed code into the right process.

This PR may also help with https://github.com/rust-lang/miri/pull/1540 by allowing miri to provide a codegen backend that only emits metadata and doesn't perform any codegen.

cc @nbaksalyar (headcrab)
cc @RalfJung (miri)

Add option to pass a custom codegen backend from a driver

Remove all unstable feature support in the `missing_const_for_fn` lint

Move `qualify_min_const_fn` out of rustc into clippy

Auto merge of #77144 - flip1995:clippyup, r=Manishearth

Update Clippy

Bi-weekly Clippy update.

This includes a `Cargo.lock` update (d445493479711389f4dea3a0f433041077ba2088), so probably needs `rollup=never`.

r? `@Manishearth`

Rollup merge of #76724 - ecstatic-morse:dataflow-pass-names, r=lcnr

Allow a unique name to be assigned to dataflow graphviz output

Previously, if the same analysis were invoked multiple times in a single compilation session, the graphviz output for later runs would overwrite that of previous runs. Allow callers to add a unique identifier to each run so this can be avoided.

Merge commit 'e636b88aa180e8cab9e28802aac90adbc984234d' into clippyup

Remove `can_suggest` from Clippy.

Removes `can_suggest` from as it is no longer used.
Reverts rust-clippy#5724.

Update Clippy testcases

Update the test `redundant_pattern_matching`: check if `is_some` and `is_none` are suggested within const contexts.

Auto merge of #76136 - CDirkx:const-result, r=dtolnay

Stabilize some Result methods as const

Stabilize the following methods of Result as const:
 - `is_ok`
 - `is_err`
 - `as_ref`

A test is also included, analogous to the test for `const_option`.

These methods are currently const under the unstable feature `const_result` (tracking issue: #67520).
I believe these methods to be eligible for stabilization because of the stabilization of #49146 (Allow if and match in constants) and the trivial implementations, see also: [PR#75463](https://github.com/rust-lang/rust/pull/75463) and [PR#76135](https://github.com/rust-lang/rust/pull/76135).

Note: these methods are the only methods currently under the `const_result` feature, thus this PR results in the removal of the feature.

Related: #76225

Update src/tools/clippy/clippy_lints/src/matches.rs

Co-authored-by: Ralf Jung <post@ralfj.de>

Remove `can_suggest` check for `is_ok` and `is_err`.

`is_ok` and `is_err` are stabilized as const and can thus always be suggested.

Update Clippy testcases

Update the test `redundant_pattern_matching`: check if `is_ok` and `is_err` are suggested within const contexts.
Also removes the `redundant_pattern_matching_const_result` test, as it is no longer needed.

Fix clippy hard-code slice::Iter path

Add pass names to some common dataflow analyses

Auto merge of #75800 - Aaron1011:feature/full-nt-tokens, r=petrochenkov

Attach tokens to all AST types used in `Nonterminal`

We perform token capturing when we have outer attributes (for nonterminals that support attributes - e.g. `Stmt`), or when we parse a `Nonterminal` for a `macro_rules!` argument. The full list of `Nonterminals` affected by this PR is:

* `NtBlock`
* `NtStmt`
* `NtTy`
* `NtMeta`
* `NtPath`
* `NtVis`
* `NtLiteral`

Of these nonterminals, only `NtStmt` and `NtLiteral` (which is actually just an `Expr`), support outer attributes - the rest only ever have token capturing perform when they match a `macro_rules!` argument.

This makes progress towards solving https://github.com/rust-lang/rust/issues/43081 - we now collect tokens for everything that might need them. However, we still need to handle `#[cfg]`, inner attributes, and misc pretty-printing issues (e.g. #75734)

I've separated the changes into (mostly) independent commits, which could be split into individual PRs for each `Nonterminal` variant. The purpose of having them all in one PR is to do a single Crater run for all of them.

Most of the changes in this PR are trivial (adding `tokens: None` everywhere we construct the various AST structs). The significant changes are:

* `ast::Visibility` is changed from `type Visibility = Spanned<VisibilityKind>` to a `struct Visibility { kind, span, tokens }`.
* `maybe_collect_tokens` is made generic, and used for both `ast::Expr` and `ast::Stmt`.
* Some of the statement-parsing functions are refactored so that we can capture the trailing semicolon.
* `Nonterminal` and `Expr` both grew by 8 bytes, as some of the structs which are stored inline (rather than behind a `P`) now have an `Option<TokenStream>` field. Hopefully the performance impact of doing this is negligible.

Fully integrate token collection for additional AST structs

This commit contains miscellaneous changes that don't fit into any of
the other commits in this PR

Merge commit '5034d47f721ff4c3a3ff2aca9ef2ef3e1d067f9f' into clippyup

Auto merge of #75573 - Aaron1011:feature/const-mutation-lint, r=oli-obk

Add CONST_ITEM_MUTATION lint

Fixes #74053
Fixes #55721

This PR adds a new lint `CONST_ITEM_MUTATION`.
Given an item `const FOO: SomeType = ..`, this lint fires on:

* Attempting to write directly to a field (`FOO.field = some_val`) or
  array entry (`FOO.array_field[0] = val`)
* Taking a mutable reference to the `const` item (`&mut FOO`), including
  through an autoderef `FOO.some_mut_self_method()`

The lint message explains that since each use of a constant creates a
new temporary, the original `const` item will not be modified.

Adjust Clippy for CONST_ITEM_MUTATION lint

We no longer lint assignments to const item fields in the
`temporary_assignment` lint, since this is now covered by the
`CONST_ITEM_MUTATION` lint.

Additionally, we `#![allow(const_item_mutation)]` in the
`borrow_interior_mutable_const.rs` test. Clippy UI tests are run with
`-D warnings`, which seems to cause builtin lints to prevent Clippy
lints from running.

Auto merge of #76044 - ecstatic-morse:dataflow-lattice, r=oli-obk

Support dataflow problems on arbitrary lattices

This PR implements last of the proposed extensions I mentioned in the design meeting for the original dataflow refactor. It extends the current dataflow framework to work with arbitrary lattices, not just `BitSet`s. This is a prerequisite for dataflow-enabled MIR const-propagation. Personally, I am skeptical of the usefulness of doing const-propagation pre-monomorphization, since many useful constants only become known after monomorphization (e.g. `size_of::<T>()`) and users have a natural tendency to hand-optimize the rest. It's probably worth exprimenting with, however, and others have shown interest cc `@rust-lang/wg-mir-opt.`

The `Idx` associated type is moved from `AnalysisDomain` to `GenKillAnalysis` and replaced with an associated `Domain` type that must implement `JoinSemiLattice`. Like before, each `Analysis` defines the "bottom value" for its domain, but can no longer override the dataflow join operator. Analyses that want to use set intersection must now use the `lattice::Dual` newtype. `GenKillAnalysis` impls have an additional requirement that `Self::Domain: BorrowMut<BitSet<Self::Idx>>`, which effectively means that they must use `BitSet<Self::Idx>` or `lattice::Dual<BitSet<Self::Idx>>` as their domain.

Most of these changes were mechanical. However, because a `Domain` is no longer always a powerset of some index type, we can no longer use an `IndexVec<BasicBlock, GenKillSet<A::Idx>>>` to store cached block transfer functions. Instead, we use a boxed `dyn Fn` trait object. I discuss a few alternatives to the current approach in a commit message.

The majority of new lines of code are to preserve existing Graphviz diagrams for those unlucky enough to have to debug dataflow analyses. I find these diagrams incredibly useful when things are going wrong and considered regressing them unacceptable, especially the pretty-printing of `MovePathIndex`s, which are used in many dataflow analyses. This required a parallel `fmt` trait used only for printing dataflow domains, as well as a refactoring of the `graphviz` module now that we cannot expect the domain to be a `BitSet`. Some features did have to be removed, such as the gen/kill display mode (which I didn't use but existed to mirror the output of the old dataflow framework) and line wrapping. Since I had to rewrite much of it anyway, I took the opportunity to switch to a `Visitor` for printing dataflow state diffs instead of using cursors, which are error prone for code that must be generic over both forward and backward analyses. As a side-effect of this change, we no longer have quadratic behavior when writing graphviz diagrams for backward dataflow analyses.

r? `@pnkfelix`

ty.flags -> ty.flags()

`ty.kind` -> `ty.kind()` in rustdoc and clippy

Auto merge of #76160 - scileo:format-recovery, r=petrochenkov

Improve recovery on malformed format call

The token following a format expression should be a comma. However, when it is replaced with a similar token (such as a dot), then the corresponding error is emitted, but the token is treated as a comma, and the parsing step continues.

r? @petrochenkov

Improve recovery on malformed format call

If a comma in a format call is replaced with a similar token, then we
emit an error and continue parsing, instead of stopping at this point.

Fix clippy

Update dataflow analyses to use new interface

Merge commit '3d0b0e66afdfaa519d8855b338b35b4605775945' into clippyup

Unbreak the clippy test

Capture tokens for Pat used in macro_rules! argument

This extends PR #73293 to handle patterns (Pat). Unlike expressions,
patterns do not support custom attributes, so we only need to capture
tokens during macro_rules! argument parsing.

Auto merge of #75120 - JulianKnodt:rm_reps, r=oli-obk

rust_ast::ast => rustc_ast

Rework of #71199 which is a rework #70621

Still working on this but just made the PR to track progress

r? @Dylan-DPC

rust_ast::ast => rustc_ast

clippy: support `QPath::LangItem`

This commit updates clippy with the introduction of `QPath::LangItem` so
that it still compiles.

Signed-off-by: David Wood <david@davidtw.co>

merge `as_local_hir_id` with `local_def_id_to_hir_id`

Auto merge of #75405 - flip1995:clippyup, r=Manishearth

Update Clippy

Biweekly Clippy update (2 days late, since I wanted to wait for https://github.com/rust-lang/rust/pull/75098)

r? @Manishearth

Merge commit '09bd400243ed6f7059fedc0c1623aae3792521d6' into clippyup

Rollup merge of #75226 - pnadon:miri-undef-uninit, r=RalfJung

Miri: Renamed "undef" to "uninit"

Renamed remaining references to "undef" to "uninit" when referring to Miri.

Impacted directories are:

- `src/librustc_codegen_llvm/consts.rs`
- `src/librustc_middle/mir/interpret/`
- `src/librustc_middle/ty/print/pretty.rs`
- `src/librustc_mir/`
- `src/tools/clippy/clippy_lints/src/consts.rs`

Upon building Miri based on the new changes it was verified that no changes needed to be made with the Miri project.

Related issue #71193

Rollup merge of #75098 - Ryan1729:clippy-pointer-cast-lint-experiment, r=oli-obk

Clippy pointer cast lint experiment

This PR is an experiment about exposing more parts of `rustc_typeck` for use in `clippy`. In particular, the code that checks where a cast is valid or not was exposed, which necessitated exposing [`FnCtxt`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/check/struct.FnCtxt.html), and figuring out how to create an instance of that type inside `clippy`.

This was prompted by [this clippy issue](https://github.com/rust-lang/rust-clippy/issues/2064).

r? @oli-obk

add allow unused_unsafe and allow dead_code

fix unary minus on usize and unused variable errors in .fixed file

add a test example of where transmutes_expressible_as_ptr_casts should not suggest anything

update stderr for transmutes_expressible_as_ptr_casts

Miri: Renamed "undef" to "uninit"

Renamed remaining references to "undef" to "uninit" when referring to Miri.

Impacted directories are:

- src/librustc_codegen_llvm/consts.rs
- src/librustc_middle/mir/interpret/
- src/librustc_middle/ty/print/pretty.rs
- src/librustc_mir/
- src/tools/clippy/clippy_lints/src/consts.rs

Upon building Miri based on the new changes it was verified that no changes needed to be made with the Miri project.

Related issue #71193

Eliminate the `SessionGlobals` from `librustc_ast`.

By moving `{known,used}_attrs` from `SessionGlobals` to `Session`. This
means they are accessed via the `Session`, rather than via TLS. A few
`Attr` methods and `librustc_ast` functions are now methods of
`Session`.

All of this required passing a `Session` to lots of functions that didn't
already have one. Some of these functions also had arguments removed, because
those arguments could be accessed directly via the `Session` argument.

`contains_feature_attr()` was dead, and is removed.

Some functions were moved from `librustc_ast` elsewhere because they now need
to access `Session`, which isn't available in that crate.
- `entry_point_type()` --> `librustc_builtin_macros`
- `global_allocator_spans()` --> `librustc_metadata`
- `is_proc_macro_attr()` --> `Session`

Auto merge of #74821 - oli-obk:const_eval_read_uninit_fast_path, r=wesleywiser

Check whether locals are too large instead of whether accesses into them are too large

Essentially this stops const prop from attempting to optimize

```rust
let mut x = [0_u8; 5000];
x[42] = 3;
```

I don't expect this to be a perf improvement without #73656 (which is also where the lack of this PR will be a perf regression).

r? @wesleywiser

copy over *.fixed file

Add some comments for magic numbers + Add tests

Fix clippy

Apply suggestions from code review

Co-authored-by: Philipp Krones <hello@philkrones.com>

run clippy_dev fmt

This seemed to overdo it a bit, affecting multiple submodules, and changing a file I didn't touch, so I didn't commit those changes

run clippy_dev update_lints