[`slow_vector_initialization`]: clarify why `Vec::new()` + resize is worse

#11198 extended this lint to also warn on `Vec::new()` + `resize(0, len)`, but did not update the lint documentation, so it left some confused (https://github.com/rust-lang/rust-clippy/issues/10938#issuecomment-1663880083).
This PR should make it a bit more clear. (cc `@djc` `@vi` what do you think about this?)

<details>
<summary>More details</summary>

Godbolt for `Vec::new()` + `.resize(x, 0)`: https://godbolt.org/z/e7q9xc9rG

The resize call first does a normal allocation (`__rust_alloc`):
```asm
alloc::raw_vec::finish_grow:
  ...
  cmp     qword ptr [rcx + 8], 0
  je      .LBB1_7  ; if capacity == 0 -> LBB1_7

.LBB1_7:
  ...
  call    qword ptr [rip + __rust_alloc@GOTPCREL]
```

*Then* a memset for zero initialization:
```asm
example::f:
  ...
  xor     esi, esi  ; 0
  call    qword ptr [rip + memset@GOTPCREL]
```
------------

Godbolt for `vec![0; len]`: https://godbolt.org/z/M3vr53vWY

Important bit:
```asm
example::f:
  ...
  call    qword ptr [rip + __rust_alloc_zeroed@GOTPCREL]
```

</details>

changelog: [`slow_vector_initialization`]: clarify why `Vec::new()` + resize is worse than `vec![0; len]`

Co-authored-by: NDirkjan Ochtman <dirkjan@ochtman.nl>

[`redundant_guards`]: don't lint on float literals

Fixes #11304

changelog: [`redundant_guards`]: don't lint on float literals

r? `@Centri3` i figured you are probably a good reviewer for this since you implemented the lint ^^

Store the laziness of type aliases in their `DefKind`

Previously, we would treat paths referring to type aliases as *lazy* type aliases if the current crate had lazy type aliases enabled independently of whether the crate which the alias was defined in had the feature enabled or not.

With this PR, the laziness of a type alias depends on the crate it is defined in. This generally makes more sense to me especially if / once lazy type aliases become the default in a new edition and we need to think about *edition interoperability*:

Consider the hypothetical case where the dependency crate has an older edition (and thus eager type aliases), it exports a type alias with bounds & a where-clause (which are void but technically valid), the dependent crate has the latest edition (and thus lazy type aliases) and it uses that type alias. Arguably, the bounds should *not* be checked since at any time, the dependency crate should be allowed to change the bounds at will with a *non*-major version bump & without negatively affecting downstream crates.

As for the reverse case (dependency: lazy type aliases, dependent: eager type aliases), I guess it rules out anything from slight confusion to mild annoyance from upstream crate authors that would be caused by the compiler ignoring the bounds of their type aliases in downstream crates with older editions.

---

This fixes #114468 since before, my assumption that the type alias associated with a given weak projection was lazy (and therefore had its variances computed) did not necessarily hold in cross-crate scenarios (which [I kinda had a hunch about](https://github.com/rust-lang/rust/pull/114253#discussion_r1278608099)) as outlined above. Now it does hold.

`@rustbot` label F-lazy_type_alias
r? `@oli-obk`

Small code style adjustments

changelog: none

redundant_type_annotations: only pass certain def kinds to type_of

Fixes #11190
Fixes rust-lang/rust#113516

Also adds an `is_lint_allowed` check to skip the lint when it's not needed

changelog: none

New lints: `impossible_comparisons` and `redundant_comparisons`

Inspired by a bug we had in production, like all good lints ;)

Adds two lints for "double" comparisons, specifically when the same expression is being compared against two different constants.

`impossible_comparisons` checks for expressions that can never be true at all. Example:
```rust
status_code <= 400 && status_code > 500
```
Presumably, the programmer intended to write `status_code >= 400 && status_code < 500` in this case.

`redundant_comparisons` checks for expressions where either half has no effect. Example:
```rust
status_code <= 400 && status_code < 500
```

Works with other literal types like floats and strings, and *some* cases where the constant is more complex than a literal, see the tests for more.

**Limitations and/or future work:**
* Doesn't work if the LHS can have side-effects at all, for example by being a function call
* Only works for exactly two comparison expressions, so `x > y && x > z && x < w` won't get checked
* Doesn't check for comparison expressions combined with `||`. Very similar logic could be applied there.

changelog: New lints [`impossible_comparisons`] and [`redundant_comparisons`]

Co-authored-by: NCatherine Flores <catherine.3.flores@gmail.com>

Add documentation to has_deref

Documentation of `has_deref` needed some polish to be more clear about where it should be used and what's it's purpose.

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

r? `@RalfJung`

Replace ConstEvalLateContext::new() with two calls to constant() to simplify the code, after PR suggestion

Rename 'impossible_double_const_comparisons' -> 'impossible_comparisons' and 'ineffective_double_const_comparisons' -> 'redundant_comparisons', after discussion on Zulip

Add descriptions for 'impossible_double_const_comparisons' and 'ineffective_double_const_comparisons'

fix: Make ConstEvalLateContext::new() public, to match the 'constant_context()' function that it replaced

Rollup of 9 pull requests

Successful merges:

 - #113945 (Fix wrong span for trait selection failure error reporting)
 - #114351 ([rustc_span][perf] Remove unnecessary string joins and allocs.)
 - #114418 (bump parking_lot to 0.12)
 - #114434 (Improve spans for indexing expressions)
 - #114450 (Fix ICE failed to get layout for ReferencesError)
 - #114461 (Fix unwrap on None)
 - #114462 (interpret: add mplace_to_ref helper method)
 - #114472 (Reword `confusable_idents` lint)
 - #114477 (Account for `Rc` and `Arc` when suggesting to clone)

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

Improve spans for indexing expressions

fixes #114388

Indexing is similar to method calls in having an arbitrary left-hand-side and then something on the right, which is the main part of the expression. Method calls already have a span for that right part, but indexing does not. This means that long method chains that use indexing have really bad spans, especially when the indexing panics and that span in coverted into a panic location.

This does the same thing as method calls for the AST and HIR, storing an extra span which is then put into the `fn_span` field in THIR.

r? compiler-errors

Lots of tiny incremental simplifications of `EmitterWriter` internals

ignore the first commit, it's https://github.com/rust-lang/rust/pull/114088 squashed and rebased, but it's needed to use to use `derive_setters`, as they need a newer `syn` version.

Then this PR starts out with removing many arguments that are almost always defaulted to `None` or `false` and replace them with builder methods that can set these fields in the few cases that want to set them.

After that it's one commit after the other that removes or merges things until everything becomes some very simple trait objects

Indexing is similar to method calls in having an arbitrary
left-hand-side and then something on the right, which is the main part
of the expression. Method calls already have a span for that right part,
but indexing does not. This means that long method chains that use
indexing have really bad spans, especially when the indexing panics and
that span in coverted into a panic location.

This does the same thing as method calls for the AST and HIR, storing an
extra span which is then put into the `fn_span` field in THIR.

Perform OpaqueCast field projection on HIR, too.

fixes #105819

This is necessary for closure captures in 2021 edition, as they capture individual fields, not the full mentioned variables. So it may try to capture a field of an opaque (because the hidden type is known to be something with a field).

See https://github.com/rust-lang/rust/pull/99806 for when and why we added OpaqueCast to MIR.

Add `internal_features` lint

Implements https://github.com/rust-lang/compiler-team/issues/596

Also requires some more test blessing for codegen tests etc

`@jyn514` had the idea of just `allow`ing the lint by default in the test suite. I'm not sure whether this is a good idea, but it's definitely one worth considering. Additional input encouraged.

Fix `suspicious_xor_used_as_pow.rs` performance

The original `suspicious_xor_used_as_pow` lint had poor performance, so I fixed that + a little refactor so that module is readable.

**107 millis. -> 106 millis.** Using `SPEEDTEST` on Rust's VMs

fix #11060
changelog: [`suspicious_xor_used_as_pow`]: Improve performance by 0.934%

Expand, rename and improve `incorrect_fn_null_checks` lint

This PR,

 - firstly, expand the lint by now linting on references
 - secondly, it renames the lint `incorrect_fn_null_checks` -> `useless_ptr_null_checks`
 - and thirdly it improves the lint by catching `ptr::from_mut`, `ptr::from_ref`, as well as `<*mut _>::cast` and `<*const _>::cast_mut`

Fixes https://github.com/rust-lang/rust/issues/113601
cc ```@est31```

It lints against features that are inteded to be internal to the
compiler and standard library. Implements MCP #596.

We allow `internal_features` in the standard library and compiler as those
use many features and this _is_ the standard library from the "internal to the compiler and
standard library" after all.

Marking some features as internal wasn't exactly the most scientific approach, I just marked some
mostly obvious features. While there is a categorization in the macro,
it's not very well upheld (should probably be fixed in another PR).

We always pass `-Ainternal_features` in the testsuite
About 400 UI tests and several other tests use internal features.
Instead of throwing the attribute on each one, just always allow them.
There's nothing wrong with testing internal features^^