The current guarantee is too strong as it would prevent adapters
from exploiting knowledge about the iterator length and using counted
loops for example because they would stop calling `next()` before
it ever returned `None`. Additionally several nested zip iterators
already fail to uphold this.

This doesn't remove any of the specialization code that tries
(and sometimes fails) to uphold the guarantee for `next()`
because removing it would also affect `next_back()`
in more surprising ways.

Dependence on endianness and type sizes was reported for enum discriminants in rust-lang#74215 but it is a more general
issue since for example the default implementation of `Hasher::write_usize` uses native endianness.
Additionally the implementations of library types are occasionally changed as their internal fields
change or hashing gets optimized.

The "fixed" in "fixed steady state limits" means to exclude load-dependent resource prioritization
that would calculate to 100% of capacity on an idle system and less capacity on a loaded system.

Additionally I also exclude "system load" since it would be silly to try to identify
other, perhaps higher priority, processes hogging some CPU cores that aren't explicitly excluded
by masks/quotas/whatever.

Co-authored-by: pierwill <19642016+pierwill@users.noreply.github.com>

We carry around a list of stylesheets that can carry two different types
of thing:

 1. Internal stylesheets specific to a page type (only for settings)
 2. Themes

In this change I move the link generation for settings.css into
settings(), so Context.style_files is reserved just for themes.

We had two places where we extracted a base theme name from a list of
StylePaths. I consolidated that code to be a method on StylePath.

I moved generation of link tags for stylesheets into the page.html
template. With that change, I made the template responsible for special
handling of light.css (making it the default theme) and of the other
themes (marking them disabled). That allowed getting rid of the
`disabled` field on StylePath.

We had been injecting the list of themes and the rustdoc version into
main.js by rewriting it at doc generation time. By avoiding this
rewrite, we can make it easier to edit main.js without regenerating all
the docs.

Added a more convenient accessor for rustdoc-vars.

Changed storage.js to not rely on resourcesSuffix. It could in theory
use rustdoc-vars, but because rustdoc-vars is at the end of the HTML,
it's not available when storage.js runs (very early in page load).

Prior to PR rust-lang#91205, checking for errors in the overall obligation
would check checking the `ParamEnv`, due to an incorrect
`super_visit_with` impl. With this bug fixed, we will now
bail out of impl candidate assembly if the `ParamEnv` contains
any error types.

In practice, this appears to be overly conservative - when an error
occurs early in compilation, we end up giving up early for some
predicates that we could have successfully evaluated without overflow.
By only checking for errors in the predicate itself, we avoid causing
additional spurious 'type annotations needed' errors after a 'real'
error has already occurred.

With this PR, the diagnostic changes caused by PR rust-lang#91205 are reverted.

…ntee, r=dtolnay

Weaken guarantee around advancing underlying iterators in zip

The current guarantee (introduced in rust-lang#52279) is too strong as it prevents adapters from exploiting knowledge about the iterator length and using counted loops for example because they would stop calling `next()` before it ever returned `None`. Additionally several nested zip iterators already fail to uphold this.

This does not yet remove any of the specialization code that tries (and sometimes fails) to uphold the guarantee for `next()`
because removing it would also affect `next_back()` in more surprising ways.

The intent is to be able to remove for example this branch

https://github.com/rust-lang/rust/blob/36bcf4069717b9dff90270d13b53a3b130329960/library/core/src/iter/adapters/zip.rs#L234-L243

or this test

https://github.com/rust-lang/rust/blob/36bcf4069717b9dff90270d13b53a3b130329960/library/core/tests/iter/adapters/zip.rs#L177-L188

Solves rust-lang#82303 by declaring it a non-issue.

Document non-guarantees for Hash

Dependence on endianness and type sizes was reported for enum discriminants in rust-lang#74215 but it is a more general
issue since for example the default implementation of `Hasher::write_usize` uses native endianness.
Additionally the implementations of library types are occasionally changed as their internal fields
change or hashing gets optimized.

## Question

Should this go on the module level documentation instead since it also concerns `Hasher` to some extent and not just `Hash`?

resolves rust-lang#74215

…state, r=dtolnay

Expand `available_parallelism` docs in anticipation of cgroup quota support

The "fixed" in "fixed steady state limits" means to exclude load-dependent resource prioritization
that would calculate to 100% of capacity on an idle system and less capacity on a loaded system.

Additionally I also exclude "system load" since it would be silly to try to identify
other, perhaps higher priority, processes hogging some CPU cores that aren't explicitly excluded
by masks/quotas/whatever.

…GuillaumeGomez

rustdoc: Consolidate static-file replacement mechanism

There were a few places in rustdoc where we would take static JS or CSS and rewrite it at doc generation time to insert values. This consolidates all the CSS instances into one CSS file and replaces the JS examples with data- attributes on the rustdoc-vars div.

Demo https://rustdoc.crud.net/jsha/static-file-replace/test_docs/

r? `@GuillaumeGomez`

…lcnr

Only check for errors in predicate when skipping impl assembly

Prior to PR rust-lang#91205, checking for errors in the overall obligation
would check checking the `ParamEnv`, due to an incorrect
`super_visit_with` impl. With this bug fixed, we will now
bail out of impl candidate assembly if the `ParamEnv` contains
any error types.

In practice, this appears to be overly conservative - when an error
occurs early in compilation, we end up giving up early for some
predicates that we could have successfully evaluated without overflow.
By only checking for errors in the predicate itself, we avoid causing
additional spurious 'type annotations needed' errors after a 'real'
error has already occurred.

With this PR, the diagnostic changes caused by PR rust-lang#91205 are reverted.