The new flag has been described in the Major Change Proposal at
rust-lang/compiler-team#656

The test expectations don't apply to WASM, where the target spec
has a different default value of `default_hidden_visibility`.
See the test comments for more details.

This reverts commit f1bf874.

Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>

Before: http://notriddle.com/rustdoc-html-demo-6/tor-before/tor_config/

After: http://notriddle.com/rustdoc-html-demo-6/tor-after/tor_config/

Profile: http://notriddle.com/rustdoc-html-demo-6/tor-profile/

As a bit of background information: in type-based queries, a type
name that does not exist gets treated as a generic type variable.

This causes a counterintuitive behavior in the `tor_config` crate,
which has a trait with an associated type variable called `T`.

This isn't a searchable concrete type, but its name still gets stored
in the typeNameIdMap, as a convenient way to intern its name.

…ty, r=TaKO8Ki

Add unstable `-Zdefault-hidden-visibility` cmdline flag for `rustc`.

The new flag has been described in the Major Change Proposal at
rust-lang/compiler-team#656

…rtialEq, r=compiler-errors

Restore `const PartialEq`

And thus fixes a number of tests. There is a bug that still needs to be fixed, so WIP for now.

r? ``@compiler-errors``

…KO8Ki

Remove edition umbrella features.

In the 2018 edition, there was an "umbrella" feature `#[feature(rust_2018_preview)]` which was used to enable several other features at once. This umbrella mechanism was not used in the 2021 edition and likely will not be used in 2024 either. During 2018 users reported that setting the feature was awkward, especially since they already needed to opt-in via the edition mechanism.

This PR removes this mechanism because I believe it will not be used (and will clean up and simplify the code). I believe that there are better ways to handle features and editions. In short:

- For highly experimental features, that may or may not be involved in an edition, they can implement regular feature gates like `tcx.features().my_feature`.
- For experimental features that *might* be involved in an edition, they should implement gates with `tcx.features().my_feature && span.at_least_rust_20xx()`. This requires the user to still specify `#![feature(my_feature)]`, to avoid disrupting testing of other edition features which are ready and have been accepted within the edition.
- For experimental features that have graduated to definitely be part of an edition, they should implement gates with `tcx.features().my_feature || span.at_least_rust_20xx()`, or just remove the feature check altogether and just check `span.at_least_rust_20xx()`.
- For relatively simple changes, they can skip the whole feature gating thing and just check `span.at_least_rust_20xx()`, and rely on the instability of the edition itself (which requires `-Zunstable-options`) to gate it.

I am working on documenting all of this in the rustc-dev-guide.

Remove an allocation in min_stack

…ern, r=GuillaumeGomez

rustdoc-search: do not treat associated type names as types

[Before](http://notriddle.com/rustdoc-html-demo-6/tor-before/tor_config/list_builder/trait.DirectDefaultEmptyListBuilderAccessors.html?search=DirectDefaultEmptyListBuilderAccessors%3CT%3DT%3E%20-%3E%20Vec%3CT%3E#associatedtype.T)

[After](http://notriddle.com/rustdoc-html-demo-6/tor-after/tor_config/list_builder/trait.DirectDefaultEmptyListBuilderAccessors.html?search=DirectDefaultEmptyListBuilderAccessors%3CT%3DT%3E%20-%3E%20Vec%3CT%3E#associatedtype.T)

[Profile](http://notriddle.com/rustdoc-html-demo-6/tor-profile/index.html)

As a bit of background information: in type-based queries, a type name that does not exist gets treated as a generic type variable.

This causes a counterintuitive behavior in the `tor_config` crate, which has a trait with an associated type variable called `T`.

This isn't a searchable concrete type, but its name still gets stored in the typeNameIdMap, as a convenient way to intern its name.

(The second commit is a mostly unrelated bugfix.)