Rollup of 6 pull requests

Successful merges:

 - #114959 (fix #113702 emit a proper diagnostic message for unstable lints passed from CLI)
 - #115011 (Warn on elided lifetimes in associated constants (`ELIDED_LIFETIMES_IN_ASSOCIATED_CONSTANT`))
 - #115077 (Do not emit invalid suggestion in E0191 when spans overlap)
 - #115087 (Add disclaimer on size assertion macro)
 - #115090 (Always use `os-release` rather than `/lib` to detect `NixOS` (bootstrap))
 - #115101 (triagebot: add dependency licensing pings)

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

triagebot: add dependency licensing pings

If a compiler dependency is added, it's probably worth having that double-checked by compiler co-leads to confirm the licensing is okay.

r? `@wesleywiser`

Always use `os-release` rather than `/lib` to detect `NixOS` (bootstrap)

[Two users over on zulip](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Bootstrapping.20on.20NixOS) bumped into issues where NixOS wasn't being properly detected.

I believe this was caused by the presence of `/lib` on their machines. `/lib` is not standard on NixOS but can still be created by users or scripts.

We are already checking `/etc/os-release`. The presence of `ID=nixos` in it's output should be trustworthy and we shouldn't then go on to also check for `/lib`.

Add disclaimer on size assertion macro

Sometimes people are inspired by rustc to add size assertions to their code and copy the macro. This is bad because it causes hard build errors. rustc happens to be special where it makes this okay.

For example, see #115028 (not sure whether they were directly inspired by this function), but I think I've also seen other cases.

Do not emit invalid suggestion in E0191 when spans overlap

Fix #115019.

Warn on elided lifetimes in associated constants (`ELIDED_LIFETIMES_IN_ASSOCIATED_CONSTANT`)

Elided lifetimes in associated constants (in impls) erroneously resolve to fresh lifetime parameters on the impl since #97313. This is not correct behavior (see #38831).

I originally opened #114716 to fix this, but given the time that has passed, the crater results seem pretty bad: https://github.com/rust-lang/rust/pull/114716#issuecomment-1682091952

This PR alternatively implements a lint against this behavior, and I'm hoping to bump this to deny in a few versions.

fix #113702 emit a proper diagnostic message for unstable lints passed from CLI

Current output:
```bash
$ build/host/stage1/bin/rustc hello.rs -Wunnameable_types
warning: unknown lint: `unnameable_types`
  |
  = note: the `unnameable_types` lint is unstable
  = note: see issue #48054 <https://github.com/rust-lang/rust/issues/48054> for more information
  = help: add `-Zcrate-attr="feature(type_privacy_lints)"` to the command-line options to enable
  = note: `#[warn(unknown_lints)]` on by default

warning: 1 warning emitted
```

Previously, the feature gate diagnostic message is like below, which is the same as the message for unstable lints from the root module.

```shell
= help: add `#![feature(type_privacy_lints)]` to the crate attributes to enable
```

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

Fix #115019.

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

Redefine the pluralize macro's arm

Redefine the unintuitive pluralize macro's arm because of the negation. The initial code starts with check if count is not 1, which is confusing and unintuitive.

The arm shoud start with checking,

- if "count" `is 1` then, append `""` (empty string) - indicate as singular
- Then check if "count" `is not 1` (more than 1), append `"s"` - indicate as plural

Before:
```rs
// This arm is abit confusing since it start with checking, if "count" is more than 1, append "s".
($x:expr) => {
    if $x != 1 { "s" } else { "" }
};
```

After:
```rs
// Pluralize based on count (e.g., apples)
($x:expr) => {
    if $x == 1 { "" } else { "s" }
};
```

update Miri

r? `@ghost`

fix ##113702

fix #113702

unknown unstable lint command lint

improve impelementation

bootstrap/miri: respect config_locked_deps

[Two users over on zulip](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Bootstrapping.20on.20NixOS) bumped into issues where NixOS wasn't being properly detected.

I believe this was caused by the presence of `/lib` on their machines. `/lib` is not standard on NixOS but can still be created by users or scripts.

We are already checking `/etc/os-release`. The presence of `ID=nixos` in it's output should be trustworthy and we shouldn't then go on to also check for `/lib`.

automatically start and stop josh in rustc-pull/push

Let's make use of the fact that this is not a shell script any more. :)

Co-authored-by: NLeón Orell Valerian Liehr <me@fmease.dev>

Remove myself from review rotation

I'll.. still be around, just not as active as I had been. I'm not adding myself to `users_on_vacation`, because anyone should still feel free to r? me if they want a specific review from me.

bump serde

bump to a version with the binary blob removed

also, respect CARGO_EXTRA_FLAGS in more places

Sometimes people are inspired by rustc to add size assertions to their
code and copy the macro. This is bad because it causes hard build
errors. rustc happens to be special where it makes this okay.

Reassign sparc-unknown-none-elf to tier 3

It should never have been moved to tier 2. It is a new platform and the maintainer has agreed to do tier 3 maintenance for it, not tier 2.

r? `@jonathanpallant`

Fix table issues in platform support documentation (closes #115047)

mdBook needs an empty line before and after the table block.
In addition, in the tier-3 list three targets forgot about the host column and therefore showed the notes in the host column.

Closes #115047

Add `suggestion` for some `#[deprecated]` items

Consider code:
```rust
fn main() {
    let _ = ["a", "b"].connect(" ");
}
```

Currently it shows deprecated warning:
```rust
warning: use of deprecated method `std::slice::<impl [T]>::connect`: renamed to join
 --> src/main.rs:2:24
  |
2 |     let _ = ["a", "b"].connect(" ");
  |                        ^^^^^^^
  |
  = note: `#[warn(deprecated)]` on by default
```

This PR adds `suggestion` for `connect` and some other deprecated items, so the warning will be changed to this:
```rust
warning: use of deprecated method `std::slice::<impl [T]>::connect`: renamed to join
 --> src/main.rs:2:24
  |
2 |     let _ = ["a", "b"].connect(" ");
  |                        ^^^^^^^
  |
  = note: `#[warn(deprecated)]` on by default
help: replace the use of the deprecated method
  |
2 |     let _ = ["a", "b"].join(" ");
  |                        ^^^^
```

Rollup of 3 pull requests

Successful merges:

 - #115044 (stable_mir: docs clarification)
 - #115054 (Fix syntax in E0191 explanation.)
 - #115067 (docs: add alias log1p to ln_1p)

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

docs: add alias log1p to ln_1p

This is what the function is called in several other languages:

* https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/log1p
* https://numpy.org/doc/stable/reference/generated/numpy.log1p.html
* https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/log1p-log1pf-log1pl2?view=msvc-170

It also confused people at URLO: https://users.rust-lang.org/t/64-bit-trigonometry/98599/27

Similar to:

* https://github.com/rust-lang/rust/pull/114971
* https://github.com/rust-lang/rust/pull/114977

Fix syntax in E0191 explanation.

This trait needs `dyn` in modern Rust.

Fixes #115042.

stable_mir: docs clarification

It should never have been moved to tier 2.
It is a new platform and the maintainer has agreed
to do tier 3 maintenance for it, not tier 2.

This is what the function is called in several other languages:

* https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/log1p
* https://numpy.org/doc/stable/reference/generated/numpy.log1p.html
* https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/log1p-log1pf-log1pl2?view=msvc-170

It also confused people at URLO: https://users.rust-lang.org/t/64-bit-trigonometry/98599/27

Add projection obligations when comparing impl too

Fixes #115033

In the test, when we ask for WF obligations of `DatasetIter<'a, ArrayBase<D>>`, we get back two important obligations: `[<D as Data>::Elem -> ?1, ?1: 'a]`. If we don't add the projection obligation, `?1` remains unconstrained.

An alternative solution would be to use unnormalized obligations, where we only have one relevant obligation: `<D as Data>::Elem: 'a`. This would leave no inference vars unconstrained.