- 15 6月, 2021 10 次提交
-
-
由 Yuki Okushi 提交于
Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented, [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR, godbolt was still on the 2021-05-01 nightly, where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of, so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058, where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594), and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589, https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP, picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug, Clone, Copy, PartialEq)] pub enum ControlFlow<B, C = ()> { /// Exit the operation without running subsequent phases. Break(B), /// Move on to the next phase of the operation as normal. Continue(C), } ``` As well as using `?` on a `ControlFlow<B, _>` in a function returning `ControlFlow<B, _>`. (Note, in particular, that there's no `From::from`-conversion on the `Break` value, the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value`, `is_continue`, `map_break`, [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE), etc. Some of the existing methods in nightly seem reasonable, some seem like they should be removed, and some need more discussion to decide. But none of them are *essential*, so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow), they're all omitted from this PR. They can be considered separately later, as further usage demonstrates which are important.
-
由 Yuki Okushi 提交于
Add functions `Duration::try_from_secs_{f32, f64}` These functions allow constructing a Duration from a floating point value that could be out of range without panicking. Tracking issue: #83400
-
由 Yuki Okushi 提交于
Explain non-dropped sender recv in docs 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. Maybe it would be better to show an example of the pattern where `drop(tx)` is used when it is being cloned multiple times? Although I have seen it in quite a few articles but I am surprised that this part is not very clear with the current words without careful reading. > If the corresponding Sender has disconnected, or it disconnects while this call is blocking, this call will wake up and return Err to indicate that no more messages can ever be received on this channel. However, since channels are buffered, messages sent before the disconnect will still be properly received. Some words there may seemed similar if I carefully read and relate it but if I am new, I probably does not know "drop" makes it "disconnected". So I mention the words "drop" and "alive" to make it more relatable to lifetime.
-
由 bors 提交于
Update RELEASES.md for 1.53.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnotes_1.53.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`
-
由 bors 提交于
rustdoc: revert deref recur to resume inclusion of impl ExtTrait<Local> for ExtType As discussed here: https://github.com/rust-lang/rust/issues/82465#issuecomment-829290384, Revert PR #80653 to resolve issue #82465. Issue #82465 was we had stopped including certain trait implementations, namely implementations on an imported type of an imported trait *instantiated on a local type*. That bug was injected by PR #80653. Reverting #80653 means we don't list all the methods that you have accessible via recursively applying `Deref`. [Discussion in last week's rustc triage meeting](https://zulip-archive.rust-lang.org/238009tcompilermeetings/19557weekly2021042954818.html#236680594) led us to conclude that the bug was worse than the enhancement, and there was not an obvious fix for the bug itself. So for the short term we remove the enhancement, while in the long term we will work on figuring out a way to have our imported trait implementation cake and eat it too.
-
由 bors 提交于
Improve CTFE UB validation error messages As mentioned in https://github.com/rust-lang/rust/pull/86245#discussion_r650494012 this PR slightly improves the formatting of validation errors, to move the path to the error prefix. From: `type validation failed: encountered invalid vtable: size is bigger than largest supported object at .0` To: `type validation failed at .0: encountered invalid vtable: size is bigger than largest supported object`.
-
由 Scott McMurray 提交于
-
由 bors 提交于
Fix force-warns to allow dashes. The `--force-warns` flag was not allowing lint names with dashes, only supporting underscores. This changes it to allow dashes to match the behavior of the A/W/D/F flags.
-
由 Rémy Rakic 提交于
-
由 Rémy Rakic 提交于
-
- 14 6月, 2021 13 次提交
-
-
由 bors 提交于
Stabilize `maybe_uninit_ref` This stabilizes `assume_init_{ref,mut}`. FCP is complete: https://github.com/rust-lang/rust/issues/63568#issuecomment-590121300 The renaming was done by #76047 and FIXME was resolved by #76241, so I think we can now stabilize them finally
🎉 Still, it's const-unstable as `assert_inhabited` is unstable. Closes #63568 -
由 mbartlett21 提交于
`Duration::from_secs_{f32, f64}` now use the results from the non-panicking functions and unwrap it.
-
由 mbartlett21 提交于
This also adds the error type used, `FromSecsError` and its `impl`s.
-
由 bors 提交于
Revert #85176 addition of `clone_from` for `ManuallyDrop` Forwarding `clone_from` to the inner value changes the observable behavior, as previously the inner value would *not* be dropped by the default implementation. Frankly, this is a super-niche case, so #85176 is welcome to argue the behavior should be otherwise! But if we overrride it, IMO documenting the behavior would be good. Example: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=c5d0856686fa850c1d7ee16891014efb
-
由 bors 提交于
Fix typo `with custom a custom` -> `with a custom`
-
由 Rémy Rakic 提交于
-
由 Rémy Rakic 提交于
-
由 bors 提交于
Fix font weight Fixes #86256. I realized that the only cases where we actually needed to have bold text was inside `impl-items`. cc `@camelid` r? `@jsha`
-
由 Yuki Okushi 提交于
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
由 Shadlock0133 提交于
-
- 13 6月, 2021 11 次提交
-
-
由 bors 提交于
Fix ICEs on invalid vtable size/alignment const UB errors The invalid vtable size/alignment errors from `InterpCx::read_size_and_align_from_vtable` were "freeform const UB errors", causing ICEs when reaching validation. This PR turns them into const UB hard errors to catch them during validation and avoid that. Fixes #86193 r? `@RalfJung` (It seemed cleaner to have 2 variants but they can be merged into one variant with a message payload if you prefer that ?)
-
由 Rémy Rakic 提交于
-
由 Rémy Rakic 提交于
They were "freeform const UB" error message, but could reach validation and trigger ICEs there. We now catch them during validation to avoid that.
-
由 bors 提交于
simplify validate_generic_param_order
-
由 bors 提交于
Stabilize `simd_x86_bittest` feature This pulls https://github.com/rust-lang/stdarch/pull/1180, FCP is complete: https://github.com/rust-lang/rust/issues/59414#issuecomment-826072554 Closes #59414
-
由 bors 提交于
Update cargo 11 commits in aa8b09297bb3156b849e73db48af4cd050492fe6..44456677b5d1d82fe981c955dc5c67734b31f340 2021-06-09 00:28:53 +0000 to 2021-06-12 18:00:01 +0000 - Fix package_default_run test. (rust-lang/cargo#9577) - Change how the fix_deny_warnings_but_not_others test works (rust-lang/cargo#9571) - Add mising documentation regarding `cargo doc` (rust-lang/cargo#9565) - Implement warning for ignored trailing arguments (rust-lang/cargo#9561) - Make clippy happy (rust-lang/cargo#9569) - Fix rustc/rustdoc config values to be config-relative. (rust-lang/cargo#9566) - Update rustfix. (rust-lang/cargo#9567) - Warn if an "all" target is specified, but we don't match anything (rust-lang/cargo#9549) - add default_run to SerializedPackage (rust-lang/cargo#9550) - respect user choice of lib/bin over heuristics (rust-lang/cargo#9522) - Add a mean to mutably access the members of a workspace (rust-lang/cargo#9547)
-
由 klensy 提交于
-
由 bors 提交于
Pretty print generator witness only in `-Zverbose` mode In release build of deeply-nested-async benchmark the size of `no-opt.bc` file is reduced from 46MB to 62kB. Helps with #84873, where in one of reported test cases the size of `no-opt.bc` file is reduced from 2.3GB to 799kB.
-
由 Eric Huss 提交于
-
由 Yuki Okushi 提交于
-
由 Tomasz Miąsko 提交于
In release build of deeply-nested-async benchmark the size of `no-opt.bc` file is reduced from 46MB to 62kB.
-
- 12 6月, 2021 6 次提交
-
-
由 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.
-
由 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 ```
-
由 Iago-lito 提交于
-
由 bors 提交于
const_eval_checked: Support as casts in abstract consts
-
由 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>
-
由 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`
-