…ubtree-update

The compiler uses `BitSet<Local>`, because the number of locals doesn't
get that high, so clippy should do likewise.

Clippy subtree update

r? `@Manishearth`

Remove Node::ArrayLenInfer

Remove `hir::ArrayLen`

This refactoring removes `hir::ArrayLen`, replacing it with `hir::ConstArg`. To represent inferred array lengths (previously `hir::ArrayLen::Infer`), a new variant `ConstArgKind::Infer` is added.

r? `@BoxyUwU`

Eliminate magic numbers from expression precedence

Context: see rust-lang/rust#133140.

This PR continues on backporting Syn's expression precedence design into rustc. Rustc's design used mysterious integer quantities represented variously as `i8` or `usize` (e.g. `PREC_CLOSURE = -40i8`), a special significance around `0` that is never named, and an extra `PREC_FORCE_PAREN` precedence level that does not correspond to any expression. Syn's design uses a C-like enum with variants that clearly correspond to specific sets of expression kinds.

This PR is a refactoring that has no intended behavior change on its own, but it unblocks other precedence work that rustc's precedence design was poorly suited to accommodate.

- Asymmetrical precedence, so that a pretty-printer can tell `(return 1) + 1` needs parens but `1 + return 1` does not.

- Squashing the `Closure` and `Jump` cases into a single precedence level.

- Numerous remaining false positives and false negatives in rustc pretty-printer's parenthesization of macro metavariables, for example in `$e < rhs` where $e is `lhs as Thing<T>`.

FYI `@fmease` &mdash; you don't need to review if rustbot picks someone else, but you mentioned being interested in the followup PRs.

…rrors

remove `Ty::is_copy_modulo_regions`

Using these functions is likely incorrect if an `InferCtxt` is available, I moved this function to `TyCtxt` (and added it to `LateContext`) and added a note to the documentation that one should prefer `Infer::type_is_copy_modulo_regions` instead.

I didn't yet move `is_sized` and `is_freeze`, though I think we should move these as well.

r? `@compiler-errors` cc #132279

Change `AttrArgs::Eq` to a struct variant

Cleanups for simplifying rust-lang/rust#131808

Basically changes `AttrArgs::Eq` to a struct variant and then avoids several matches on `AttrArgsEq` in favor of methods on it. This will make future refactorings simpler, as they can either keep methods or switch to field accesses without having to restructure code

…cjgillot

Add lint against function pointer comparisons

This is kind of a follow-up to rust-lang/rust#117758 where we added a lint against wide pointer comparisons for being ambiguous and unreliable; well function pointer comparisons are also unreliable. We should IMO follow a similar logic and warn people about it.

-----

## `unpredictable_function_pointer_comparisons`

*warn-by-default*

The `unpredictable_function_pointer_comparisons` lint checks comparison of function pointer as the operands.

### Example

```rust
fn foo() {}
let a = foo as fn();

let _ = a == foo;
```

### Explanation

Function pointers comparisons do not produce meaningful result since they are never guaranteed to be unique and could vary between different code generation units. Furthermore different function could have the same address after being merged together.

----

This PR also uplift the very similar `clippy::fn_address_comparisons` lint, which only linted on if one of the operand was an `ty::FnDef` while this PR lints proposes to lint on all `ty::FnPtr` and `ty::FnDef`.

```@rustbot``` labels +I-lang-nominated

~~Edit: Blocked on rust-lang/libs-team#323 being accepted and it's follow-up pr~~

It was inconsistently done (sometimes even within a single function) and
most of the rest of the compiler uses fatal errors instead, which need
to be caught using catch_with_exit_code anyway. Using fatal errors
instead of ErrorGuaranteed everywhere in the driver simplifies things a
bit.

As a rule, the application of `unsafe` to a declaration requires that use-sites
of that declaration also require `unsafe`. For example, a field declared
`unsafe` may only be read in the lexical context of an `unsafe` block.

For nearly all safe traits, the safety obligations of fields are explicitly
discharged when they are mentioned in method definitions. For example,
idiomatically implementing `Clone` (a safe trait) for a type with unsafe fields
will require `unsafe` to clone those fields.

Prior to this commit, `Copy` violated this rule. The trait is marked safe, and
although it has no explicit methods, its implementation permits reads of `Self`.

This commit resolves this by making `Copy` conditionally safe to implement. It
remains safe to implement for ADTs without unsafe fields, but unsafe to
implement for ADTs with unsafe fields.

Tracking: #132922

Parse guard patterns

This implements the parsing of [RFC3637 Guard Patterns](https://rust-lang.github.io/rfcs/3637-guard-patterns.html) (see also [tracking issue](rust-lang/rust#129967)). This PR is extracted from rust-lang/rust#129996 with minor modifications.

cc `@max-niederman`

Rollup of 7 pull requests

Successful merges:

 - #133567 (A bunch of cleanups)
 - #133789 (Add doc alias 'then_with' for `then` method on `bool`)
 - #133880 (Expand home_dir docs)
 - #134036 (crash tests: use individual mir opts instead of mir-opt-level where easily possible)
 - #134045 (Fix some triagebot mentions paths)
 - #134046 (Remove ignored tests for hangs w/ new solver)
 - #134050 (Miri subtree update)

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

Initial implementation of `#[feature(default_field_values]`, proposed in rust-lang/rfcs#3681.

Support default fields in enum struct variant

Allow default values in an enum struct variant definition:

```rust
pub enum Bar {
    Foo {
        bar: S = S,
        baz: i32 = 42 + 3,
    }
}
```

Allow using `..` without a base on an enum struct variant

```rust
Bar::Foo { .. }
```

`#[derive(Default)]` doesn't account for these as it is still gating `#[default]` only being allowed on unit variants.

Support `#[derive(Default)]` on enum struct variants with all defaulted fields

```rust
pub enum Bar {
    #[default]
    Foo {
        bar: S = S,
        baz: i32 = 42 + 3,
    }
}
```

Check for missing fields in typeck instead of mir_build.

Expand test with `const` param case (needs `generic_const_exprs` enabled).

Properly instantiate MIR const

The following works:

```rust
struct S<A> {
    a: Vec<A> = Vec::new(),
}
S::<i32> { .. }
```

Add lint for default fields that will always fail const-eval

We *allow* this to happen for API writers that might want to rely on users'
getting a compile error when using the default field, different to the error
that they would get when the field isn't default. We could change this to
*always* error instead of being a lint, if we wanted.

This will *not* catch errors for partially evaluated consts, like when the
expression relies on a const parameter.

Suggestions when encountering `Foo { .. }` without `#[feature(default_field_values)]`:

 - Suggest adding a base expression if there are missing fields.
 - Suggest enabling the feature if all the missing fields have optional values.
 - Suggest removing `..` if there are no missing fields.

fix ICE on type error in promoted

Fixes rust-lang/rust#133968

Ensure that when we turn a type error into a "this promoted failed to evaluate" error, we do record this as something that may happen even in "infallible" promoteds.

Make `Copy` unsafe to implement for ADTs with `unsafe` fields

As a rule, the application of `unsafe` to a declaration requires that use-sites of that declaration also entail `unsafe`. For example, a field declared `unsafe` may only be read in the lexical context of an `unsafe` block.

For nearly all safe traits, the safety obligations of fields are explicitly discharged when they are mentioned in method definitions. For example, idiomatically implementing `Clone` (a safe trait) for a type with unsafe fields will require `unsafe` to clone those fields.

Prior to this commit, `Copy` violated this rule. The trait is marked safe, and although it has no explicit methods, its implementation permits reads of `Self`.

This commit resolves this by making `Copy` conditionally safe to implement. It remains safe to implement for ADTs without unsafe fields, but unsafe to implement for ADTs with unsafe fields.

Tracking: #132922

r? ```@compiler-errors```

Rollup of 11 pull requests

Successful merges:

 - #133478 (jsondocck: Parse, don't validate commands.)
 - #133967 ([AIX] Pass -bnoipath when adding rust upstream dynamic crates)
 - #133970 ([AIX] Replace sa_sigaction with sa_union.__su_sigaction for AIX)
 - #133980 ([AIX] Remove option "-n" from AIX "ln" command)
 - #134008 (Make `Copy` unsafe to implement for ADTs with `unsafe` fields)
 - #134017 (Don't use `AsyncFnOnce::CallOnceFuture` bounds for signature deduction)
 - #134023 (handle cygwin environment in `install::sanitize_sh`)
 - #134041 (Use SourceMap to load debugger visualizer files)
 - #134065 (Move `write_graphviz_results`)
 - #134106 (Add compiler-maintainers who requested to be on review rotation)
 - #134123 (bootstrap: Forward cargo JSON output to stdout, not stderr)

Failed merges:

 - #134120 (Remove Felix from ping groups and review rotation)

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

…r paths involving them

When we expand a `mod foo;` and parse `foo.rs`, we now track whether that file had an unrecovered parse error that reached the end of the file. If so, we keep that information around. When resolving a path like `foo::bar`, we do not emit any errors for "`bar` not found in `foo`", as we know that the parse error might have caused `bar` to not be parsed and accounted for.

When this happens in an existing project, every path referencing `foo` would be an irrelevant compile error. Instead, we now skip emitting anything until `foo.rs` is fixed. Tellingly enough, we didn't have any test for errors caused by `mod` expansion.

Fix #97734.

…ave constness

Consider comments and bare delimiters the same as an "empty line" for purposes of hiding rendered code output of long multispans. This results in more aggressive shortening of rendered output without losing too much context, specially in `*.stderr` tests that have "hidden" comments.

…tiline span rendering

Move impl constness into impl trait header

This PR is kind of the opposite of the rejected rust-lang/rust#134114

Instead of moving more things into the `constness` query, we want to keep them where their corresponding hir nodes are lowered. So I gave this a spin for impls, which have an obvious place to be (the impl trait header). And surprisingly it's also a perf improvement (likely just slightly better query & cache usage).

The issue was that removing anything from the `constness` query makes it just return `NotConst`, which is wrong. So I had to change it to `bug!` out if used wrongly, and only then remove the impl blocks from the `constness` query. I think this change is good in general, because it makes using `constness` more robust (as can be seen by how few sites that had to be changed, so it was almost solely used specifically for the purpose of asking for functions' constness). The main thing where this change was not great was in clippy, which was using the `constness` query as a general DefId -> constness map. I added a `DefKind` filter in front of that. If it becomes a more common pattern we can always move that helper into rustc.

…th-parse-errors, r=davidtwco

Keep track of parse errors in `mod`s and don't emit resolve errors for paths involving them

When we expand a `mod foo;` and parse `foo.rs`, we now track whether that file had an unrecovered parse error that reached the end of the file. If so, we keep that information around in the HIR and mark its `DefId` in the `Resolver`. When resolving a path like `foo::bar`, we do not emit any errors for "`bar` not found in `foo`", as we know that the parse error might have caused `bar` to not be parsed and accounted for.

When this happens in an existing project, every path referencing `foo` would be an irrelevant compile error. Instead, we now skip emitting anything until `foo.rs` is fixed. Tellingly enough, we didn't have any test for errors caused by expansion of `mod`s with parse errors.

Fix rust-lang/rust#97734.

Add AST support for unsafe binders

I'm splitting up #130514 into pieces. It's impossible for me to keep up with a huge PR like that. I'll land type system support for this next, probably w/o MIR lowering, which will come later.

r? `@oli-obk`
cc `@BoxyUwU` and `@lcnr` who also may want to look at this, though this PR doesn't do too much yet

Don't consider `///` and `//!` docstrings to be empty for the purposes of multiline span rendering.

Rollup of 7 pull requests

Successful merges:

 - #133900 (Advent of `tests/ui` (misc cleanups and improvements) [1/N])
 - #133937 (Keep track of parse errors in `mod`s and don't emit resolve errors for paths involving them)
 - #133938 (`rustc_mir_dataflow` cleanups, including some renamings)
 - #134058 (interpret: reduce usage of TypingEnv::fully_monomorphized)
 - #134130 (Stop using driver queries in the public API)
 - #134140 (Add AST support for unsafe binders)
 - #134229 (Fix typos in docs on provenance)

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

Tweak multispan rendering to reduce output length

Consider comments and bare delimiters the same as an "empty line" for purposes of hiding rendered code output of long multispans. This results in more aggressive shortening of rendered output without losing too much context, specially in `*.stderr` tests that have "hidden" comments. We do that check not only on the first 4 lines of the multispan, but now also on the previous to last line as well.

Rename `ty_def_id` so people will stop using it by accident

This function is just for cycle detection, but people keep using it because they think it's the right way of getting the def id from a `Ty` (and I can't blame them necessarily).

Rollup of 8 pull requests

Successful merges:

 - #134252 (Fix `Path::is_absolute` on Hermit)
 - #134254 (Fix building `std` for Hermit after `c_char` change)
 - #134255 (Update includes in `/library/core/src/error.rs`.)
 - #134261 (Document the symbol Visibility enum)
 - #134262 (Arbitrary self types v2: adjust diagnostic.)
 - #134265 (Rename `ty_def_id` so people will stop using it by accident)
 - #134271 (Arbitrary self types v2: better feature gate test)
 - #134274 (Add check-pass test for `&raw`)

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

…-obk

(Re-)Implement `impl_trait_in_bindings`

This reimplements the `impl_trait_in_bindings` feature for local bindings.

"`impl Trait` in bindings" serve as a form of *trait* ascription, where the type basically functions as an infer var but additionally registering the `impl Trait`'s trait bounds for the infer type. These trait bounds can be used to enforce that predicates hold, and can guide inference (e.g. for closure signature inference):

```rust
let _: impl Fn(&u8) -> &u8 = |x| x;
```

They are implemented as an additional set of bounds that are registered when the type is lowered during typeck, and then these bounds are tied to a given `CanonicalUserTypeAscription` for borrowck. We enforce these `CanonicalUserTypeAscription` bounds during borrowck to make sure that the `impl Trait` types are sensitive to lifetimes:

```rust
trait Static: 'static {}
impl<T> Static for T where T: 'static {}

let local = 1;
let x: impl Static = &local;
//~^ ERROR `local` does not live long enough
```

r? oli-obk

cc #63065

---

Why can't we just use TAIT inference or something? Well, TAITs in bodies have the problem that they cannot reference lifetimes local to a body. For example:

```rust
type TAIT = impl Display;
let local = 0;
let x: TAIT = &local;
//~^ ERROR `local` does not live long enough
```

That's because TAITs requires us to do *opaque type inference* which is pretty strict, since we need to remap all of the lifetimes of the hidden type to universal regions. This is simply not possible here.

---

I consider this part of the "impl trait everywhere" experiment. I'm not certain if this needs yet another lang team experiment.