Skip to content

R
Rust

int / Rust
大约 1 年 前同步成功

通知 1
Star 0
Fork 0
R
Rust

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 07 3月, 2021 12 次提交
  3. 06 3月, 2021 28 次提交
    • L
      Improve transmute docs with further clarifications · fbc17410
      由 Lonami 提交于 
      Closes #82493.
      fbc17410
    • Y
      Move some tests to more suitable subdirs · eb9abea2
      由 Yuki Okushi 提交于
      eb9abea2
    • H
      address comments · 7d3a6f16
      由 Henry Boisdequin 提交于
      7d3a6f16
    • B
      Auto merge of #82816 - GuillaumeGomez:rollup-hxohu2e, r=GuillaumeGomez · 51748a8f
      由 bors 提交于 
      Rollup of 7 pull requests

Successful merges:

 - #80845 (Make ItemKind::ExternCrate looks like hir::ItemKind::ExternCrate to make transition over hir::ItemKind simpler)
 - #82708 (Warn on `#![doc(test(...))]` on items other than the crate root and use future incompatible lint)
 - #82714 (Detect match arm body without braces)
 - #82736 (Bump optimization from mir_opt_level 2 to 3 and 3 to 4 and make "release" be level 2 by default)
 - #82782 (Make rustc shim's verbose output include crate_name being compiled.)
 - #82797 (Update tests names to start with `issue-`)
 - #82809 (rustdoc: Use substrings instead of split to grab enum variant paths)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
      51748a8f
    • G
      Rollup merge of #82809 - notriddle:microoptimize-main-js, r=GuillaumeGomez · 8dfbc00d
      由 Guillaume Gomez 提交于 
      rustdoc: Use substrings instead of split to grab enum variant paths

Both versions are about equally readable, but this version avoids scanning the entire path and building an intermediate array (`split()` in Rust is a lazy iterator, but not in JavaScript).
      8dfbc00d
    • G
      Rollup merge of #82797 - henryboisdequin:name-issue-num, r=Xanewok · 1a08cb6a
      由 Guillaume Gomez 提交于 
      Update tests names to start with `issue-`

See ``@JohnTitor's`` [comment](https://github.com/rust-lang/rust/pull/82720#discussion_r586488083)

``@rustbot`` label +C-cleanup
      1a08cb6a
    • G
      Rollup merge of #82782 -... · ef17859e
      由 Guillaume Gomez 提交于 
      Rollup merge of #82782 - pnkfelix:include-crate-being-compiled-in-bootstrap-verbose-output, r=Mark-Simulacrum

Make rustc shim's verbose output include crate_name being compiled.

This change is mainly motivated by an issue with the environment printing I added in PR 82403: multiple rustc invocations progress in parallel, and the environment output, spanning multiple lines, gets interleaved in ways make it difficult to extra the enviroment settings.

(This aforementioned difficulty is more of a hiccup than an outright show-stopper, because the environment variables tend to be the same for all of the rustc invocations, so it doesn't matter too much if one mixes up which lines one is looking at. But still: Better to fix it.)
      ef17859e
    • G
      Rollup merge of #82736 - spastorino:mir-opt-level-perf-changes, r=oli-obk · 15c148b4
      由 Guillaume Gomez 提交于 
      Bump optimization from mir_opt_level 2 to 3 and 3 to 4 and make "release" be level 2 by default

r? `@oli-obk`
      15c148b4
    • G
      Rollup merge of #82714 - estebank:missing-braces, r=oli-obk · 34b2caa7
      由 Guillaume Gomez 提交于 
      Detect match arm body without braces

Fix #82524.
      34b2caa7
    • G
      Rollup merge of #82708 - GuillaumeGomez:doc-test-attr-check, r=Manishearth · 8867f7f6
      由 Guillaume Gomez 提交于 
      Warn on `#![doc(test(...))]` on items other than the crate root and use future incompatible lint

Part of #82672.

This PR does multiple things:
 * Create a new `INVALID_DOC_ATTRIBUTE` lint which is also "future incompatible", allowing us to use it as a warning for the moment until it turns (eventually) into a hard error.
 * Use this link when `#![doc(test(...))]` isn't used at the crate level.
 * Make #82702 use this new lint as well.

r? ``@jyn514``
      8867f7f6
    • G
      Rollup merge of #80845 - GuillaumeGomez:item-kind-transition, r=jyn514 · 92861c79
      由 Guillaume Gomez 提交于 
      Make ItemKind::ExternCrate looks like hir::ItemKind::ExternCrate to make transition over hir::ItemKind simpler

It was surprisingly difficult to make this change, mostly because of two issues:

* We now store the `ExternCrate` name in the parent struct (`clean::Item`), which forced me to modify the json conversion code a bit more than expected.
* The second problem was that, since we now have a `Some(name)`, it was trying to render it, ending up in a panic because we ended up in a `unreachable` statement. The solution was simply to add `!item.is_extern_crate()` in `formats::renderer` before calling `cx.item(item, &cache)?;`.

I'll continue to replace all the `clean::ItemKind` variants one by one until it looks exactly like `hir::ItemKind`. Then we'll simply discard the rustdoc type. Once this done, we'll be able to discard `clean::Item` too to use `hir::Item`.

r? ``@jyn514``
      92861c79
    • S
      bless mir-inlining warning message · 11d9390c
      由 Santiago Pastorino 提交于
      11d9390c
    • J
      Add an unstable option to print all unversioned files · 173d2aaa
      由 Joshua Nelson 提交于 
      This allows sharing those files between different doc invocations
without having to know their names ahead of time.
      173d2aaa
    • S
      Fix MIR optimization level description · 663d4c86
      由 Santiago Pastorino 提交于
      663d4c86
    • S
      Bump one missing mir_opt_level · 004465c6
      由 Santiago Pastorino 提交于
      004465c6
    • S
      Fix rustc_driver self text and bump the mir_opt_level · 261048f0
      由 Santiago Pastorino 提交于
      261048f0
    • S
      Bump mir-opt-level from 2 to 3 in tests · af63afc0
      由 Santiago Pastorino 提交于
      af63afc0
    • S
      Bump mir-opt-level from 3 to 4 in tests · 705813c8
      由 Santiago Pastorino 提交于
      705813c8
    • S
      Make clippy set mir_opt_level using Option · 03c1f176
      由 Santiago Pastorino 提交于
      03c1f176
    • S
      Make mir_opt_level default to 2 for optimized levels · 421fd8eb
      由 Santiago Pastorino 提交于
      421fd8eb
    • S
      Bump all mir_opt_level 2 to 3 · 782c7b04
      由 Santiago Pastorino 提交于
      782c7b04
    • S
      Bump all mir_opt_level 3 to 4 · f3b8920d
      由 Santiago Pastorino 提交于
      f3b8920d
    • S
      For better consistency change mir_opt_level <= 1 to < 2 · fde8d6ee
      由 Santiago Pastorino 提交于
      fde8d6ee
    • S
      Extract mir_opt_level to a method and use Option to be able to know if the value is provided or not · 8152da22
      由 Santiago Pastorino 提交于
      8152da22
    • B
      Auto merge of #74024 - Folyd:master, r=m-ou-se · caca2121
      由 bors 提交于 
      Improve slice.binary_search_by()'s best-case performance to O(1)

This PR aimed to improve the [slice.binary_search_by()](https://doc.rust-lang.org/std/primitive.slice.html#method.binary_search_by)'s best-case performance to O(1).

# Noticed

I don't know why the docs of `binary_search_by` said `"If there are multiple matches, then any one of the matches could be returned."`, but the implementation isn't the same thing. Actually, it returns the **last one** if multiple matches found.

Then we got two options:

## If returns the last one is the correct or desired result

Then I can rectify the docs and revert my changes.

## If the docs are correct or desired result

Then my changes can be merged after fully reviewed.

However, if my PR gets merged, another issue raised: this could be a **breaking change** since if multiple matches found, the returning order no longer the last one instead of it could be any one.

For example:
```rust
let mut s = vec![0, 1, 1, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55];
let num = 1;
let idx = s.binary_search(&num);
s.insert(idx, 2);

// Old implementations
assert_eq!(s, [0, 1, 1, 1, 1, 2, 2, 3, 5, 8, 13, 21, 34, 42, 55]);

// New implementations
assert_eq!(s, [0, 1, 1, 1, 2, 1, 2, 3, 5, 8, 13, 21, 34, 42, 55]);
```

# Benchmarking

**Old implementations**
```sh
$ ./x.py bench --stage 1 library/libcore
test slice::binary_search_l1           ... bench:          59 ns/iter (+/- 4)
test slice::binary_search_l1_with_dups ... bench:          59 ns/iter (+/- 3)
test slice::binary_search_l2           ... bench:          76 ns/iter (+/- 5)
test slice::binary_search_l2_with_dups ... bench:          77 ns/iter (+/- 17)
test slice::binary_search_l3           ... bench:         183 ns/iter (+/- 23)
test slice::binary_search_l3_with_dups ... bench:         185 ns/iter (+/- 19)
```

**New implementations (1)**

Implemented by this PR.
```rust
if cmp == Equal {
    return Ok(mid);
} else if cmp == Less {
    base = mid
}
```
```sh
$ ./x.py bench --stage 1 library/libcore
test slice::binary_search_l1           ... bench:          58 ns/iter (+/- 2)
test slice::binary_search_l1_with_dups ... bench:          37 ns/iter (+/- 4)
test slice::binary_search_l2           ... bench:          76 ns/iter (+/- 3)
test slice::binary_search_l2_with_dups ... bench:          57 ns/iter (+/- 6)
test slice::binary_search_l3           ... bench:         200 ns/iter (+/- 30)
test slice::binary_search_l3_with_dups ... bench:         157 ns/iter (+/- 6)

$ ./x.py bench --stage 1 library/libcore
test slice::binary_search_l1           ... bench:          59 ns/iter (+/- 8)
test slice::binary_search_l1_with_dups ... bench:          37 ns/iter (+/- 2)
test slice::binary_search_l2           ... bench:          77 ns/iter (+/- 2)
test slice::binary_search_l2_with_dups ... bench:          57 ns/iter (+/- 2)
test slice::binary_search_l3           ... bench:         198 ns/iter (+/- 21)
test slice::binary_search_l3_with_dups ... bench:         158 ns/iter (+/- 11)

```

**New implementations (2)**

Suggested by `@nbdd0121` in [comment](https://github.com/rust-lang/rust/pull/74024#issuecomment-665430239).
```rust
base = if cmp == Greater { base } else { mid };
if cmp == Equal { break }
```

```sh
$ ./x.py bench --stage 1 library/libcore
test slice::binary_search_l1           ... bench:          59 ns/iter (+/- 7)
test slice::binary_search_l1_with_dups ... bench:          37 ns/iter (+/- 5)
test slice::binary_search_l2           ... bench:          75 ns/iter (+/- 3)
test slice::binary_search_l2_with_dups ... bench:          56 ns/iter (+/- 3)
test slice::binary_search_l3           ... bench:         195 ns/iter (+/- 15)
test slice::binary_search_l3_with_dups ... bench:         151 ns/iter (+/- 7)

$ ./x.py bench --stage 1 library/libcore
test slice::binary_search_l1           ... bench:          57 ns/iter (+/- 2)
test slice::binary_search_l1_with_dups ... bench:          38 ns/iter (+/- 2)
test slice::binary_search_l2           ... bench:          77 ns/iter (+/- 11)
test slice::binary_search_l2_with_dups ... bench:          57 ns/iter (+/- 4)
test slice::binary_search_l3           ... bench:         194 ns/iter (+/- 15)
test slice::binary_search_l3_with_dups ... bench:         151 ns/iter (+/- 18)

```

I run some benchmarking testings against on two implementations. The new implementation has a lot of improvement in duplicates cases, while in `binary_search_l3` case, it's a little bit slower than the old one.
      caca2121
    • M
      Use substrings instead of split to grab enum variant paths · 0571bc42
      由 Michael Howell 提交于 
      Both versions are about equally readable, but this version avoids scanning
the entire path and building an intermediate array (`split()` in Rust is
a lazy iterator, but not in JavaScript).
      0571bc42
    • G
      Add relevant test · c1bfb9a7
      由 Giacomo Stevanato 提交于
      c1bfb9a7
    • G
      Prevent Zip specialization from calling __iterator_get_unchecked twice with... · 2371914a
      由 Giacomo Stevanato 提交于 
      Prevent Zip specialization from calling __iterator_get_unchecked twice with the same index after calling next_back
      2371914a