Use local and remapped paths where appropriate

Auto merge of #84401 - crlf0710:impl_main_by_path, r=petrochenkov

Implement RFC 1260 with feature_name `imported_main`.

This is the second extraction part of #84062 plus additional adjustments.
This (mostly) implements RFC 1260.

However there's still one test case failure in the extern crate case. Maybe `LocalDefId` doesn't work here? I'm not sure.

cc https://github.com/rust-lang/rust/issues/28937
r? `@petrochenkov`

Auto merge of #84189 - jyn514:clippy-dev, r=Mark-Simulacrum

Implement `x.py test src/tools/clippy --bless`

- Add clippy_dev to the rust workspace

  Before, it would give an error that it wasn't either included or
  excluded from the workspace:

  ```
  error: current package believes it's in a workspace when it's not:
  current:   /home/joshua/rustc/src/tools/clippy/clippy_dev/Cargo.toml
  workspace: /home/joshua/rustc/Cargo.toml

  this may be fixable by adding `src/tools/clippy/clippy_dev` to the `workspace.members` array of the manifest located at: /home/joshua/rustc/Cargo.toml
  Alternatively, to keep it out of the workspace, add the package to the `workspace.exclude` array, or add an empty `[workspace]` table to the package's manifest.
  ```

- Change clippy's copy of compiletest not to special-case
  rust-lang/rust. Using OUT_DIR confused `clippy_dev` and it couldn't find
  the test outputs. This is one of the reasons why `cargo dev bless` used
  to silently do nothing (the others were that `CARGO_TARGET_DIR` and
  `PROFILE` weren't set appropriately).

- Run clippy_dev on test failure

I tested this by removing a couple lines from a stderr file, and they
were correctly replaced.

- Fix clippy_dev warnings

Rollup merge of #84484 - jyn514:check-tools, r=Mark-Simulacrum

Don't rebuild rustdoc and clippy after checking bootstrap

This works by unconditionally passing -Z unstable-options to the
compiler. This has no affect in practice since bootstrap doesn't use
`deny(rustc::internal)`.

Fixes https://github.com/rust-lang/rust/issues/82461.

r? ```@Mark-Simulacrum```

Implement RFC 1260 with feature_name `imported_main`.

Switch `rustc::internal` from deny to warn

These should still obey deny-warnings.

Implement `x.py test src/tools/clippy --bless`

- Add clippy_dev to the rust workspace

  Before, it would give an error that it wasn't either included or
  excluded from the workspace:

  ```
  error: current package believes it's in a workspace when it's not:
  current:   /home/joshua/rustc/src/tools/clippy/clippy_dev/Cargo.toml
  workspace: /home/joshua/rustc/Cargo.toml

  this may be fixable by adding `src/tools/clippy/clippy_dev` to the `workspace.members` array of the manifest located at: /home/joshua/rustc/Cargo.toml
  Alternatively, to keep it out of the workspace, add the package to the `workspace.exclude` array, or add an empty `[workspace]` table to the package's manifest.
  ```

- Change clippy's copy of compiletest not to special-case
  rust-lang/rust. Using OUT_DIR confused `clippy_dev` and it couldn't find
  the test outputs. This is one of the reasons why `cargo dev bless` used
  to silently do nothing (the others were that `CARGO_TARGET_DIR` and
  `PROFILE` weren't set appropriately).

- Run clippy_dev on test failure

I tested this by removing a couple lines from a stderr file, and they
were correctly replaced.

- Fix clippy_dev warnings

Merge commit '7c7683c8efe447b251d6c5ca6cce51233060f6e8' into clippyup

fix clippy

Merge commit '98e2b9f25b6db4b2680a3d388456d9f95cb28344' into clippyup

fix suggestion for unsized function parameters

Auto merge of #78880 - CDirkx:not_supported, r=joshtriplett

Add `Unsupported` to `std::io::ErrorKind`

I noticed a significant portion of the uses of `ErrorKind::Other` in std is for unsupported operations.
The notion that a specific operation is not available on a target (and will thus never succeed) seems semantically distinct enough from just "an unspecified error occurred", which is why I am proposing to add the variant `Unsupported` to `std::io::ErrorKind`.

**Implementation**:

The following variant will be added to `std::io::ErrorKind`:

```rust
/// This operation is unsupported on this platform.
Unsupported
```
`std::io::ErrorKind::Unsupported` is an error returned when a given operation is not supported on a platform, and will thus never succeed; there is no way for the software to recover. It will be used instead of `Other` where appropriate, e.g. on wasm for file and network operations.

`decode_error_kind` will be updated  to decode operating system errors to `Unsupported`:
- Unix and VxWorks: `libc::ENOSYS`
- Windows: `c::ERROR_CALL_NOT_IMPLEMENTED`
- WASI: `wasi::ERRNO_NOSYS`

**Stability**:
This changes the kind of error returned by some functions on some platforms, which I think is not covered by the stability guarantees of the std? User code could depend on this behavior, expecting `ErrorKind::Other`, however the docs already mention:

> Errors that are `Other` now may move to a different or a new `ErrorKind` variant in the future. It is not recommended to match an error against `Other` and to expect any additional characteristics, e.g., a specific `Error::raw_os_error` return value.

The most recent variant added to `ErrorKind` was `UnexpectedEof` in `1.6.0` (almost 5 years ago), but `ErrorKind` is marked as `#[non_exhaustive]` and the docs warn about exhaustively matching on it, so adding a new variant per se should not be a breaking change.

The variant `Unsupported` itself could be marked as `#[unstable]`, however, because this PR also immediately uses this new variant and changes the errors returned by functions I'm inclined to agree with the others in this thread that the variant should be insta-stabilized.

Fix clippy test using `ErrorKind`

Auto merge of #84064 - hyd-dev:unknown-lints, r=petrochenkov

Do not ignore path segments in the middle in `#[allow]`/`#[warn]`/`#[deny]`/`#[forbid]` attributes

Fixes #83477.

Do not ignore path segments in the middle in `#[allow]`/`#[warn]`/`#[deny]`/`#[forbid]` attributes

Remove #[main] attribute.

Merge commit 'b40ea209e7f14c8193ddfc98143967b6a2f4f5c9' into clippyup

Rollup merge of #83916 - Amanieu:asm_anonconst, r=petrochenkov

Use AnonConst for asm! constants

This replaces the old system which used explicit promotion. See #83169 for more background.

The syntax for `const` operands is still the same as before: `const <expr>`.

Fixes #83169

Because the implementation is heavily based on inline consts, we suffer from the same issues:
- We lose the ability to use expressions derived from generics. See the deleted tests in `src/test/ui/asm/const.rs`.
- We are hitting the same ICEs as inline consts, for example #78174. It is unlikely that we will be able to stabilize this before inline consts are stabilized.

Use AnonConst for asm! constants

Rollup merge of #83820 - petrochenkov:nolinkargs, r=nagisa

Remove attribute `#[link_args]`

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

The attribute could always be replaced with `-C link-arg`, but cargo didn't provide a reasonable way to pass such flags to rustc.
Now cargo supports `cargo:rustc-link-arg*` directives in build scripts (https://doc.rust-lang.org/cargo/reference/unstable.html#extra-link-arg), so this attribute can be removed.

Remove attribute `#[link_args]`

fix clippy error

Track bound vars

Remove hir::CrateItem.

Remove (lots of) dead code

Found with https://github.com/est31/warnalyzer.

Dubious changes:
- Is anyone else using rustc_apfloat? I feel weird completely deleting
  x87 support.
- Maybe some of the dead code in rustc_data_structures, in case someone
  wants to use it in the future?
- Don't change rustc_serialize

  I plan to scrap most of the json module in the near future (see
  https://github.com/rust-lang/compiler-team/issues/418) and fixing the
  tests needed more work than I expected.

TODO: check if any of the comments on the deleted code should be kept.

Rollup merge of #82917 - cuviper:iter-zip, r=m-ou-se

Add function core::iter::zip

This makes it a little easier to `zip` iterators:

```rust
for (x, y) in zip(xs, ys) {}
// vs.
for (x, y) in xs.into_iter().zip(ys) {}
```

You can `zip(&mut xs, &ys)` for the conventional `iter_mut()` and
`iter()`, respectively. This can also support arbitrary nesting, where
it's easier to see the item layout than with arbitrary `zip` chains:

```rust
for ((x, y), z) in zip(zip(xs, ys), zs) {}
for (x, (y, z)) in zip(xs, zip(ys, zs)) {}
// vs.
for ((x, y), z) in xs.into_iter().zip(ys).zip(xz) {}
for (x, (y, z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {}
```

It may also format more nicely, especially when the first iterator is a
longer chain of methods -- for example:

```rust
    iter::zip(
        trait_ref.substs.types().skip(1),
        impl_trait_ref.substs.types().skip(1),
    )
    // vs.
    trait_ref
        .substs
        .types()
        .skip(1)
        .zip(impl_trait_ref.substs.types().skip(1))
```

This replaces the tuple-pair `IntoIterator` in #78204.
There is prior art for the utility of this in [`itertools::zip`].

[`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html

format macro argument parsing fix

When the character next to `{}` is "shifted" (when mapping a byte index
in the format string to span) we should avoid shifting the span end
index, so first map the index of `}` to span, then bump the span,
instead of first mapping the next byte index to a span (which causes
bumping the end span too much).

Regression test added.

Fixes #83344

Use iter::zip in src/tools/clippy/

Merge commit '0e87918536b9833bbc6c683d1f9d51ee2bf03ef1' into clippyup

Add has_default to GenericParamDefKind::Const

This currently creates a field which is always false on GenericParamDefKind for future use when
consts are permitted to have defaults

Update const_generics:default locations

Previously just ignored them, now actually do something about them.

Fix using type check instead of value

Add parsing

This adds all the necessary changes to lower const-generics defaults from parsing.

Change P<Expr> to AnonConst

This matches the arguments passed to instantiations of const generics, and makes it specific to
just anonymous constants.

Attempt to fix lowering bugs

Auto merge of #79278 - mark-i-m:stabilize-or-pattern, r=nikomatsakis

Stabilize or_patterns (RFC 2535, 2530, 2175)

closes #54883

This PR stabilizes the or_patterns feature in Rust 1.53.

This is blocked on the following (in order):
- [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021
- [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705)
    - It looks like we will need to pursue some sort of edition-based transition for `:pat`.
- [x] Nomination and discussion by T-lang
- [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100).
- [ ] An FCP on stabilization

EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177

update `const_eval_resolve`

clippy: stabilize or_patterns lint

hir: Preserve used syntax in `TyKind::TraitObject`

Auto merge of #82122 - bstrie:dep4real, r=dtolnay

Deprecate `intrinsics::drop_in_place` and `collections::Bound`, which accidentally weren't deprecated

Fixes #82080.

I've taken the liberty of updating the `since` values to 1.52, since an unobservable deprecation isn't much of a deprecation (even the detailed release notes never bothered to mention these deprecations).

As mentioned in the issue I'm *pretty* sure that using a type alias for `Bound` is semantically equivalent to the re-export; [the reference implies](https://doc.rust-lang.org/reference/items/type-aliases.html) that type aliases only observably differ from types when used on unit structs or tuple structs, whereas `Bound` is an enum.

Auto merge of #83188 - petrochenkov:field, r=lcnr

ast/hir: Rename field-related structures

I always forget what `ast::Field` and `ast::StructField` mean despite working with AST for long time, so this PR changes the naming to less confusing and more consistent.

- `StructField` -> `FieldDef` ("field definition")
- `Field` -> `ExprField` ("expression field", not "field expression")
- `FieldPat` -> `PatField` ("pattern field", not "field pattern")

Various visiting and other methods working with the fields are renamed correspondingly too.

The second commit reduces the size of `ExprKind` by boxing fields of `ExprKind::Struct` in preparation for https://github.com/rust-lang/rust/pull/80080.

Rollup merge of #83092 - petrochenkov:qspan, r=estebank

More precise spans for HIR paths

`Ty::assoc_item` is lowered to `<Ty>::assoc_item` in HIR, but `Ty` got span from the whole path.
This PR fixes that, and adjusts some diagnostic code that relied on `Ty` having the whole path span.

This is a pre-requisite for https://github.com/rust-lang/rust/pull/82868 (we cannot report suggestions like `Tr::assoc` -> `<dyn Tr>::assoc` with the current imprecise spans).
r? ````@estebank````

Auto merge of #82536 - sexxi-goose:handle-patterns-take-2, r=nikomatsakis

2229: Handle patterns within closures correctly when `capture_disjoint_fields` is enabled

This PR fixes several issues related to handling patterns within closures when `capture_disjoint_fields` is enabled.
1. Matching is always considered a use of the place, even with `_` patterns
2. Compiler ICE when capturing fields in closures through `let` assignments

To do so, we

- Introduced new Fake Reads
- Delayed use of `Place` in favor of `PlaceBuilder`
- Ensured that `PlaceBuilder` can be resolved before attempting to extract `Place` in any of the pattern matching code

Closes rust-lang/project-rfc-2229/issues/27
Closes rust-lang/project-rfc-2229/issues/24
r? `@nikomatsakis`

ast: Reduce size of `ExprKind` by boxing fields of `ExprKind::Struct`

ast/hir: Rename field-related structures

StructField -> FieldDef ("field definition")
Field -> ExprField ("expression field", not "field expression")
FieldPat -> PatField ("pattern field", not "field pattern")

Also rename visiting and other methods working on them.

Update clippy tests

Fix error after rebase

Add comments with examples and tests

Use `rustc_interface::interface::Config::parse_sess_created` in Clippy

Add fake_read() to clippy

Clippy: HACK! Fix bootstrap error

This will be removed in the next sync, once beta is at 1.52. Until then
this hack avoids to put `cfg(bootstrap)` into Clippy.

Merge commit '6ed6f1e6a1a8f414ba7e6d9b8222e7e5a1686e42' into clippyup

Auto merge of #79519 - cjgillot:noattr, r=wesleywiser

Store HIR attributes in a side table

Same idea as #72015 but for attributes.
The objective is to reduce incr-comp invalidations due to modified attributes.
Notably, those due to modified doc comments.

Implementation:
- collect attributes during AST->HIR lowering, in `LocalDefId -> ItemLocalId -> &[Attributes]` nested tables;
- access the attributes through a `hir_owner_attrs` query;
- local refactorings to use this access;
- remove `attrs` from HIR data structures one-by-one.

Change in behaviour:
- the HIR visitor traverses all attributes at once instead of parent-by-parent;
- attribute arrays are sometimes duplicated: for statements and variant constructors;
- as a consequence, attributes are marked as used after unused-attribute lint emission to avoid duplicate lints.

~~Current bug: the lint level is not correctly applied in `std::backtrace_rs`, triggering an unused attribute warning on `#![no_std]`. I welcome suggestions.~~

Deprecate items that accidentally weren't deprecated

Fixes #82080

Remove hir::Expr::attrs.

Remove hir::Item::attrs.

Remove hir::ImplItem::attrs.

Remove hir::TraitItem::attrs.

Remove hir::StructField::attrs.

Remove hir::Variant::attrs.

Remove hir::Arm::attrs.

Remove hir::Crate::attrs.

Remove hir::Local::attrs.

Remove hir::StmtKind::attrs.

Do not store attrs in FnKind.

Simplify clippy author.

Switch to changing cp_non_overlap in tform

It was suggested to lower this in MIR instead of ssa, so do that instead.

Update cranelift

Update match branches

This updates all places where match branches check on StatementKind or UseContext.
This doesn't properly implement them, but adds TODOs where they are, and also adds some best
guesses to what they should be in some cases.

Rollup merge of #82048 - mark-i-m:or-pat-type-ascription, r=petrochenkov

or-patterns: disallow in `let` bindings

~~Blocked on https://github.com/rust-lang/rust/pull/81869~~

Disallows top-level or-patterns before type ascription. We want to reserve this syntactic space for possible future generalized type ascription.

r? ``@petrochenkov``

clippy: fix or-pattern in let binding

Auto merge of #82727 - oli-obk:shrinkmem, r=pnkfelix

Test the effect of shrinking the size of Rvalue by 16 bytes

r? `@ghost`

Rollup merge of #82736 - spastorino:mir-opt-level-perf-changes, r=oli-obk

Bump optimization from mir_opt_level 2 to 3 and 3 to 4 and make "release" be level 2 by default

r? `@oli-obk`

Make clippy set mir_opt_level using Option

Shrink the size of Rvalue by 16 bytes

Fix borrow and deref

Allow noop_method_call in clippy ui test

Use diagnostic items in into_iter_collections

Add missing diagnostic item Symbols

Fix Clippy build and test

Merge commit '928e72dd10749875cbd412f74bfbfd7765dbcd8a' into clippyup

Move try_print_query_stack to rustc_interface.

Rollup merge of #82238 - petrochenkov:nocratemod, r=Aaron1011

ast: Keep expansion status for out-of-line module items

I.e. whether a module `mod foo;` is already loaded from a file or not.
This is a pre-requisite to correctly treating inner attributes on such modules (https://github.com/rust-lang/rust/issues/81661).

With this change AST structures for `mod` items diverge even more for AST structure for the crate root, which previously used `ast::Mod`.
Therefore this PR removes `ast::Mod` from `ast::Crate` in the first commit, these two things are sufficiently different from each other, at least at syntactic level.
Customization points for visiting a "`mod` item or crate root" were also removed from AST visitors (`fn visit_mod`).
`ast::Mod` itself was refactored away in the second commit in favor of `ItemKind::Mod(Unsafe, ModKind)`.

Rollup merge of #82215 - TaKO8Ki:replace-if-let-while-let, r=varkor

Replace if-let and while-let with `if let` and `while let`

This pull request replaces if-let and while-let with `if let` and `while let`.

closes https://github.com/rust-lang/rust/issues/82205

ast: Keep expansion status for out-of-line module items

Also remove `ast::Mod` which is mostly redundant now

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

Update Clippy

Biweekly Clippy update

r? `@Manishearth`

replace if-let and while-let with `if let` and `while let`

Only store a LocalDefId in hir::ImplItem.

Only store a LocalDefId in hir::TraitItem.

Only store a LocalDefId in hir::Item.

Items are guaranteed to be HIR owner.

Use ItemId as a strongly typed index.

Auto merge of #81238 - RalfJung:copy-intrinsics, r=m-ou-se

directly expose copy and copy_nonoverlapping intrinsics

This effectively un-does https://github.com/rust-lang/rust/pull/57997. That should help with `ptr::read` codegen in debug builds (and any other of these low-level functions that bottoms out at `copy`/`copy_nonoverlapping`), where the wrapper function will not get inlined. See the discussion in https://github.com/rust-lang/rust/pull/80290 and https://github.com/rust-lang/rust/issues/81163.

Cc `@bjorn3` `@therealprof`

Fix clippy's path to the copy intrinsics.

Merge commit '70c0f90453701e7d6d9b99aaa1fc6a765937b736' into clippyup

Rename HIR UnOp variants

This renames the variants in HIR UnOp from

    enum UnOp {
        UnDeref,
        UnNot,
        UnNeg,
    }

to

    enum UnOp {
        Deref,
        Not,
        Neg,
    }

Motivations:

- This is more consistent with the rest of the code base where most enum
  variants don't have a prefix.

- These variants are never used without the `UnOp` prefix so the extra
  `Un` prefix doesn't help with readability. E.g. we don't have any
  `UnDeref`s in the code, we only have `UnOp::UnDeref`.

- MIR `UnOp` type variants don't have a prefix so this is more
  consistent with MIR types.

- "un" prefix reads like "inverse" or "reverse", so as a beginner in
  rustc code base when I see "UnDeref" what comes to my mind is
  something like "&*" instead of just "*".

Rollup merge of #81680 - camsteffen:primty, r=oli-obk

Refactor `PrimitiveTypeTable` for Clippy

I removed `PrimitiveTypeTable` and added `PrimTy::ALL` and `PrimTy::from_name` in its place. This allows Clippy to use `PrimTy::from_name` for the `builtin_type_shadow` lint, and a `const` list of primitive types is deleted from Clippy code (the goal). All changes should be a little faster, if anything.

Bump clippy version

Suggest panic!("{}", ..) instead of panic!(..) clippy::expect_fun_call.

Fix/allow non_fmt_panic in clippy tests.

Use PrimTy in builtin type shadow lint

Merge commit '3e4179766bcecd712824da04356621b8df012ea4' into sync-from-clippy

Rollup merge of #81260 - vn971:restore-editorconfig, r=Mark-Simulacrum

Add .editorconfig

This adds a .editorconfig file to rust-lang/rust, matching Clippy's. It's not clear that this will benefit many people, but the cost is low and the rewards are potentially meaningful.

Auto merge of #81405 - bugadani:ast, r=cjgillot

Box the biggest ast::ItemKind variants

This PR is a different approach on https://github.com/rust-lang/rust/pull/81400, aiming to save memory in humongous ASTs.

The three affected item kind enums are:
 - `ast::ItemKind` (208 -> 112 bytes)
 - `ast::AssocItemKind` (176 -> 72 bytes)
 - `ast::ForeignItemKind` (176 -> 72 bytes)

Add .editorconfig

Editorconfig is a lightweight specification that
helps maintaining consistent coding/formatting style
accross editors, especially those editors
that are not explicitly aware of Rust and rustfmt.

https://editorconfig.org/

Auto merge of #80851 - m-ou-se:panic-2021, r=petrochenkov

Implement Rust 2021 panic

This implements the Rust 2021 versions of `panic!()`. See https://github.com/rust-lang/rust/issues/80162 and https://github.com/rust-lang/rfcs/pull/3007.

It does so by replacing `{std, core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller.

This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: https://github.com/rust-lang/rust/pull/80879/commits/c5273bdfb266c35e8eab9413aa8d58d27fdbe114 That change is blocked on figuring out what to do with https://github.com/rust-lang/rust/issues/80846 first.