unwrap_or lint corrected

[Nicholas-Baron]

#78814 (comment)

This pull request fixes the lint from clippy where unwrap_or could be better done as a unwrap_or_else or a unwrap_or_default.

[rust-highfive]

Some changes occurred in intra-doc-links.

cc @jyn514

[rust-highfive]

r? @lcnr

(rust_highfive has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

@bors try @rust-timer queue

It seems plausible that gating the method call could actually hurt in some cases (since it changes operation order somewhat). Probably doesn't matter in practice, though.

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 1c7498c3e57e25363d0b7d3a716f7e1234604c4f with merge 3de0a1b5392ebbbfc1249710da2f62232983e9a9...

[bors]

☀️ Try build successful - checks-actions
Build commit: 3de0a1b5392ebbbfc1249710da2f62232983e9a9 (3de0a1b5392ebbbfc1249710da2f62232983e9a9)

[rust-timer]

Queued 3de0a1b5392ebbbfc1249710da2f62232983e9a9 with parent a601302, future comparison URL.

[rust-timer]

Finished benchmarking try commit (3de0a1b5392ebbbfc1249710da2f62232983e9a9): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never
@rustbot modify labels: +S-waiting-on-review -S-waiting-on-perf

[Nicholas-Baron]

The following changes are reversions of unwrap_or_else to unwrap_or.

[the8472]

Git does support bundling changes for multiple files into a single commit.

[rust-log-analyzer]

The job mingw-check of your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[command]/usr/bin/git submodule foreach --recursive git config --local --name-only --get-regexp 'http\.https\:\/\/github\.com\/\.extraheader' && git config --local --unset-all 'http.https://github.com/.extraheader' || :
[command]/usr/bin/git config --local http.https://github.com/.extraheader AUTHORIZATION: basic ***
##[endgroup]
##[group]Fetching the repository
[command]/usr/bin/git -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules --depth=2 origin +a1480fe8dc3999b78d2d46fc4b19d21261056ff3:refs/remotes/pull/78825/merge
---
configure: rust.channel         := nightly
configure: rust.debug-assertions := True
configure: llvm.assertions      := True
configure: dist.missing-tools   := True
configure: build.configure-args := ['--enable-sccache', '--disable-manage-submodu ...
configure: writing `config.toml` in current directory
configure: 
configure: run `python /checkout/x.py --help`
configure: 
---
skip untracked path cpu-usage.csv during rustfmt invocations
skip untracked path src/doc/book/ during rustfmt invocations
skip untracked path src/doc/rust-by-example/ during rustfmt invocations
skip untracked path src/llvm-project/ during rustfmt invocations
Diff in /checkout/compiler/rustc_codegen_llvm/src/intrinsic.rs at line 1724:
 // stuffs.
 fn int_type_width_signed(ty: Ty<'_>, cx: &CodegenCx<'_, '_>) -> Option<(u64, bool)> {
     match ty.kind() {
-        ty::Int(t) => Some((
-            t.bit_width().unwrap_or(u64::from(cx.tcx.sess.target.pointer_width)),
Running `"/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/rustfmt" "--config-path" "/checkout" "--edition" "2018" "--unstable-features" "--skip-children" "--check" "/checkout/compiler/rustc_codegen_llvm/src/intrinsic.rs"` failed.
If you're running `tidy`, try again with `--bless`. Or, if you just want to format code, run `./x.py fmt` instead.
-        )),
-        )),
-        ty::Uint(t) => Some((
-            t.bit_width().unwrap_or(u64::from(cx.tcx.sess.target.pointer_width)),
-        )),
-        )),
+        ty::Int(t) => {
+            Some((t.bit_width().unwrap_or(u64::from(cx.tcx.sess.target.pointer_width)), true))
+        }
+        ty::Uint(t) => {
+            Some((t.bit_width().unwrap_or(u64::from(cx.tcx.sess.target.pointer_width)), false))
         _ => None,
     }
 }
failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test --stage 2 src/tools/tidy
failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test --stage 2 src/tools/tidy
Build completed unsuccessfully in 0:00:14
== clock drift check ==
  local time: Sat Nov  7 21:01:25 UTC 2020
  network time: Sat, 07 Nov 2020 00:15:56 GMT
== end clock drift check ==
##[error]Process completed with exit code 1.
[command]/usr/bin/git version
git version 2.29.2
[command]/usr/bin/git config --local --name-only --get-regexp core\.sshCommand
[command]/usr/bin/git submodule foreach --recursive git config --local --name-only --get-regexp 'core\.sshCommand' && git config --local --unset-all 'core.sshCommand' || :

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @rust-lang/infra. (Feature Requests)

[Nicholas-Baron]

@the8472 I rolled up all 20 of my changes into one revert commit. Yes, I have wasted my time with 20 one line commits and I really should learn from that.

[lcnr]

LGTM. I do however think 14 commits is a bit too much for this PR, r=me after you did some squashing here

[Nicholas-Baron]

@lcnr Squashed this PR down to 4 commits and rebased it onto the latest master.

[Mark-Simulacrum]

Last 3 commits look like they'd just be noise in the commit log? Is there a reason why they were kept?

[Nicholas-Baron]

Last 3 commits look like they'd just be noise in the commit log? Is there a reason why they were kept?

The 2nd commit is a revert explaining why. I could merge the last 3 into one commit.

[Mark-Simulacrum]

I do not think there should be more than 1 commit here, personally. I think it is useful to have standalone commits if they have distinct contents from other commits in the PR, which is not the case here. Generally in-PR reverts just don't make sense for preserving indefinitely.

[Nicholas-Baron]

I do not think there should be more than 1 commit here, personally. I think it is useful to have standalone commits if they have distinct contents from other commits in the PR, which is not the case here. Generally in-PR reverts just don't make sense for preserving indefinitely.

Ok, squashing into 1 commit

[lcnr]

Thanks 👍

@bors r+

[bors]

📌 Commit 261ca04 has been approved by lcnr

[jyn514]

@Nicholas-Baron btw, there were recently a bunch of clippy bugs fixed, so I would expect x.py clippy --fix to have low-hanging fruit (previously clippy would error out while applying suggestions).

[bors]

⌛ Testing commit 261ca04 with merge d4ea0b3...

[bors]

☀️ Test successful - checks-actions
Approved by: lcnr
Pushing d4ea0b3 to master...