…::insert()`

…Map::insert()`

As discovered in rust-lang#85461, the MSVC linker treats weak symbols slightly
differently than unix-y linkers do. This causes link.exe to fail with
LNK1227 "conflicting weak extern definition" where as other targets are
able to link successfully.

This changes the dead functions from being generated as weak/hidden to
private/default which, as the LLVM reference says:

> Global values with “private” linkage are only directly accessible by
objects in the current module. In particular, linking code into a module
with a private global value may cause the private to be renamed as
necessary to avoid collisions. Because the symbol is private to the
module, all references can be updated. This doesn’t show up in any
symbol table in the object file.

This fixes the conflicting weak symbols but doesn't address the reason
*why* we have conflicting symbols for these dead functions. The test
cases added in this commit contain a minimal repro of the fundamental
issue which is that the logic used to decide what dead code functions
should be codegen'd in the current CGU doesn't take into account that
functions can be duplicated across multiple CGUs (for instance, in the
case of `#[inline(always)]` functions).

Fixing that is likely to be a more complex change (see
rust-lang#85461 (comment)).

Fixes rust-lang#85461

Also:

- Review and edit current docs
- Enforce documentation for crate

Co-authored-by: r00ster <r00ster91@protonmail.com>
Co-authored-by: Camille Gillot <gillot.camille@gmail.com>

…s, r=cjgillot

Document all public items in `rustc_incremental`

Also:

- Review and edit current docs
- Enforce documentation for the module.

…, r=dtolnay

Fix incorrect stability attributes

These two instances were caught in rust-lang#90356, but that PR isn't going to be merged. I've extracted these to ensure it's still correct.

``@rustbot`` label: +A-stability +C-cleanup +S-waiting-on-review

Fix method name reference in stream documentation

adjust const_eval_select documentation

"The Rust compiler assumes" indicates that this is language UB, but [I don't think that is a good idea](https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/const_eval_select.20assumptions). This UB would be very hard to test for and looks like a way-too-big footgun. ``@oli-obk`` suggested this is meant to be more like "library UB", so I tried to adjust the docs accordingly.

I also removed all references to "referential transparency". That is a rather vague concept used to mean many different things, and I honestly have no idea what exactly is meant by it in this specific instance. But I assume ``@fee1-dead`` had in their mind a property that all `const fn` code upholds, so by demanding that the runtime code and the const-time code are *observably equivalent*, whatever that property is would also be enforced here.

Cc ``@rust-lang/wg-const-eval``

…r, r=tmandry

code-cov: generate dead functions with private/default linkage

As discovered in rust-lang#85461, the MSVC linker treats weak symbols slightly
differently than unix-y linkers do. This causes link.exe to fail with
LNK1227 "conflicting weak extern definition" where as other targets are
able to link successfully.

This changes the dead functions from being generated as weak/hidden to
private/default which, as the LLVM reference says:

> Global values with “private” linkage are only directly accessible by
objects in the current module. In particular, linking code into a module
with a private global value may cause the private to be renamed as
necessary to avoid collisions. Because the symbol is private to the
module, all references can be updated. This doesn’t show up in any
symbol table in the object file.

This fixes the conflicting weak symbols but doesn't address the reason
*why* we have conflicting symbols for these dead functions. The test
cases added in this commit contain a minimal repro of the fundamental
issue which is that the logic used to decide what dead code functions
should be codegen'd in the current CGU doesn't take into account that
functions can be duplicated across multiple CGUs (for instance, in the
case of `#[inline(always)]` functions).

Fixing that is likely to be a more complex change (see
rust-lang#85461 (comment)).

Fixes rust-lang#85461

…eeMap-documentation, r=yaahc

Update documentation to use `from()` to initialize `HashMap`s and `BTreeMap`s

As of Rust 1.56, `HashMap` and `BTreeMap` both have associated `from()` functions.  I think using these in the documentation cleans things up a bit.  It allows us to remove some of the `mut`s and avoids the Initialize-Then-Modify anti-pattern.

…=dtolnay

Fix Vec::extend_from_slice docs

`other` is a slice not a vector.

…llot

Fix ICE on format string of macro with secondary-label

This generalizes the fix rust-lang#86104 to also correctly skip `Span::from_inner` for the `secondary_label` of a format macro parsing error as well.

We can alternatively skip the `span_label` diagnostic call for the secondary label as well, since that label probably only makes sense when the _proper_ span is computed.

Fixes rust-lang#91556

Remove redundant [..]s

Fix documentation for `core::ready::Ready`