This made more sense back when it was abbreviated, but now it
seems redundant.

Fixes rust-lang#93428

This fix is a response to a couple of special cases related to the
`module_id`, which is eventually used for trait candidates:

  * The module id is always set to the current crate, when checking `crate::`.

    Normally, the set of in-scope traits would be set in `load_links_in_attrs`,
    but if there are no doc comments, then that loop will never run.

  * the module id is set to the parent module, when resolving a module
    that is spelled like this:

        // Notice how we use an outlined doc comment here!
        // [`Test::my_fn`]
        mod something {
        }

    As with the above problem with `crate::`, we need to make sure the
    module gets its traits in scope resolved, even if it has no doc comments
    of its own.

The dirent returned from readdir() is only guaranteed to be valid for
d_reclen bytes on common platforms.  Since we copy the name separately
anyway, we can copy everything except d_name into DirEntry::entry.

Fixes rust-lang#93384.

Make `join!` description more accurate

…1-dead

Add note suggesting that predicate may be satisfied, but is not `const`

Not sure if we should be printing this in addition to, or perhaps _instead_ of the help message:
```
help: the trait `~const Add` is not implemented for `NonConstAdd`
```

Also added `ParamEnv::is_const` and `PolyTraitPredicate::is_const_if_const` and, in a separate commit, used those in other places instead of `== hir::Constness::Const`, etc.

r? ````@fee1-dead````

…oli-obk

Do not register infer var for GAT projection in RPIT

Fixes rust-lang#93340
Fixes rust-lang#91603

r? ```@oli-obk```

…tooltip, r=jsha,GuillaumeGomez

rustdoc: remove tooltip from source link

This made more sense back when it was abbreviated, but now it seems redundant.

Move unstable is_{arch}_feature_detected! macros to std::arch

These macros are unstable, except for `is_x86_feature_detected` which is still exported from the crate root for backwards-compatibility.

This should unblock the stabilization of `is_aarch64_feature_detected`.

r? ```@m-ou-se```

…oc-links-very-early, r=petrochenkov

rustdoc: load the set of in-scope traits for modules with no docstring

Fixes rust-lang#93428

This fix is a response to a couple of special cases related to the `module_id`, which is eventually used for trait candidates:

  * The module id is always set to the current crate, when checking `crate::`.

    Normally, the set of in-scope traits would be set in `load_links_in_attrs`, but if there are no doc comments, then that loop will never run.

  * the module id is set to the parent module, when resolving a module that is spelled like this:

        // Notice how we use an outlined doc comment here!
        // [`Test::my_fn`]
        mod something {
        }

    As with the above problem with `crate::`, we need to make sure the module gets its traits in scope resolved, even if it has no doc comments of its own.

… r=cuviper

fs: Don't copy d_name from struct dirent

The dirent returned from readdir() is only guaranteed to be valid for
d_reclen bytes on common platforms.  Since we copy the name separately
anyway, we can copy everything except d_name into DirEntry::entry.

Fixes rust-lang#93384.

Rename _args -> args in format_args expansion

As observed in rust-lang#91359 (comment), prior to that PR this variable was sometimes never used, such as in the case of:

```rust
println!("");

// used to expand to:
::std::io::_print(
    ::core::fmt::Arguments::new_v1(
        &["\n"],
        &match () {
            _args => [],
        },
    ),
);
```

so the leading underscore in `_args` was used to suppress an unused variable lint. However after rust-lang#91359 the variable is always used when present, as the unused case would instead expand to:

```rust
::std::io::_print(::core::fmt::Arguments::new_v1(&["\n"], &[]));
```