Fix typo in Default trait docs: Provides -> Provide
An earlier commit (99ed06e) accidentally changed this paragraph from the original, imperative `Provide` to the present tense `Provides`. The latter is indeed the standard for Rustdoc comments relating to a function or method, but this snippet is introducing the `Default` trait in general terms and not talking about any particular function. I believe this change was likely made in error and should be reverted.
Dogfood or_patterns in the standard library
We can start using `or_patterns` in the standard library as a step toward stabilization.
cc #54883 @Centril
reword Miri validity errors: undefined -> uninitialized
I don't think we say "undefined value" or anything like that anywhere in the docs or so, but we do use the term "uninitialized memory", so I think we should do the same here.
Longer-term, I think we should also internally rename "undef" to "uninit".
r? @oli-obk
Hides default fns inside Fuse impl to avoid exposing it to any crate
Fixes#70796
@cuviper I've added some default, private traits to do the job for us. If required, I can expose them to a specific visibility if you want to call these functions for #70332
r? @cuviper
Do not reuse post LTO products when exports change
Do not reuse post lto products when exports change
Generalizes code from PR #67020, which handled case when imports change.
Fix#69798
An earlier commit (99ed06e) accidentally changed this paragraph from the
original, imperative "Provide" to the present tense "Provides". The
latter is indeed the standard for Rustdoc comments relating to a
function or method, but this snippet is introducing the Default trait in
general terms and not talking about any particular function. I believe
this change was likely made in error and should be reverted.
Rollup of 5 pull requests
Successful merges:
- #70611 (Add long error explanation for E0708 #61137)
- #71197 (Don't use the HirId to NodeId map in MIR)
- #71211 (Update cargo)
- #71219 (Minor fixes to doc comments of 'VecDeque')
- #71221 (Dogfood or_patterns in rustdoc)
Failed merges:
r? @ghost
Minor fixes to doc comments of 'VecDeque'
1. Changed descriptions of `fn get` & `fn get_mut`.
Since both of these functions are returning references, and not the owned value, I thought the doc comments could be fixed to be consistent with doc comments of `fn front` & `fn front_mut`.
2. Other changes are minor fixes or additions for clarification.
Thank you for taking a look :)
Update cargo
3 commits in 74e3a7d5b756d7c0e94399fc29fcd154e792c22a..ebda5065ee8a1e46801380abcbac21a25bc7e755
2020-04-13 20:41:52 +0000 to 2020-04-16 14:28:43 +0000
- Don't use debug display for error object. (rust-lang/cargo#8119)
- Add backwards-compatibility for old cargo-tree flags. (rust-lang/cargo#8115)
- Try to avoid panics on buggy (?) clocks (rust-lang/cargo#8114)
Don't use the HirId to NodeId map in MIR
Another step towards not having to build a `HirId` to `NodeId` map other than for doc and RLS purposes.
We are currently sorting `unsafe` blocks by `NodeId` in `check_unsafety`; change it to sorting by `Span` instead; this passes the tests, but better ideas are welcome.
In addition, simplify the split between the used and unused `unsafe` blocks for readability and less sorting.
cc https://github.com/rust-lang/rust/issues/50928
1. Changed descriptions of `fn get` & `fn get_mut`.
Since both of these functions are returning references, and not the owned value, I thought the doc comments could be fixed to be consistent with doc comments of `fn front` & `fn front_mut`.
2. Other changes are minor fixes or additions for clarification.
Thank you for taking a look :)
Rollup of 5 pull requests
Successful merges:
- #70566 (Don't bail out before linting in generic contexts.)
- #71141 (Provide better compiler output when using `?` on `Option` in fn returning `Result` and vice-versa)
- #71149 (remove an impossible branch from check_consts)
- #71179 (fix more clippy warnings)
- #71191 (Clean up E0520 explanation)
Failed merges:
r? @ghost
remove an impossible branch from check_consts
All function calleess are either `FnPtr` or `FnDef`, so we can remove the alternative from check_consts and just make it ICE instead.
Remove a stack frame from .await calls
The stack frames when `.await`ing one async fn from another currently look like this:
```
12: foo:🅱️:{{closure}}
at src/main.rs:2
13: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66
14: core::future::poll_with_context
at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84
15: foo:🅰️:{{closure}}
at src/main.rs:6
```
Since the move away from using TLS to pass the Context around, it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame, but that seems significantly harder to deal with.
It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.
Rollup of 6 pull requests
Successful merges:
- #69903 (Do not ICE in the face of invalid enum discriminant)
- #70354 (Update RELEASES.md for 1.43.0)
- #70774 (End cleanup on rustdoc-js tools)
- #70990 (Improve rustdoc source code a bit)
- #71145 (Add illumos triple)
- #71166 (Clean up E0518 explanation)
Failed merges:
r? @ghost
Add illumos triple
This fixesrust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions, several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target.
Work originally started by @jasonbking, with subsequent additions by @pfmooney and @jclulow.
