profile
viewpoint

kennytm/cargo-kcov 110

Cargo subcommand to run kcov to get coverage report on Linux

kennytm/cov 106

LLVM-GCOV Source coverage for Rust

kennytm/CoCCalc 51

THIS PROJECT HAS BEEN ABANDONED.

kennytm/dbgen 14

Generate random test cases for databases

kennytm/CatSaver 8

Automatically save logcat

kennytm/async-ctrlc 6

`async-ctrlc` is an async wrapper of the `ctrlc` crate in Rust

auraht/gamepad 4

A cross-platform gamepad library to supplement HIDDriver

kennytm/borsholder 4

Combined status board of rust-lang/rust's Homu queue and GitHub PR status.

kennytm/711cov 3

Coverage reporting software for gcov-4.7

kennytm/aar-to-eclipse 3

Convert *.aar to Android library project for Eclipse ADT

push eventrust-lang-nursery/rust-toolstate

Rust Toolstate Update

commit sha 9ebbb6e0b5ee94efa3c1b961d808778ce8c1feee

(windows CI update)

view details

push time in an hour

pull request commentpingcap/br

grafana dashboards support multiple cluster

CLA assistant check <br/>Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.<br/><sub>You have signed the CLA already but the status is still pending? Let us recheck it.</sub>

zjj2wry

comment created time in an hour

PR opened pingcap/br

grafana dashboards support multiple cluster

<!-- Thank you for working on BR! Please read BR's CONTRIBUTING document BEFORE filing this PR. -->

What problem does this PR solve?

<!-- Add the issue link with a summary if it exists. -->

Many users(come from DBaaS、operator、tiup) monitor multiple TiDB clusters in one Grafana, this PR make Grafana dashboards support multiple clusters and not affect single cluster usage. Cluster variable is hidden by default.

What is changed and how it works?

  • add a tidb_cluster label in all expr
  • add cluster variable in Grafana templating

How it Works: load it to your Grafana :))

Single Cluster: No change

Multiple Cluster: Construct a label that can uniquely identify the cluster. in tidb_operator, you can use {namespace}-{cluster_name} as your {tidb_cluster} variable. add this configuration to your prometheus config

relabel_configs:
  - source_labels:
      - namespace
      - name
    separator: "-"
    target_label: tidb_cluster

Check List

<!-- Remove the items that are not applicable. -->

Tests

<!-- At least one of them must be included. -->

  • No code

Code changes

Side effects

  • no effects

Related changes

  • https://github.com/pingcap/tidb/pull/22503

Release note

  • metrics: grafana dashboards support multiple clusters
+70 -45

0 comment

1 changed file

pr created time in an hour

pull request commentpingcap/tidb-lightning

grafana dashboards support multiple cluster

/cc @tennix @breeswish @AstroProfundis @DanielZhangQD

zjj2wry

comment created time in an hour

push eventrust-lang/rustup-components-history

Deploy from CI

commit sha 09adb49da5daf6eb60e928f5fffb42d73f3df521

Deploy 6aa318a895ba44ff118759d0467390f41ab51b9a to gh-pages

view details

push time in an hour

pull request commentpingcap/tidb-lightning

grafana dashboards support multiple cluster

CLA assistant check <br/>Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.<br/><sub>You have signed the CLA already but the status is still pending? Let us recheck it.</sub>

zjj2wry

comment created time in an hour

PR opened pingcap/tidb-lightning

grafana dashboards support multiple cluster

<!-- Thank you for contributing to TiDB-Lightning! Please read the CONTRIBUTING document BEFORE filing this PR. -->

What problem does this PR solve?

<!-- Add the issue link with a summary if it exists. -->

Many users(come from DBaaS、operator、tiup) monitor multiple TiDB clusters in one Grafana, this PR make Grafana dashboards support multiple clusters and not affect single cluster usage. Cluster variable is hidden by default.

What is changed and how it works?

  • add a tidb_cluster label in all expr
  • add cluster variable in Grafana templating

How it Works: load it to your Grafana :))

Single Cluster: No change

Multiple Cluster: Construct a label that can uniquely identify the cluster. in tidb_operator, you can use {namespace}-{cluster_name} as your {tidb_cluster} variable. add this configuration to your prometheus config

relabel_configs:
  - source_labels:
      - namespace
      - name
    separator: "-"
    target_label: tidb_cluster

Check List <!--REMOVE the items that are not applicable-->

Tests <!-- At least one of them must be included. -->

  • No code

Side effects

  • No effects

Related changes

  • https://github.com/pingcap/tidb/pull/22503

Release note

  • metrics: grafana dashboards support multiple clusters
+58 -32

0 comment

1 changed file

pr created time in an hour

push eventrust-lang-nursery/rust-toolstate

Rust Toolstate Update

commit sha cdd5ec1d81cd64c182817d027dbf33655135492c

(linux CI update)

view details

push time in an hour

pull request commentrust-lang/rfcs

adds async stream rfc

@zesterer thank you for your comments, they encouraged us to think even more carefully about the design of this feature. I am going to leave the design as it is now as a minimal viable implementation, but we have your concerns about channels recorded here for future reference. I have no doubt we will be opening more RFCs around Async streams in the near future and we will certainly keep your concerns in mind. Thank you again, the community input and context is vital to any RFC.

nellshamrell

comment created time in 2 hours

pull request commentrust-lang/rfcs

adds async stream rfc

Hello @rust-lang/libs :) For those of you who have not yet approved FCP in this comment - are there any concerns you have or is there anything blocking approving this for FCP?

nellshamrell

comment created time in 2 hours

Pull request review commentrust-lang/rfcs

adds async stream rfc

+- Feature Name: `async_stream`+- Start Date: 2020-09-29+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++Introduce the `Stream` trait into the standard library, using the+design from `futures`. Redirect the `Stream` trait definition in the +`futures-core` crate (which is "pub-used" by the `futures` crate) to the standard library.++# Motivation+[motivation]: #motivation++Streams are a core async abstraction. These behave similarly to `Iterator`,+but rather than blocking between each item yield, it allows other+tasks to run while it waits.++People can do this currently using the `Stream` trait defined in the +[futures](https://crates.io/crates/futures) crate. However, we would like+to add `Stream` to the standard library. ++Including `Stream` in the standard library would clarify the stability guarantees of the trait. For example, if [Tokio](https://tokio.rs/) +wishes to declare a [5 year stability period](http://smallcultfollowing.com/babysteps/blog/2020/02/11/async-interview-6-eliza-weisman/#communicating-stability), +having the `Stream` trait in the standard library means there are no concerns +about the trait changing during that time ([citation](http://smallcultfollowing.com/babysteps/blog/2019/12/23/async-interview-3-carl-lerche/#what-should-we-do-next-stabilize-stream)).++## Examples of current crates that are consuming streams++### async-h1++* [async-h1](https://docs.rs/async-h1)'s server implementation takes `TcpStream` instances produced by a `TcpListener` in a loop.++### async-sse++* [async-sse](https://docs.rs/async-sse/) parses incoming buffers into a stream of messages.++## Why a shared trait?++We eventually want dedicated syntax for working with streams, which will require a shared trait. +This includes a trait for producing streams and a trait for consuming streams.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++A "stream" is the async version of an [iterator].++The `Iterator` trait includes a `next` method, which computes and returns the next item in the sequence. The `Stream` trait includes the `poll_next` method to assist with defining a stream. In the future, we should add a `next` method for use when consuming and interacting with a stream (see the [Future possiblilities](future-possibilities) section later in this RFC).++## poll_next method++When implementing a `Stream`, users will define a `poll_next` method. +The `poll_next` method asks if the next item is ready. If so, it returns+the item. Otherwise, `poll_next` will return [`Poll::Pending`]. ++Just as with a [`Future`], returning [`Poll::Pending`] +implies that the stream has arranged for the current task to be re-awoken when the data is ready.++[iterator]: https://doc.rust-lang.org/std/iter/trait.Iterator.html+[`Future`]: https://doc.rust-lang.org/std/future/trait.Future.html+[`Poll::Pending`]: https://doc.rust-lang.org/std/task/enum.Poll.html#variant.Pending++```rust+// Defined in std::stream module+pub trait Stream {+    // Core items:+    type Item;+    fn poll_next(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Option<Self::Item>>;+    +    // Optional optimization hint, just like with iterators:+    #[inline]+    fn size_hint(&self) -> (usize, Option<usize>) {+        (0, None)+    }+}+```++The arguments to `poll_next` match that of the [`Future::poll`] method:++* The self must be a pinned reference, ensuring both unique access to+  the stream and that the stream value itself will not move. Pinning+  allows the stream to save pointers into itself when it suspends,+  which will be required to support generator syntax at some point.+* The [context] `cx` defines details of the current task. In particular,+  it gives access to the [`Waker`] for the task, which will allow the+  task to be re-awoken once data is ready.++[`Future::poll`]: https://doc.rust-lang.org/std/future/trait.Future.html#tymethod.poll+[pinned]: https://doc.rust-lang.org/std/pin/struct.Pin.html+[context]: https://doc.rust-lang.org/std/task/struct.Context.html+[`Waker`]: https://doc.rust-lang.org/std/task/struct.Waker.html++### Usage++A user could create a stream as follows (Example taken from @yoshuawuyt's [implementation pull request](https://github.com/rust-lang/rust/pull/79023)).++Creating a stream involves two steps: creating a `struct` to+ hold the stream's state, and then implementing `Stream` for that+ `struct`.++ Let's make a stream named `Counter` which counts from `1` to `5`:++```rust+#![feature(async_stream)]+# use core::stream::Stream;+# use core::task::{Context, Poll};+# use core::pin::Pin;++// First, the struct:++/// A stream which counts from one to five+struct Counter {+    count: usize,+}++// we want our count to start at one, so let's add a new() method to help.+// This isn't strictly necessary, but is convenient. Note that we start+// `count` at zero, we'll see why in `poll_next()`'s implementation below.+impl Counter {+    fn new() -> Counter {+        Counter { count: 0 }+    }+}++// Then, we implement `Stream` for our `Counter`:++impl Stream for Counter {+    // we will be counting with usize+    type Item = usize;++    // poll_next() is the only required method+    fn poll_next(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Option<Self::Item>> {+        // Increment our count. This is why we started at zero.+        self.count += 1;++        // Check to see if we've finished counting or not.+        if self.count < 6 {+            Poll::Ready(Some(self.count))+        } else {+            Poll::Ready(None)+        }+    }+}+```++## Initial impls

Hi @KodrAus - I intentionally did not include the consuming side here since the next method has been moved to the "Future Possibilities" section. I felt including that here would introduce more confusion about what is and is not covered by this RFC.

nellshamrell

comment created time in 2 hours

Pull request review commentrust-lang/rfcs

adds async stream rfc

+- Feature Name: `async_stream`+- Start Date: 2020-09-29+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++Introduce the `Stream` trait into the standard library, using the+design from `futures`. Redirect the `Stream` trait definition in the +`futures-core` crate (which is "pub-used" by the `futures` crate) to the standard library.++# Motivation+[motivation]: #motivation++Streams are a core async abstraction. These behave similarly to `Iterator`,+but rather than blocking between each item yield, it allows other+tasks to run while it waits.++People can do this currently using the `Stream` trait defined in the +[futures](https://crates.io/crates/futures) crate. However, we would like+to add `Stream` to the standard library. ++Including `Stream` in the standard library would clarify the stability guarantees of the trait. For example, if [Tokio](https://tokio.rs/) +wishes to declare a [5 year stability period](http://smallcultfollowing.com/babysteps/blog/2020/02/11/async-interview-6-eliza-weisman/#communicating-stability), +having the `Stream` trait in the standard library means there are no concerns +about the trait changing during that time ([citation](http://smallcultfollowing.com/babysteps/blog/2019/12/23/async-interview-3-carl-lerche/#what-should-we-do-next-stabilize-stream)).++## Examples of current crates that are consuming streams++### async-h1++* [async-h1](https://docs.rs/async-h1)'s server implementation takes `TcpStream` instances produced by a `TcpListener` in a loop.++### async-sse++* [async-sse](https://docs.rs/async-sse/) parses incoming buffers into a stream of messages.++## Why a shared trait?++We eventually want dedicated syntax for working with streams, which will require a shared trait. +This includes a trait for producing streams and a trait for consuming streams.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++A "stream" is the async version of an [iterator].++The `Iterator` trait includes a `next` method, which computes and returns the next item in the sequence. The `Stream` trait includes the `poll_next` method to assist with defining a stream. In the future, we should add a `next` method for use when consuming and interacting with a stream (see the [Future possiblilities](future-possibilities) section later in this RFC).++## poll_next method++When implementing a `Stream`, users will define a `poll_next` method. +The `poll_next` method asks if the next item is ready. If so, it returns+the item. Otherwise, `poll_next` will return [`Poll::Pending`]. ++Just as with a [`Future`], returning [`Poll::Pending`] +implies that the stream has arranged for the current task to be re-awoken when the data is ready.++[iterator]: https://doc.rust-lang.org/std/iter/trait.Iterator.html+[`Future`]: https://doc.rust-lang.org/std/future/trait.Future.html+[`Poll::Pending`]: https://doc.rust-lang.org/std/task/enum.Poll.html#variant.Pending++```rust+// Defined in std::stream module+pub trait Stream {+    // Core items:+    type Item;+    fn poll_next(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Option<Self::Item>>;+    +    // Optional optimization hint, just like with iterators:+    #[inline]+    fn size_hint(&self) -> (usize, Option<usize>) {+        (0, None)+    }+}+```++The arguments to `poll_next` match that of the [`Future::poll`] method:++* The self must be a pinned reference, ensuring both unique access to+  the stream and that the stream value itself will not move. Pinning+  allows the stream to save pointers into itself when it suspends,+  which will be required to support generator syntax at some point.+* The [context] `cx` defines details of the current task. In particular,+  it gives access to the [`Waker`] for the task, which will allow the+  task to be re-awoken once data is ready.++[`Future::poll`]: https://doc.rust-lang.org/std/future/trait.Future.html#tymethod.poll+[pinned]: https://doc.rust-lang.org/std/pin/struct.Pin.html+[context]: https://doc.rust-lang.org/std/task/struct.Context.html+[`Waker`]: https://doc.rust-lang.org/std/task/struct.Waker.html++### Usage++A user could create a stream as follows (Example taken from @yoshuawuyt's [implementation pull request](https://github.com/rust-lang/rust/pull/79023)).++Creating a stream involves two steps: creating a `struct` to+ hold the stream's state, and then implementing `Stream` for that+ `struct`.++ Let's make a stream named `Counter` which counts from `1` to `5`:++```rust+#![feature(async_stream)]+# use core::stream::Stream;+# use core::task::{Context, Poll};+# use core::pin::Pin;++// First, the struct:++/// A stream which counts from one to five+struct Counter {+    count: usize,+}++// we want our count to start at one, so let's add a new() method to help.+// This isn't strictly necessary, but is convenient. Note that we start+// `count` at zero, we'll see why in `poll_next()`'s implementation below.+impl Counter {+    fn new() -> Counter {+        Counter { count: 0 }+    }+}++// Then, we implement `Stream` for our `Counter`:++impl Stream for Counter {+    // we will be counting with usize+    type Item = usize;++    // poll_next() is the only required method+    fn poll_next(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Option<Self::Item>> {+        // Increment our count. This is why we started at zero.+        self.count += 1;++        // Check to see if we've finished counting or not.+        if self.count < 6 {+            Poll::Ready(Some(self.count))+        } else {+            Poll::Ready(None)+        }+    }+}+```++## Initial impls++There are a number of simple "bridge" impls that are also provided:++```rust+impl<S> Stream for Box<S>+where+    S: Stream + Unpin + ?Sized,+{+    type Item = <S as Stream>::Item+}++impl<S> Stream for &mut S+where+    S: Stream + Unpin + ?Sized,+{+    type Item = <S as Stream>::Item;+}++impl<S, T> Stream for Pin<P>+where+    P: DerefMut<Target=T> + Unpin,+    T: Stream,+{+    type Item = <T as Stream>::Item;+}++impl<S> Stream for AssertUnwindSafe<S>+where+    S: Stream, +{+    type Item = <S as Stream>::Item;+}+```++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++This section goes into details about various aspects of the design and+why they ended up the way they did.++## Where does `Stream` live in the std lib?++`Stream` will live in the `core::stream` module and be re-exported as `std::stream`.++It is possible that it could live in another area as well, though this follows+the pattern of `core::future`.++## Why use a `poll` method?++An alternative design for the stream trait would be to have a trait+that defines an async `next` method:++```rust+trait Stream {+    type Item;+    +    async fn next(&mut self) -> Option<Self::Item>;+}+```++Unfortunately, async methods in traits are not currently supported,+and there [are a number of challenges to be+resolved](https://rust-lang.github.io/wg-async-foundations/design_notes/async_fn_in_traits.html)+before they can be added. ++Moreover, it is not clear yet how to make traits that contain async+functions be `dyn` safe, and it is important to be able to pass around `dyn+Stream` values without the need to monomorphize the functions that work+with them.++Unfortunately, the use of poll does mean that it is harder to write+stream implementations. The long-term fix for this, discussed in the [Future possiblilities](future-possibilities) section, is dedicated [generator syntax].++# Rationale and alternatives+[rationale-and-alternatives]: #rationale-and-alternatives++## Where should stream live?++As mentioned above, `core::stream` is analogous to `core::future`. But, do we want to find +some other naming scheme that can scale up to other future additions, such as io traits or channels?++# Future possibilities+[future-possibilities]: #future-possibilities++## Next method++While users will be able to implement a `Stream` as defined in this RFC, they will not have a way to interact with it in the core library. As soon as we figure out a way to do it in an object safe manner, we should add a `next` method  either in the `Stream` trait or elsewhere.++The `Iterator` trait includes a `next` method, which computes and returns the next item in the sequence. We should also implement a `next` method for `Stream`, similar to [the implementation in the futures-util crate](https://docs.rs/futures-util/0.3.5/src/futures_util/stream/stream/next.rs.html#10-12).++The core `poll_next` method is unergonomic; it does not let you iterate +over the items coming out of the stream. Therefore, we include a few minimal +convenience methods that are not dependent on any unstable features, such as `next`.++As @yoshuawuyts states in their [pull request which adds `core::stream::Stream` to the standard library](https://github.com/rust-lang/rust/pull/79023):++Unlike `Iterator`, `Stream` makes a distinction between the `poll_next`+method which is used when implementing a `Stream`, and the `next` method+which is used when consuming a stream. Consumers of `Stream` only need to+consider `next`, which when called, returns a future which yields+`Option<Item>`.++The future returned by `next` will yield `Some(Item)` as long as there are

Hi @KodrAus - the answer on this one is I honestly don't know. I'm happy to include a note that this will need to be considered in the eventual RFC and implementation of the next method. Would that be sufficient, since this is in the Future Possibilities section?

nellshamrell

comment created time in 2 hours

push eventrust-lang/rustc-pr-tracking

stats updater

commit sha b35ce372991809448413880388d8466158a79e44

Automatic stats update

view details

push time in 4 hours

push eventrust-lang/rust-repos

lists updater

commit sha 5a86bf391c14600fec79d8e23dfdf067f3a0b1b4

Automatic lists update

view details

push time in 4 hours

push eventrust-lang-nursery/rust-toolstate

Rust Toolstate Update

commit sha 9e390263fd1f0ae959613a72c3fc3b4dbb100753

(windows CI update)

view details

push time in 6 hours

push eventrust-lang-nursery/rust-toolstate

Rust Toolstate Update

commit sha dcbdc3db19454ef8cc2ba8c644ce6d7615305265

(linux CI update)

view details

push time in 6 hours

pull request commentrust-lang/rfcs

RFC: Pointer metadata & VTable

Oh that middle pointer is a really cool trick. Congrats.

I feel that fn size_for_meta<T>(meta: <T as Pointee>::Metadata) -> usize and align_for_meta intrinsics would still be useful for other cases where such tricks might not be sufficient, such as a collections storing multiple DST values in a contiguous allocation analogous to Vec<dyn Any>.

On the other hand it’s less clear to me what not having {size,align}_for_meta enables.

While I tried to make this RFC not prevent future language extensions such as custom DSTs, to be honest I somewhat expect Rust to never have custom DSTs, or any DST much more complex than already exist. Rust already spent a lot "complexity budget" on other language features, and at some point pushing the type system further starts to have diminishing returns.

SimonSapin

comment created time in 6 hours

push eventrust-lang-nursery/rust-toolstate

Rust Toolstate Update

commit sha e5de18ab176ff8a139a9f9409fb2dd01c681d004

(windows CI update)

view details

push time in 9 hours

push eventrust-lang-nursery/rust-toolstate

Rust Toolstate Update

commit sha 9d49c6e0701166473f33fbd9bf378cd40dec415d

(linux CI update)

view details

push time in 9 hours

push eventrust-lang-nursery/rust-toolstate

Rust Toolstate Update

commit sha fe1bc2142416ead1617348fd8c3eaf7bcfea7934

📣 Toolstate changed by rust-lang/rust#81375! Tested on commit rust-lang/rust@7fba12bb1d3877870758a7a53e2fe766bb19bd60. Direct link to PR: <https://github.com/rust-lang/rust/pull/81375> 🎉 miri on windows: test-fail → test-pass (cc @oli-obk @eddyb @RalfJung).

view details

push time in 10 hours

pull request commentrust-lang/rfcs

RFC: Pointer metadata & VTable

No, ThinBox needs to know align_of for the value in order to compute the offset to the data.

Actually, it doesn't. Since the size of the meta-data is known at compile-time -- based on T -- it's possible to use a middle-pointer technique instead:

  1. Create a large allocation, similar to WithMeta.
  2. Compute the middle pointer as the allocated pointer + max(sizeof(T::MetaData), align(value))
  3. Write the value at the value at the middle pointer.
  4. Write the meta-data just before the middle pointer.
  5. Have ThinBox memorize the middle pointer.

This simplifies the code for Deref:

  • The meta-data is at -sizeof(T::MetaData) bytes before the middle pointer.
  • The data is right at the middle pointer.

The only moment where the alignment of the value is needed again is in Drop, but then we can just use Deref to get a complete fat-pointer and use size_of_value and align_of_value.

An example implementation can be found in the examples of https://crates.io/crates/rfc2580/0.2.0 .


As a result, I once again raise the question of whether the size, align and layout functions are necessary.

Conservatively, I would advise not exposing them -- even if they can be implemented -- for the moment.

SimonSapin

comment created time in 11 hours

pull request commentrust-lang/rfcs

Change visibility scoping rules for macro_rules macros

One migration plan would be to allow pub macro in all editions, emit deprecation warnings for #[macro_use], #[macro_export] and textual scoping in Edition 2018 and make them hard errors in Edition 2021. Thus the criterias from the Edition RFC should be satisfied:

  • As with today, each new version of the compiler may gain stabilizations and deprecations.
  • When opting in to a new edition, existing deprecations may turn into hard errors, and the compiler may take advantage of that fact to repurpose existing usage

This would mean that the mixed scoping behavior is only present in Edition 2018 (and probably Edition 2015), but Edition 2021 is fully migrated. I'm not sure if this still counts as having a "less than ideal intermediate state", but at least the new edition would have the consistent behaviour.

The concern about "too exciting edition" still applies though. Any macro that is defined in one file and used in another file would get a warning. Which probably are most macro usages.

How were the lints handled when Edition 2018 came out? (This could be described in the Prior Arts section) For bare_trait_objects, it was allow-by-default in Rust 1.31 and changed to warn-by-default in Rust 1.37. I haven't looked at other lints.

rylev

comment created time in 12 hours

push eventrust-lang-nursery/rust-toolstate

Rust Toolstate Update

commit sha fda21a5cd107f3bec43f6168aa8f5968f38d2889

(windows CI update)

view details

push time in 12 hours

push eventrust-lang-nursery/rust-toolstate

Rust Toolstate Update

commit sha e97868a6ce688919803e39dcbc362f1d79d6fbaa

(linux CI update)

view details

push time in 13 hours

startedkennytm/tzfile

started time in 14 hours

PR opened rust-lang/highfive

Format rust-lang/rust.json.

The formatting in this file has been abused so much with small changes over time. Time to remove some of the chaos.

+41 -18

0 comment

1 changed file

pr created time in 15 hours

push eventrust-lang-nursery/rust-toolstate

Rust Toolstate Update

commit sha ea0af64c1ebd965ace4465b585bc4f8e176b08e2

(windows CI update)

view details

push time in 15 hours

pull request commentrust-lang/rfcs

Enum name elison through inferred variant constructors

Since enum and module path both use ::, we can consider the mach ... in ... {} syntax. For example, the following code

match res.status() {
     tide::StatusCode::NotFound => Ok(tide::Response::new(tide::StatusCode::NotFound)),
     tide::StatusCode::InternalServerError => Ok("Something went wrong".into()),
     _ => Ok(res),
}

can be written as

match res.status() in tide::StatusCode {
     NotFound => Ok(tide::Response::new(NotFound)),
     InternalServerError => Ok("Something went wrong".into()),
     _ => Ok(res),
}

It can also used for matching any statics in a module path:

match value in mycrate::mymod {
     ONE => 1,
     TWO => 2,
     _ => 3,
}

if we have defined ONE and TWO in mycrate::mymod:

pub static ONE: usize = 0;
pub static TWO: usize = 1;
Rufflewind

comment created time in 15 hours

push eventrust-lang-nursery/rust-toolstate

Rust Toolstate Update

commit sha c0cf9f5be8b55e2e62f3207c3148f71c161a995e

(linux CI update)

view details

push time in 16 hours

push eventrust-lang/rust-repos

lists updater

commit sha 81fdc934bb4be3f22072afec65793a074d409fc6

Automatic lists update

view details

push time in 16 hours

more