bors [Sun, 13 Dec 2020 10:52:29 +0000 (10:52 +0000)]
Auto merge of #79668 - coolreader18:recover-const-impl, r=petrochenkov
Recover on `const impl<> X for Y`
`@leonardo-m` mentioned that `const impl Foo for Bar` could be recovered from in #79287.
I'm not sure about the error strings as they are, I think it should probably be something like the error that `expected_one_of_not_found` makes + the suggestion to flip the keywords, but I'm not sure how exactly to do that. Also, I decided not to try to handle `const unsafe impl` or `unsafe const impl` cause I figured that `unsafe impl const` would be pretty rare anyway (if it's even valid?), and it wouldn't be worth making the code more messy.
bors [Sun, 13 Dec 2020 08:40:07 +0000 (08:40 +0000)]
Auto merge of #79956 - camelid:variant-field-vis, r=petrochenkov
Resolve enum field visibility correctly
Fixes #79593. :tada:
Previously, this code treated enum fields' visibility as if they were
struct fields. However, that's not correct because the visibility of a
struct field with `ast::VisibilityKind::Inherited` is private to the
module it's defined in, whereas the visibility of an *enum* field with
`ast::VisibilityKind::Inherited` is the visibility of the enum it
belongs to.
In HTML, when a button follows an input (in a `form`), if the enter keep is pressed on the input, instead of sending the submit event to the input, it'll create a click event on the button following it, which in this case made the help popup show up whenever "enter" was pressed.
Yuki Okushi [Sun, 13 Dec 2020 02:05:47 +0000 (11:05 +0900)]
Rollup merge of #79984 - Nadrieril:remove-unused-dep, r=jyn514
Remove an unused dependency that made `rustdoc` crash
Whilst struggling with https://github.com/rust-lang/rust/issues/79980 I discovered that this dependency was unused, and that made rustdoc crash. This PR removes it.
Yuki Okushi [Sun, 13 Dec 2020 02:05:45 +0000 (11:05 +0900)]
Rollup merge of #79973 - camelid:rustdoc-search-tab-color, r=GuillaumeGomez
rustdoc light theme: Fix CSS for selected buttons
Fixes #79961.
The background was dark before, which made the text impossible to read.
Now the button doesn't override the background, and the only thing it
does is add a light-blue top border.
Ultimately, the search results tabs now look very similar to how they
used to look.
Yuki Okushi [Sun, 13 Dec 2020 02:05:40 +0000 (11:05 +0900)]
Rollup merge of #79954 - jyn514:normalize-oops, r=Mark-Simulacrum
Fix building compiler docs with stage 0
This regressed in https://github.com/rust-lang/rust/pull/79525 (see https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Can't.20document.20single.20crate).
Yuki Okushi [Sun, 13 Dec 2020 02:05:36 +0000 (11:05 +0900)]
Rollup merge of #79940 - matthiaskrgr:cl15ppy, r=Dylan-DPC
fix more clippy::complexity findings
fix clippy::unnecessary_filter_map
use if let Some(x) = .. instead of ...map(|x|) to conditionally run fns that return () (clippy::option_map_unit_fn)
fix clippy::{needless_bool, manual_unwrap_or}
don't clone types that are copy (clippy::clone_on_copy)
don't convert types into identical types with .into() (clippy::useless_conversion)
use strip_prefix over slicing (clippy::manual_strip)
Yuki Okushi [Sun, 13 Dec 2020 02:05:30 +0000 (11:05 +0900)]
Rollup merge of #79398 - pickfire:keyword, r=Dylan-DPC
Link loop/for keyword
Even though the reference already have all of these, I am just adding related keywords in the see also to let others easily click on the related keyword.
Yuki Okushi [Sun, 13 Dec 2020 02:05:22 +0000 (11:05 +0900)]
Rollup merge of #79360 - wchargin:wchargin-doc-iter-by-reference, r=m-ou-se
std::iter: document iteration over `&T` and `&mut T`
A colleague of mine is new to Rust, and mentioned that it was “slightly
confusing” to figure out what `&mut` does in iterating over `&mut foo`:
```rust
for value in &mut self.my_vec {
// ...
}
```
My colleague had read the `std::iter` docs and not found the answer
there. There is a brief section at the top about “the three forms of
iteration”, which mentions `iter_mut`, but it doesn’t cover the purpose
of `&mut coll` for a collection `coll`. This patch adds an explanatory
section to the docs. I opted to create a new section so that it can
appear after the note that `impl<I: Iterator> IntoIterator for I`, and
it’s nice for the existing “three forms of iteration” to appear near the
top.
Test Plan:
Ran `./x.py doc library/core`, and the result looked good, including
links. Manually copy-pasted the two doctests into the playground and ran
them.
Arlie Davis [Fri, 11 Dec 2020 19:32:48 +0000 (11:32 -0800)]
Improve error handling in `symbols` proc-macro
This improves how the `symbols` proc-macro handles errors.
If it finds an error in its input, the macro does not panic.
Instead, it still produces an output token stream. That token
stream will contain `compile_error!(...)` macro invocations.
This will still cause compilation to fail (which is what we want),
but it will prevent meaningless errors caused by the output not
containing symbols that the macro normally generates.
This solves a small (but annoying) problem. When you're editing
rustc_span/src/symbol.rs, and you get something wrong (dup
symbol name, misordered symbol), you want to get only the errors
that are relevant, not a burst of errors that are irrelevant.
This change also uses the correct Span when reporting errors,
so you get errors that point to the correct place in
rustc_span/src/symbol.rs where something is wrong.
This also adds several unit tests which test the `symbols` proc-macro.
This commit also makes it easy to run the `symbols` proc-macro
as an ordinary Cargo test. Just run `cargo test`. This makes it
easier to do development on the macro itself, such as running it
under a debugger.
This commit also uses the `Punctuated` type in `syn` for parsing
comma-separated lists, rather than doing it manually.
The output of the macro is not changed at all by this commit,
so rustc should be completely unchanged. This just improves
quality of life during development.
Guillaume Gomez [Sat, 12 Dec 2020 22:30:13 +0000 (23:30 +0100)]
Fixes submit event of the search input
In HTML, when a button follows an input, if the enter keep is pressed on the input, instead of sending the submit event to the input, it'll create a click event on the button following it, which in this case made the help popup show up whenever "enter" was pressed.
bors [Sat, 12 Dec 2020 23:01:25 +0000 (23:01 +0000)]
Auto merge of #79976 - jyn514:assertion-failure, r=jyn514
Remove incorrect assert
Fixes an assertion failure when resolving `::std` (or any other crate that uses the `::` style, see https://github.com/rust-lang/rust/pull/79809/files#r541776478, https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/Perf.20failing).
Camelid [Sat, 12 Dec 2020 03:52:51 +0000 (19:52 -0800)]
Resolve enum field visibility correctly
Previously, this code treated enum fields' visibility as if they were
struct fields. However, that's not correct because the visibility of a
struct field with `ast::VisibilityKind::Inherited` is private to the
module it's defined in, whereas the visibility of an *enum* field with
`ast::VisibilityKind::Inherited` is the visibility of the enum it
belongs to.
Aaron Hill [Sat, 12 Dec 2020 20:20:22 +0000 (15:20 -0500)]
Properly capture trailing 'unglued' token
If we try to capture the `Vec<u8>` in `Option<Vec<u8>>`, we'll
need to capture a `>` token which was 'unglued' from a `>>` token.
The processing of unglueing a token for parsing purposes bypasses the
usual capturing infrastructure, so we currently lose the trailing `>`.
As a result, we fall back to the reparsed `TokenStream`, causing us to
lose spans.
This commit makes token capturing keep track of a trailing 'unglued'
token. Note that we don't need to care about unglueing except at the end
of the captured tokens - if we capture both the first and second unglued
tokens, then we'll end up capturing the full 'glued' token, which
already works correctly.
bors [Sat, 12 Dec 2020 19:41:56 +0000 (19:41 +0000)]
Auto merge of #79957 - jyn514:smaller-span, r=GuillaumeGomez
[rustdoc] Calculate span information on demand instead of storing it ahead of time
This brings `size_of<clean::types::Span>()` down from over 100 bytes (!!) to only 12, the same as rustc. It brings `Item` down even more, from `784` to `680`.
~~TODO: I need to figure out how to do this for the JSON backend too. That uses `From` impls everywhere, which don't allow passing in the `Session` as an argument. `@P1n3appl3,` `@tmandry,` maybe one of you have ideas?~~ Figured it out, fortunately only two functions needed to be changed. I like the `convert_x()` format better than `From` everywhere but I'm open to feedback.
running 396 tests
..................................................2020-11-23T12:12:37.735649Z ERROR compiletest::runtest: fatal error, panic: "failed to run tidy - is it installed? - No such file or directory (os error 2)"
F................................................. 100/396
.................................................................................................... 200/396
.................................................................................................... 300/396
...............................i...............2020-11-23T12:15:00.271271Z ERROR compiletest::runtest: fatal error, panic: "failed to run tidy - is it installed? - No such file or directory (os error 2)"
F................................................
```
------------------------------------------
stderr:
------------------------------------------
4: `@has` check failed
`XPATH PATTERN` did not match
// `@has` - '//*[`@class="rust` fn"]' 'pub fn f(callback: fn(len: usize, foo: u32))'
Encountered 1 errors
------------------------------------------
info: generating a diff against nightly rustdoc
failed to run tidy - is it installed? - Permission denied (os error 13)
failed to run tidy - is it installed? - Permission denied (os error 13)
# a diff without running `tidy`
```
running 396 tests
..................................................2020-11-23T12:12:37.735649Z ERROR compiletest::runtest: fatal error, panic: "failed to run tidy - is it installed? - No such file or directory (os error 2)"
F................................................. 100/396
.................................................................................................... 200/396
.................................................................................................... 300/396
...............................i...............2020-11-23T12:15:00.271271Z ERROR compiletest::runtest: fatal error, panic: "failed to run tidy - is it installed? - No such file or directory (os error 2)"
F................................................
```
------------------------------------------
stderr:
------------------------------------------
4: @has check failed
`XPATH PATTERN` did not match
// @has - '//*[@class="rust fn"]' 'pub fn f(callback: fn(len: usize, foo: u32))'
Encountered 1 errors
------------------------------------------
info: generating a diff against nightly rustdoc
failed to run tidy - is it installed? - Permission denied (os error 13)
failed to run tidy - is it installed? - Permission denied (os error 13)
# a diff without running `tidy`
```
bors [Sat, 12 Dec 2020 12:36:18 +0000 (12:36 +0000)]
Auto merge of #79169 - LeSeulArtichaut:ty-lib, r=nikomatsakis
Create `rustc_type_ir`
Decided to start small 😄
This PR creates a `rustc_type_ir` crate as part of the WG-Traits plan to create a shared type library.
~~There already exists a `rustc_ty` crate, so I named the new crate `rustc_ty_library`. However I think it would make sense to rename the current `rustc_ty` to something else (e.g. `rustc_ty_passes`) to free the name for this new crate.~~
Rich Kadel [Sat, 12 Dec 2020 02:28:37 +0000 (18:28 -0800)]
Fixes reported bugs in Rust Coverage
Fixes: #79569 Fixes: #79566 Fixes: #79565
For the first issue (#79569), I got hit a `debug_assert!()` before
encountering the reported error message (because I have `debug = true`
enabled in my config.toml).
The assertion showed me that some `SwitchInt`s can have more than one
target pointing to the same `BasicBlock`.
I had thought that was invalid, but since it seems to be possible, I'm
allowing this now.
I added a new test for this.
----
In the last two cases above, both tests (intentionally) fail to compile,
but the `InstrumentCoverage` pass is invoked anyway.
The MIR starts with an `Unreachable` `BasicBlock`, which I hadn't
encountered before. (I had assumed the `InstrumentCoverage` pass
would only be invoked with MIRs from successful compilations.)
I don't have test infrastructure set up to test coverage on files that
fail to compile, so I didn't add a new test.
bors [Sat, 12 Dec 2020 02:40:17 +0000 (02:40 +0000)]
Auto merge of #79931 - RalfJung:no-redundant-storage-live, r=oli-obk
make redundant StorageLive UB
The interesting behavior of StorageLive in loops (https://github.com/rust-lang/rust/issues/42371) has been fixed, so we can now finally make it a hard error to mark a local as live that is already live. :)
bors [Sat, 12 Dec 2020 00:23:29 +0000 (00:23 +0000)]
Auto merge of #79553 - sexxi-goose:mir_min_cap_writeback, r=nikomatsakis
Capture precise paths in THIR and MIR
This PR allows THIR and MIR to use the result of the new capture analysis to actually capture precise paths
To achieve we:
- Writeback min capture results to TypeckResults
- Move handling upvars to PlaceBuilder in mir_build
- Lower precise paths in THIR build by reading min_captures
- Search for ancestors in min_capture when trying to build a MIR place which starts off of an upvar
bors [Fri, 11 Dec 2020 22:00:00 +0000 (22:00 +0000)]
Auto merge of #79349 - Nemo157:issue-79201, r=jyn514
Apply `doc(cfg)` from parent items while collecting trait impls
Because trait impls bypass the standard `clean` hierarchy they do not participate in the `propagate_doc_cfg` pass, so instead we need to pre-collect all possible `doc(cfg)` attributes that will apply to them when cleaning.
bors [Fri, 11 Dec 2020 12:30:05 +0000 (12:30 +0000)]
Auto merge of #79910 - RalfJung:abort-msg, r=oli-obk
CTFE: tweak abort-on-uninhabited message
Having an "aborted execution:" makes it more consistent with the `Abort` terminator saying "the program aborted execution". Right now, at least one of the two errors will look weird in Miri.
bors [Fri, 11 Dec 2020 10:20:43 +0000 (10:20 +0000)]
Auto merge of #79915 - Aaron1011:fix/fix-reuse-def-path-hash, r=petrochenkov
Use `def_path_hash_to_def_id` when re-using a `RawDefId`
Fixes #79890
Previously, we just copied a `RawDefId` from the 'old' map to the 'new'
map. However, the `RawDefId` for a given `DefPathHash` may be different
in the current compilation session. Using `def_path_hash_to_def_id`
ensures that the `RawDefId` we use is valid in the current session.
bors [Fri, 11 Dec 2020 07:54:35 +0000 (07:54 +0000)]
Auto merge of #79893 - RalfJung:forget-windows, r=oli-obk
Windows TLS: ManuallyDrop instead of mem::forget
The Windows TLS implementation still used `mem::forget` instead of `ManuallyDrop`, leading to the usual problem of "using" the `Box` when it should not be used any more.
bors [Fri, 11 Dec 2020 05:34:07 +0000 (05:34 +0000)]
Auto merge of #79927 - tmandry:rollup-pwn4b1v, r=tmandry
Rollup of 11 pull requests
Successful merges:
- #77027 (Improve documentation for `std::{f32,f64}::mul_add`)
- #79375 (Make the kernel_copy tests more robust/concurrent.)
- #79639 (Add long explanation for E0212)
- #79698 (Add tracking issue template for library features.)
- #79809 (Dogfood `str_split_once()`)
- #79851 (Clarify the 'default is only allowed on...' error)
- #79858 (Update const-fn doc in unstable-book)
- #79860 (Clarify that String::split_at takes a byte index.)
- #79871 (Fix small typo in `wrapping_shl` documentation)
- #79896 (Make search results tab and help button focusable with keyboard)
- #79917 (Use Symbol for inline asm register class names)
Tyler Mandry [Fri, 11 Dec 2020 05:33:14 +0000 (21:33 -0800)]
Rollup merge of #79860 - rust-lang:frewsxcv-patch-2, r=jyn514
Clarify that String::split_at takes a byte index.
To someone skimming through the `String` docs and only reads the first line, the person could interpret "index" to be "char index". Later on in the docs it clarifies, but by adding "byte" it removes that ambiguity.
Tyler Mandry [Fri, 11 Dec 2020 05:33:12 +0000 (21:33 -0800)]
Rollup merge of #79858 - sasurau4:doc/update-unstable-book-const-fn, r=oli-obk
Update const-fn doc in unstable-book
Fix #79691
I couldn't find suitable examples. It seems that `const_fn` feature-gate used only following place. https://github.com/rust-lang/rust/blob/810324d1f31eb8d75e8f0044df720652986ef133/compiler/rustc_ast_passes/src/feature_gate.rs#L560-L562
And example like following emits [E0379](https://doc.rust-lang.org/error-index.html#E0379).
```rust
#![feature(const_fn)]
trait Foo {
const fn bar() -> Self;
}
```
Any other suitable example exists, please let me know.
Tyler Mandry [Fri, 11 Dec 2020 05:33:10 +0000 (21:33 -0800)]
Rollup merge of #79851 - camelid:better-error-for-default-fn, r=davidtwco
Clarify the 'default is only allowed on...' error
Code like
impl Foo {
default fn foo() {}
}
will trigger the error
error: `default` is only allowed on items in `impl` definitions
--> src/lib.rs:5:5
|
5 | default fn foo() {}
| -------^^^^^^^^^
| |
| `default` because of this
but that's very confusing! I *did* put it on an item in an impl!
So this commit changes the message to
error: `default` is only allowed on items in trait impls
--> src/lib.rs:5:5
|
5 | default fn foo() {}
| -------^^^^^^^^^
| |
| `default` because of this
Tyler Mandry [Fri, 11 Dec 2020 05:33:08 +0000 (21:33 -0800)]
Rollup merge of #79809 - Eric-Arellano:split-once, r=matklad
Dogfood `str_split_once()`
Part of https://github.com/rust-lang/rust/issues/74773.
Beyond increased clarity, this fixes some instances of a common confusion with how `splitn(2)` behaves: the first element will always be `Some()`, regardless of the delimiter, and even if the value is empty.
Given this code:
```rust
fn main() {
let val = "...";
let mut iter = val.splitn(2, '=');
println!("Input: {:?}, first: {:?}, second: {:?}", val, iter.next(), iter.next());
}
```
Tyler Mandry [Fri, 11 Dec 2020 05:33:06 +0000 (21:33 -0800)]
Rollup merge of #79698 - m-ou-se:libs-tracking-issue-template, r=KodrAus
Add tracking issue template for library features.
This adds a issue template for a library tracking issue.
There's already a template for tracking issues, but it's mostly geared towards compiler/language features. A separate template makes it a bit easier to make sure it matches with the process we use for library changes.
Main differences:
- Added a note about how small library features can be added without RFC, and removed the parts that assume there's an RFC.
- Merged the 'Steps' and 'History' sections: Library features are often small enough that there's no multiple steps planned ahead of time.
- Removed the section about avoiding large discussions and opening separate issues for problems with the feature. Library features are usually focussed enough that the discussion about a feature is best kept together in the tracking issue.
- Removed links to the rustc-dev-guide, which are specific to changes in the compiler and language.
Tyler Mandry [Fri, 11 Dec 2020 05:33:02 +0000 (21:33 -0800)]
Rollup merge of #79375 - vext01:kernel-copy-temps, r=bjorn3
Make the kernel_copy tests more robust/concurrent.
These tests write to the same filenames in /tmp and in some cases these files don't get cleaned up properly. This caused issues for us when different users run the tests on the same system, e.g.:
```
---- sys::unix::kernel_copy::tests::bench_file_to_file_copy stdout ----
thread 'sys::unix::kernel_copy::tests::bench_file_to_file_copy' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', library/std/src/sys/unix/kernel_copy/tests.rs:71:10
---- sys::unix::kernel_copy::tests::bench_file_to_socket_copy stdout ----
thread 'sys::unix::kernel_copy::tests::bench_file_to_socket_copy' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', library/std/src/sys/unix/kernel_copy/tests.rs💯10
```
Use `std::sys_common::io__test::tmpdir()` to solve this.
bors [Fri, 11 Dec 2020 03:08:32 +0000 (03:08 +0000)]
Auto merge of #79656 - jnqnfe:ordering, r=sfackler
Add some core::cmp::Ordering helpers
...to allow easier equal-to-or-greater-than and less-than-or-equal-to
comparisons.
Prior to Rust 1.42 a greater-than-or-equal-to comparison might be written
either as a match block, or a traditional conditional check like this:
```rust
if cmp == Ordering::Equal || cmp == Ordering::Greater {
// Do something
}
```
Which requires two instances of `cmp`. Don't forget that while `cmp` here
is very short, it could be something much longer in real use cases.
From Rust 1.42 a nicer alternative is possible:
```rust
if matches!(cmp, Ordering::Equal | Ordering::Greater) {
// Do something
}
```
The commit adds another alternative which may be even better in some cases:
```rust
if cmp.is_equal_or_greater() {
// Do something
}
```
The earlier examples could be cleaner than they are if the variants of
`Ordering` are imported such that `Equal`, `Greater` and `Less` can be
referred to directly, but not everyone will want to do that.
The new solution can shorten lines, help avoid logic mistakes, and avoids
having to import `Ordering` / `Ordering::*`.
bors [Thu, 10 Dec 2020 23:43:20 +0000 (23:43 +0000)]
Auto merge of #77801 - fusion-engineering-forks:pin-mutex, r=Mark-Simulacrum
Enforce no-move rule of ReentrantMutex using Pin and fix UB in stdio
A `sys_common::ReentrantMutex` may not be moved after initializing it with `.init()`. This was not enforced, but only stated as a requirement in the comments on the unsafe functions. This change enforces this no-moving rule using `Pin`, by changing `&self` to a `Pin` in the `init()` and `lock()` functions.
This uncovered a bug I introduced in #77154: stdio.rs (the only user of ReentrantMutex) called `init()` on its ReentrantMutexes while constructing them in the intializer of `SyncOnceCell::get_or_init`, which would move them afterwards. Interestingly, the ReentrantMutex unit tests already had the same bug, so this invalid usage has been tested on all (CI-tested) platforms for a long time. Apparently this doesn't break badly on any of the major platforms, but it does break the rules.\*
To be able to keep using SyncOnceCell, this adds a `SyncOnceCell::get_or_init_pin` function, which makes it possible to work with pinned values inside a (pinned) SyncOnceCell. Whether this function should be public or not and what its exact behaviour and interface should be if it would be public is something I'd like to leave for a separate issue or PR. In this PR, this function is internal-only and marked with `pub(crate)`.
\* Note: That bug is now included in 1.48, while this patch can only make it to ~~1.49~~ 1.50. We should consider the implications of 1.48 shipping with a wrong usage of `pthread_mutex_t` / `CRITICAL_SECTION` / .. which technically invokes UB according to their specification. The risk is very low, considering the objects are not 'used' (locked) before the move, and the ReentrantMutex unit tests have verified this works fine in practice.
Edit: This has been backported and included in 1.48. And soon 1.49 too.
---
In future changes, I want to push this usage of Pin further inside `sys` instead of only `sys_common`, and apply it to all 'unmovable' objects there (`Mutex`, `Condvar`, `RwLock`). Also, while `sys_common`'s mutexes and condvars are already taken care of by #77147 and #77648, its `RwLock` should still be made movable or get pinned.
Aaron Hill [Thu, 10 Dec 2020 20:27:07 +0000 (15:27 -0500)]
Use `def_path_hash_to_def_id` when re-using a `RawDefId`
Fixes #79890
Previously, we just copied a `RawDefId` from the 'old' map to the 'new'
map. However, the `RawDefId` for a given `DefPathHash` may be different
in the current compilation session. Using `def_path_hash_to_def_id`
ensures that the `RawDefId` we use is valid in the current session.
Lyndon Brown [Thu, 10 Dec 2020 07:00:17 +0000 (07:00 +0000)]
Add some core::cmp::Ordering helpers
...to allow easier greater-than-or-equal-to and less-than-or-equal-to
comparisons, and variant checking without needing to import the enum,
similar to `Option::is_none()` / `Option::is_some()`, in situations where
you are dealing with an `Ordering` value. (Simple `PartialOrd` / `Ord`
based evaluation may not be suitable for all situations).
Prior to Rust 1.42 a greater-than-or-equal-to comparison might be written
either as a match block, or a traditional conditional check like this:
```rust
if cmp == Ordering::Equal || cmp == Ordering::Greater {
// Do something
}
```
Which requires two instances of `cmp`. Don't forget that while `cmp` here
is very short, it could be something much longer in real use cases.
From Rust 1.42 a nicer alternative is possible:
```rust
if matches!(cmp, Ordering::Equal | Ordering::Greater) {
// Do something
}
```
The commit adds another alternative which may be even better in some cases:
```rust
if cmp.is_ge() {
// Do something
}
```
The earlier examples could be cleaner than they are if the variants of
`Ordering` are imported such that `Equal`, `Greater` and `Less` can be
referred to directly, but not everyone will want to do that.
The new solution can shorten lines, help avoid logic mistakes, and avoids
having to import `Ordering` / `Ordering::*`.
projects / rust.git / log