rustc's startup has several layers, including:
- `interface::run_compiler` passes a closure, `f`, to
  `run_in_thread_pool_with_globals`, which creates a thread pool, sets
  up session globals, and passes `f` to `create_compiler_and_run`.
- `create_compiler_and_run` creates a `Session`, a `Compiler`, sets the
  source map, and calls `f`.

rustdoc is a bit different.
- `main_args` calls `main_options` via
  `run_in_thread_pool_with_globals`, which (again) creates a thread pool
  (hardcoded to a single thread!) and sets up session globals.
- `main_options` has four different paths.
  - The second one calls `interface::run_compiler`, which redoes the
    `run_in_thread_pool_with_globals`! This is bad.
  - The fourth one calls `interface::create_compiler_and_run`, which is
    reasonable.
  - The first and third ones don't do anything of note involving the
    above functions, except for some symbol interning which requires
    session globals.

In other words, rustdoc calls into `rustc_interface` at three different
levels. It's a bit confused, and feels like code where functionality has
been added by different people at different times without fully
understanding how the globally accessible stuff is set up.

This commit tidies things up. It removes the
`run_in_thread_pool_with_globals` call in `main_args`, and adjust the
four paths in `main_options` as follows.
- `markdown::test` calls `test::test_main`, which provides its own
  parallelism and so doesn't need a thread pool. It had one small use of
  symbol interning, which required session globals, but the commit
  removes this.
- `doctest::run` already calls `interface::run_compiler`, so it doesn't
  need further adjustment.
- `markdown::render` is simple but needs session globals for interning
  (which can't easily be removed), so it's now wrapped in
  `create_session_globals_then`.
- The fourth path now uses `interface::run_compiler`, which is
  equivalent to the old `run_in_thread_pool_with_globals` +
  `create_compiler_and_run` pairing.

There is no longer any need for them to be separate.

It has a single call site, and removing it slightly improves the
confusing tangle of nested closures present at startup.

It has a single call site.

This avoids the need for a degenerate `Lrc::get_mut` call.

When added in 4596436, these multi-class
selectors were present in the initial commit, but no reason was given why
the shorter selector wouldn't work.

Co-authored-by: jyn514 <[email protected]>
Co-authored-by: Esteban Kuber <[email protected]>

…ounds, r=petrochenkov

Point out incompatible closure bounds

Fixes rust-lang#100295

`let`'s not needed in struct field definitions

Fixes rust-lang#101683

Clean up rustdoc startup

Startup is pretty hairy, in both rustdoc and rustc. The first commit here improves the rustdoc situation quite a bit. The remaining commits are smaller but also help.

Best reviewed one commit at a time.

r? `@jyn514`

…r=fee1-dead

Unify `tcx.constness` query and param env constness checks

The checks that we do in the `constness` query seem inconsistent with the checks that we do to determine if an item's param-env is const, so I merged them into the `constness` query and call that from the `param_env` query.

I'm not sure if this totally makes sense -- is there a case where `tcx.param_env()` would return a const param-env for an item whose `tcx.constness()` is `Constness::NotConst`? Because if not, it seems a bit dangerous that these two differ.

Luckily, not many places actually use `tcx.constness()`, and the checks in `tcx.param_env()` seem stricter than the checks in `tcx.constness()` (at least for the types of items we type-check).

Also, due to the way that `tcx.param_env()` is implemented, it _never_ used to return a const param-env for a item coming from a different crate, which also seems dangerous (though also probably not weaponizable currently, because we seldom actually compute the param-env for a non-local item).

…hor, r=GuillaumeGomez

rustdoc: clean up overly complex `.trait-impl` CSS selectors

When added in 4596436, these multi-class selectors were present in the initial commit, but no reason was given why the shorter selector wouldn't work.

…1-dead

suggest candidates for unresolved import

Currently we prompt suggestion of candidates(help notes of `use xxx::yyy`) for names which cannot be resolved, but we don't do that for import statements themselves that couldn't be resolved. It seems reasonable to add candidate help information for these statements as well.
Fixes rust-lang#102711