Several times, people have seemed unclear on how to respond to some of
the policy requirements, particularly those that just state things the
target developers must *not* do (e.g. not posting to PRs that break the
target). Add a note that such requirements just need acknowledgement,
nothing more.

Make quoting and responding a "must" rather than an "is encouraged to",
since it's easier to review the requirements that way.

The requirement on dependencies was phrased in terms of "host tools",
but it was also intended to apply equally to targets that only support
cross-compilation. Only the exception (for libraries commonly needed for
binaries on the target) was intended to apply to host tools. Reword the
requirement to talk about the dependencies required for "compiling,
linking,and emitting functional binaries, libraries, or other code for
the target", rather than generically in terms of dependencies for
rustc/cargo.

This doesn't change the net effect of the requirements, since other
requirements already stated that the target can't make the Rust
toolchain depend on proprietary libraries. However, this should make the
requirements clearer.

The requirement for target documentation talks about "running tests",
but tier 3 targets often don't support running the full testsuite, and
in practice the documentation for how to run an individual binary may be
more useful. Change "running tests" to "running binaries, or running
tests".

Explain that target-specific documentation should appear in a
subdirectory of platform-support, with a link from the target's entry on
the platform-support page.

Use "(associated) function" terminology instead of "method".

Co-authored-by: Daniel Henry-Mantilla <daniel.henry.mantilla@gmail.com>

This adds the old, pre 90639 `is_implemented` that previously only was
true if the implementation of the item was from the given impl block and
not from the trait default.

This test checks that `#[rustc_must_implement_one_of]` is gated behind
`#![feature(rustc_attrs)]`.

This was originally introduced in rust-lang#10916 as a way to remove all landing
pads when performing LTO. However this is no longer necessary today
since rustc properly marks all functions and call-sites as nounwind
where appropriate.

In fact this is incorrect in the presence of `extern "C-unwind"` which
must create a landing pad when compiled with `-C panic=abort` so that
foreign exceptions are caught and properly turned into aborts.

Faced with a very long word, browsers will let it overflow its
box horizontally rather than break it in the middle. We essentially
never want that behavior. We would rather break the word and keep it
inside its horizontal limits. So we apply a default overflow-wrap:
break-word/anywhere to the document as a while.

In some contexts we would rather add a horizontal scrollbar (code
blocks), or elide the excess text with an ellipsis (sidebar). Those
still work as expected.

This version is nice in that it doesn't need to worry about zeros, and thus doesn't have any error cases.

Now that we have (unstable) methods for this, we don't need the bespoke trait methods for it in the `bignum` implementation.

…unctions in metadata.rs.

…ft-updates, r=Mark-Simulacrum

Clarifications in the target tier policy

We've added several targets since the introduction of the target tier policy. Based on experiences of those adding such targets, and discussions around such additions, clarify the target tier policy to make it easier to follow and work with.

None of these changes substantively change the requirements on targets. (In some cases the changes do direct target submitters to follow specific process requirements for the addition of a target, such as how to respond to requirements, where to put target-specific documentation, or what should appear in that documentation. Those changes are procedural in nature and document the procedures we already direct people to follow.)

- Clarify how to quote and respond to the target tier policy requirements. Several times, people have seemed unclear on how to respond to some of the policy requirements, particularly those that just state things the target developers must *not* do (e.g. not posting to PRs that break the target). Add a note that such requirements just need acknowledgement, nothing more.
- Clarify dependency requirements in the face of cross-compilation. I previously phrased this confusingly in terms of "host tools", since that is the case where an exception applies (allowing proprietary target libraries commonly used by binaries for the target). Rephrase it to apply equally to cross-compilation. This doesn't change the net effect of the requirements, since other requirements already cover the dependencies of the Rust toolchain.
- Clarify documentation about running binaries. The requirement for target documentation talks about "running tests", but tier 3 targets often don't support running the full testsuite, and in practice the documentation for how to run an individual binary may be more useful. Change "running tests" to "running binaries, or running tests".
- Explain where to place target-specific documentation (a subdirectory of platform-support, with a link from the platform-support entry for the target).
- Add a template for target-specific documentation.

…ne_of_attr, r=Aaron1011

Implement `#[rustc_must_implement_one_of]` attribute

This PR adds a new attribute — `#[rustc_must_implement_one_of]` that allows changing the "minimal complete definition" of a trait. It's similar to GHC's minimal `{-# MINIMAL #-}` pragma, though `#[rustc_must_implement_one_of]` is weaker atm.

Such attribute was long wanted. It can be, for example, used in `Read` trait to make transitions to recently added `read_buf` easier:
```rust
#[rustc_must_implement_one_of(read, read_buf)]
pub trait Read {
    fn read(&mut self, buf: &mut [u8]) -> Result<usize> {
        let mut buf = ReadBuf::new(buf);
        self.read_buf(&mut buf)?;
        Ok(buf.filled_len())
    }

    fn read_buf(&mut self, buf: &mut ReadBuf<'_>) -> Result<()> {
        default_read_buf(|b| self.read(b), buf)
    }
}

impl Read for Ty0 {}
//^ This will fail to compile even though all `Read` methods have default implementations

// Both of these will compile just fine
impl Read for Ty1 {
    fn read(&mut self, buf: &mut [u8]) -> Result<usize> { /* ... */ }
}
impl Read for Ty2 {
    fn read_buf(&mut self, buf: &mut ReadBuf<'_>) -> Result<()> { /* ... */ }
}
```

For now, this is implemented as an internal attribute to start experimenting on the design of this feature. In the future we may want to extend it:
- Allow arbitrary requirements like `a | (b & c)`
- Allow multiple requirements like
  - ```rust
    #[rustc_must_implement_one_of(a, b)]
    #[rustc_must_implement_one_of(c, d)]
    ```
- Make it appear in rustdoc documentation
- Change the syntax?
- Etc

Eventually, we should make an RFC and make this (or rather similar) attribute public.

---

I'm fairly new to compiler development and not at all sure if the implementation makes sense, but at least it passes tests :)

…-debuginfo, r=petrochenkov

rustc_codegen_llvm: Remove (almost) unused span parameter from many functions in metadata.rs

Many functions and intermediate data structures in `rustc_codegen_llvm/src/debuginfo/metadata.rs` take a span parameter that is only used for providing a span to a `span_bug!()` invocation, in case the debuginfo typemap gets corrupted. However, this span does not really convey useful information as it just points to the first point a type is used -- and half of the time is initialized to `DUMMY_SP`.

This PR removes this span parameter from the module.

It also removes the following unused parameters from `composite_type_metadata()` together with an outdated comment:

```rust
    // Ignore source location information as long as it
    // can't be reconstructed for non-local crates.
    _file_metadata: &'ll DIFile,
    _definition_span: Span,
```

…gisa

Correct minor typos in some long error code explanations

Just a little nitpick to improve the long explanations of the error codes. 😊

Enable wrapping words by default

Faced with a very long word, browsers will let it overflow its
box horizontally rather than break it in the middle. We essentially
never want that behavior. We would rather break the word and keep it
inside its horizontal limits. So we apply a default overflow-wrap:
break-word/anywhere to the document as a while.

In some contexts we would rather add a horizontal scrollbar (code
blocks), or elide the excess text with an ellipsis (sidebar). Those
still work as expected.

Fixes rust-lang#92771

[Some related discussion](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/wrap.20.2F.20overflow.20.2F.20scroll) and a related issue: rust-lang#92421.

Demo: https://rustdoc.crud.net/jsha/overflow-wrap/std/iter/trait.Iterator.html#method.try_find

r? ``@GuillaumeGomez``

…, r=Mark-Simulacrum

Rename environment variable for overriding rustc version

…k-Simulacrum

Remove LLVMRustMarkAllFunctionsNounwind

This was originally introduced in rust-lang#10916 as a way to remove all landing
pads when performing LTO. However this is no longer necessary today
since rustc properly marks all functions and call-sites as nounwind
where appropriate.

In fact this is incorrect in the presence of `extern "C-unwind"` which
must create a landing pad when compiled with `-C panic=abort` so that
foreign exceptions are caught and properly turned into aborts.

…aumeGomez

rustdoc: Remove `collect` in `html::markdown::parse`

Add `log2` and `log10` to `NonZeroU*`

This version is nice in that it doesn't need to worry about zeros, and thus doesn't have any error cases.

cc `int_log` tracking issue rust-lang#70887

(I didn't add them to `NonZeroI*` despite it being on `i*` since allowing negatives bring back the error cases again.)

…mulacrum

Use `carrying_{mul|add}` in `num::bignum`

Now that we have (unstable) methods for this, we don't need the bespoke trait methods for it in the `bignum` implementation.

cc rust-lang#85532