* Remove `prefix` param of `document_short/full`, `render_markdown`, as its always an empty string.
* Remove `Option` wrapping of `document_short` `parent`, as its always `Some`.
Rustdoc doesn't work on IE11. It's been broken for months, it isn't supported
by the [tiered browser support list], it's even more severely broken on other
Rust websites, and IE11 doesn't support the `<details>` tag that we want
to use.
In the interest of honesty, let's give an actual error message for anyone
on IE11.
[tiered browser support list]: https://github.com/rust-lang/rfcs/blob/master/text/1985-tiered-browser-support.md
Remove unused footer section
I realized yesterday while working on docs.rs that rustdoc was generating a "footer"section that it doesn't use. No need to keep it then.
r? `@jyn514`
Introduce CompileMonoItem DepNode
This is likely required for allowing efficient hot code swap support in cg_clif's jit mode. My prototype currently requires re-compiling all functions, which is both slow and uses a lot of memory as there is not support for freeing the memory used by replaced functions yet.
cc https://github.com/bjorn3/rustc_codegen_cranelift/issues/1087
Match against attribute name when validating attributes
Extract attribute name once and match it against symbols that are being
validated, instead of using `Session::check_name` for each symbol
individually.
Assume that all validated attributes are used, instead of marking them
as such, since the attribute check should be exhaustive.
Instead of creating a JS toggle, this injects details/summary for
sub-variants of enums. This also fixes the CSS so that the toggle button
does not jump when expanding/collapsing.
rustdoc: Reduce visual weight of attributes.
Followup from #83337. As part of that PR, we stopped hiding attributes behind a toggle, because most things have just zero or one attributes. However, this made clear that the current rendering of attributes emphasizes them a lot, which distracts from function signatures. This PR changes their color of attributes to be the same as the toggles, and reduces their font weight.
This also removes `#[lang]` from the list of ALLOWED_ATTRIBUTES. This attribute is an implementation detail rather than part of the public-facing documentation.
Demo at https://hoffman-andrews.com/rust/de-emph-attr/std/string/struct.String.html#method.trim
un-double `return` on try_err
This fixes#7103 by looking at the parent expression and omitting the "return " in the suggestion when its already a `return` expression.
---
changelog: none
Stablize `non-ascii-idents`
This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467).
r? `@Manishearth`
Add `Unsupported` to `std::io::ErrorKind`
I noticed a significant portion of the uses of `ErrorKind::Other` in std is for unsupported operations.
The notion that a specific operation is not available on a target (and will thus never succeed) seems semantically distinct enough from just "an unspecified error occurred", which is why I am proposing to add the variant `Unsupported` to `std::io::ErrorKind`.
**Implementation**:
The following variant will be added to `std::io::ErrorKind`:
```rust
/// This operation is unsupported on this platform.
Unsupported
```
`std::io::ErrorKind::Unsupported` is an error returned when a given operation is not supported on a platform, and will thus never succeed; there is no way for the software to recover. It will be used instead of `Other` where appropriate, e.g. on wasm for file and network operations.
`decode_error_kind` will be updated to decode operating system errors to `Unsupported`:
- Unix and VxWorks: `libc::ENOSYS`
- Windows: `c::ERROR_CALL_NOT_IMPLEMENTED`
- WASI: `wasi::ERRNO_NOSYS`
**Stability**:
This changes the kind of error returned by some functions on some platforms, which I think is not covered by the stability guarantees of the std? User code could depend on this behavior, expecting `ErrorKind::Other`, however the docs already mention:
> Errors that are `Other` now may move to a different or a new `ErrorKind` variant in the future. It is not recommended to match an error against `Other` and to expect any additional characteristics, e.g., a specific `Error::raw_os_error` return value.
The most recent variant added to `ErrorKind` was `UnexpectedEof` in `1.6.0` (almost 5 years ago), but `ErrorKind` is marked as `#[non_exhaustive]` and the docs warn about exhaustively matching on it, so adding a new variant per se should not be a breaking change.
The variant `Unsupported` itself could be marked as `#[unstable]`, however, because this PR also immediately uses this new variant and changes the errors returned by functions I'm inclined to agree with the others in this thread that the variant should be insta-stabilized.
Add `Unsupported` to `std::io::ErrorKind`
I noticed a significant portion of the uses of `ErrorKind::Other` in std is for unsupported operations.
The notion that a specific operation is not available on a target (and will thus never succeed) seems semantically distinct enough from just "an unspecified error occurred", which is why I am proposing to add the variant `Unsupported` to `std::io::ErrorKind`.
**Implementation**:
The following variant will be added to `std::io::ErrorKind`:
```rust
/// This operation is unsupported on this platform.
Unsupported
```
`std::io::ErrorKind::Unsupported` is an error returned when a given operation is not supported on a platform, and will thus never succeed; there is no way for the software to recover. It will be used instead of `Other` where appropriate, e.g. on wasm for file and network operations.
`decode_error_kind` will be updated to decode operating system errors to `Unsupported`:
- Unix and VxWorks: `libc::ENOSYS`
- Windows: `c::ERROR_CALL_NOT_IMPLEMENTED`
- WASI: `wasi::ERRNO_NOSYS`
**Stability**:
This changes the kind of error returned by some functions on some platforms, which I think is not covered by the stability guarantees of the std? User code could depend on this behavior, expecting `ErrorKind::Other`, however the docs already mention:
> Errors that are `Other` now may move to a different or a new `ErrorKind` variant in the future. It is not recommended to match an error against `Other` and to expect any additional characteristics, e.g., a specific `Error::raw_os_error` return value.
The most recent variant added to `ErrorKind` was `UnexpectedEof` in `1.6.0` (almost 5 years ago), but `ErrorKind` is marked as `#[non_exhaustive]` and the docs warn about exhaustively matching on it, so adding a new variant per se should not be a breaking change.
The variant `Unsupported` itself could be marked as `#[unstable]`, however, because this PR also immediately uses this new variant and changes the errors returned by functions I'm inclined to agree with the others in this thread that the variant should be insta-stabilized.
