Skip to content

R
Rust

int / Rust
接近 1 年 前同步成功

通知 1
Star 0
Fork 0
R
Rust

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

切换分支/标签
  1. 15 6月, 2021 10 次提交
  3. 14 6月, 2021 13 次提交
  5. 13 6月, 2021 11 次提交
  7. 12 6月, 2021 6 次提交
    • B
      Auto merge of #82703 - iago-lito:nonzero_add_mul_pow, r=m-ou-se · da7ada58
      由 bors 提交于 
      Implement nonzero arithmetics for NonZero types.

Hello'all, this is my first PR to this repo.

Non-zero natural numbers are stable by addition/multiplication/exponentiation, so it makes sense to make this arithmetic possible with `NonZeroU*`.

The major pitfall is that overflowing underlying `u*` types possibly lead to underlying `0` values, which break the major invariant of `NonZeroU*`. To accommodate it, only `checked_` and `saturating_` operations are implemented.

Other variants allowing wrapped results like `wrapping_` or `overflowing_` are ruled out *de facto*.

`impl Add<u*> for NonZeroU* { .. }` was considered, as it panics on overflow which enforces the invariant, but it does not so in release mode. I considered forcing `NonZeroU*::add` to panic in release mode by deferring the check to `u*::checked_add`, but this is less explicit for the user than directly using `NonZeroU*::checked_add`.
Following `@Lokathor's` advice on zulip, I have dropped the idea.

`@poliorcetics` on Discord also suggested implementing `_sub` operations, but I'd postpone this to another PR if there is a need for it. My opinion is that it could be useful in some cases, but that it makes less sense because non-null natural numbers are not stable by subtraction even in theory, while the overflowing problem is just about technical implementation.

One thing I don't like is that the type of the `other` arg differs in every implementation: `_add` methods accept any raw positive integer, `_mul` methods only accept non-zero values otherwise the invariant is also broken, and `_pow` only seems to accept `u32` for a reason I ignore but that seems consistent throughout `std`. Maybe there is a better way to harmonize this?

This is it, Iope I haven't forgotten anything and I'll be happy to read your feedback.
      da7ada58
    • B
      Auto merge of #86215 - FabianWolff:unnameable-types, r=jackh726 · 60f1a2fc
      由 bors 提交于 
      Do not suggest to add type annotations for unnameable types

Consider this example:
```rust
const A = || 42;

struct S<T> { t: T }
const B: _ = S { t: || 42 };
```
This currently produces the following output:
```
error: missing type for `const` item
 --> src/lib.rs:1:7
  |
1 | const A = || 42;
  |       ^ help: provide a type for the item: `A: [closure@src/lib.rs:1:11: 1:16]`

error[E0121]: the type placeholder `_` is not allowed within types on item signatures
 --> src/lib.rs:4:10
  |
4 | const B: _ = S { t: || 42 };
  |          ^
  |          |
  |          not allowed in type signatures
  |          help: replace `_` with the correct type: `S<[closure@src/lib.rs:4:21: 4:26]>`

error: aborting due to 2 previous errors
```
However, these suggestions are obviously useless, because the suggested types cannot be written down. With my changes, the suggestion is replaced with a note, because there is no simple fix:
```
error: missing type for `const` item
 --> test.rs:1:7
  |
1 | const A = || 42;
  |       ^
  |
note: however, the inferred type `[closure@test.rs:1:11: 1:16]` cannot be named
 --> test.rs:1:11
  |
1 | const A = || 42;
  |           ^^^^^

error[E0121]: the type placeholder `_` is not allowed within types on item signatures
 --> test.rs:4:10
  |
4 | const B: _ = S { t: || 42 };
  |          ^ not allowed in type signatures
  |
note: however, the inferred type `S<[closure@test.rs:4:21: 4:26]>` cannot be named
 --> test.rs:4:14
  |
4 | const B: _ = S { t: || 42 };
  |              ^^^^^^^^^^^^^^

error: aborting due to 2 previous errors
```
      60f1a2fc
    • I
      Stop relying on #[feature(try_trait)] in doctests. · 7afdaf2c
      由 Iago-lito 提交于
      7afdaf2c
    • B
      Auto merge of #86130 - BoxyUwU:abstract_const_as_cast, r=oli-obk · d59b80d5
      由 bors 提交于 
      const_eval_checked: Support as casts in abstract consts
      d59b80d5
    • I
      Explain non-dropped sender recv in docs · 0f3c7d18
      由 Ivan Tham 提交于 
      Original senders that are still hanging around could cause
Receiver::recv to not block since this is a potential footgun
for beginners, clarify more on this in the docs for readers to
be aware about it.

Fix minor tidbits in sender recv doc
Co-authored-by: NDylan DPC <dylan.dpc@gmail.com>

Add example for unbounded receive loops in doc

Show the drop(tx) pattern, based on tokio docs
https://tokio-rs.github.io/tokio/doc/tokio/sync/index.html

Fix example code for drop sender recv

Fix wording in sender docs
Co-authored-by: NJosh Triplett <josh@joshtriplett.org>
      0f3c7d18
    • B
      Auto merge of #86180 - cjgillot:defmv, r=petrochenkov · 0f6ba39f
      由 bors 提交于 
      Hash DefId in rustc_span.

This is mostly just moving code around. Changes are simplifications of unneeded callbacks from rustc_span to rustc_middle.

r? `@petrochenkov`
      0f6ba39f