Mara Bos [Wed, 21 Apr 2021 21:06:20 +0000 (23:06 +0200)]
Rollup merge of #84380 - Smittyvb:rdoc-title-order, r=jsha
Write Rustdoc titles like "x in crate::mod - Rust"
This makes Rustdoc titles for items be like "Widget in cratename::blah::foo - Rust". Titles for modules and other non-items are unchanged, and still read like "cratename::blah::foo - Rust". This makes managing several open Rustdoc tabs easier.
Mara Bos [Wed, 21 Apr 2021 21:06:17 +0000 (23:06 +0200)]
Rollup merge of #84365 - vext01:improve-lto-docstrings, r=petrochenkov
Improve the docstrings of the `Lto` struct.
This change is the result of [this zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Making.20sense.20of.20LTO.20modes.20in.20rustc).
Hopefully it makes things a little clearer. What do you think?
Mara Bos [Wed, 21 Apr 2021 21:06:15 +0000 (23:06 +0200)]
Rollup merge of #84251 - RalfJung:non-zero-const-since, r=kennytm
fix 'const-stable since' for NonZeroU*::new_unchecked
For the unsigned `NonZero` types, `new_unchecked` was const-stable from the start with https://github.com/rust-lang/rust/pull/50808. Fix the docs to accurately reflect that.
I think this `since` is also incorrect:
```rust
#[stable(feature = "from_nonzero", since = "1.31.0")]
impl From<$Ty> for $Int {
```
The signed nonzero types were only stabilized in 1.34, so that `From` impl certainly didn't exist before. But I had enough of digging through git histories after I figured out when `new_unchecked` became const-stable...^^
Mara Bos [Wed, 21 Apr 2021 21:06:14 +0000 (23:06 +0200)]
Rollup merge of #84212 - CDirkx:void, r=m-ou-se
Replace `Void` in `sys` with never type
This PR replaces several occurrences in `sys` of the type `enum Void {}` with the Rust never type (`!`).
The name `Void` is unfortunate because in other languages (C etc.) it refers to a unit type, not an uninhabited type.
Note that the previous stabilization of the never type was reverted, however all uses here are implementation details and not publicly visible.
Mara Bos [Wed, 21 Apr 2021 21:06:12 +0000 (23:06 +0200)]
Rollup merge of #84119 - CDirkx:vxworks, r=m-ou-se
Move `sys::vxworks` code to `sys::unix`
Follow-up to #77666, `sys::vxworks` is almost identical to `sys::unix`, the only differences are the `rand`, `thread_local_dtor`, and `process` implementation. Since `vxworks` is `target_family = unix` anyway, there is no reason for the code not to live inside of `sys::unix` like all the other unix-OSes.
Mara Bos [Wed, 21 Apr 2021 21:06:11 +0000 (23:06 +0200)]
Rollup merge of #84013 - CDirkx:fmt, r=m-ou-se
Replace all `fmt.pad` with `debug_struct`
This replaces any occurrence of:
- `f.pad("X")` with `f.debug_struct("X").finish()`
- `f.pad("X { .. }")` with `f.debug_struct("X").finish_non_exhaustive()`
This is in line with existing formatting code such as
https://github.com/rust-lang/rust/blob/125505306744a0a5bb01d62337260a95d9ff8d57/library/std/src/sync/mpsc/mod.rs#L1470-L1475
Write Rustdoc titles like "x in crate::mod - Rust"
This makes Rustdoc titles for items read like
"x in cratename::blah::foo - Rust". Title for modules and other
non-items are unchanged, and still read like
"doccratenameconst::blah::foo - Rust". This makes managing several open
Rustdoc tabs easier.
Auto merge of #84353 - estebank:as-ref-mir, r=davidtwco
Suggest `.as_ref()` on borrow error involving `Option`/`Result`
When encountering a E0382 borrow error involving an `Option` or `Result`
provide a suggestion to use `.as_ref()` on the prior move location to
avoid the move.
Auto merge of #84363 - Dylan-DPC:rollup-ink2wyq, r=Dylan-DPC
Rollup of 4 pull requests
Successful merges:
- #84337 (Clarify the difference between insert and get_or_insert)
- #84340 (rustdoc: Show nag box on IE11)
- #84345 (Remove comment about doc hack.)
- #84347 (rustdoc: Simplify some document functions)
Rollup merge of #84347 - Swatinem:simplify-document-fns, r=jyn514
rustdoc: Simplify some document functions
* 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`.
Rollup merge of #84340 - notriddle:patch-4, r=GuillaumeGomez
rustdoc: Show nag box on IE11
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
Auto merge of #84295 - richkadel:continue-coverage, r=tmandry
Add coverage to continue statements
`continue` statements were missing coverage. This was particularly
noticeable in a match pattern that contained only a `continue`
statement, leaving the branch appear uncounted. This PR addresses the
problem and adds tests to prove it.
Suggest `.as_ref()` on borrow error involving `Option`/`Result`
When encountering a E0382 borrow error involving an `Option` or `Result`
provide a suggestion to use `.as_ref()` on the prior move location to
avoid the move.
* 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`.
Michael Howell [Mon, 19 Apr 2021 18:40:25 +0000 (11:40 -0700)]
rustdoc: Show nag box on IE10
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
Rollup merge of #84123 - bjorn3:compile_mono_item_dep_node, r=wesleywiser
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
Auto merge of #84091 - tmiasko:check-attrs-sym, r=davidtwco
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.
Auto merge of #84283 - jsha:de-emphasize-attributes, r=GuillaumeGomez
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.
Auto merge of #78880 - CDirkx:not_supported, r=joshtriplett
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.
Don't set fast-math for the SIMD operations we set it for previously
Instead of `fast-math`. `fast-math` implies things like functions not
being able to accept as an argument or return as a result, say, `inf`
which made these functions confusingly named or behaving incorrectly,
depending on how you interpret it. It seems that the intended behaviour
was to set a `afn` flag instead. In doing so we also renamed the
intrinsics to say `_approx` so that it is clear these are not precision
oriented and the users can act accordingly.
`continue` statements were missing coverage. This was particularly
noticeable in a match pattern that contained only a `continue`
statement, leaving the branch appear uncounted. This PR addresses the
problem and adds tests to prove it.
Auto merge of #84207 - SimonSapin:deprecate-core-raw, r=dtolnay
Deprecate the core::raw / std::raw module
It only contains the `TraitObject` struct which exposes components of wide pointer. Pointer metadata APIs are designed to replace this: https://github.com/rust-lang/rust/issues/81513
projects / rust.git / log