D7178: [RFC] rust-matchers: add `Matcher` trait and implement `AlwaysMatcher`

2019-11-06 Thread yuja (Yuya Nishihara)
yuja added a comment. > +pub trait Matcher { > +/// Explicitly listed files > +fn file_set() -> HashSet<>; [...] > +/// Matcher will match everything and `files_set()` will be empty: > +/// optimization might be possible. > +fn matches_everything() -> bool

Re: D7178: [RFC] rust-matchers: add `Matcher` trait and implement `AlwaysMatcher`

2019-11-06 Thread Yuya Nishihara
> +pub trait Matcher { > +/// Explicitly listed files > +fn file_set() -> HashSet<>; [...] > +/// Matcher will match everything and `files_set()` will be empty: > +/// optimization might be possible. > +fn matches_everything() -> bool { > +false > +} Maybe better

D7178: [RFC] rust-matchers: add `Matcher` trait and implement `AlwaysMatcher`

2019-11-05 Thread Raphaël Gomès
Closed by commit rHGa77d4fe347a4: rust-matchers: add `Matcher` trait and implement `AlwaysMatcher` (authored by Alphare). This revision was automatically updated to reflect the committed changes. This revision was not accepted when it landed; it landed in state "Needs Review". REPOSITORY rHG

D7178: [RFC] rust-matchers: add `Matcher` trait and implement `AlwaysMatcher`

2019-11-05 Thread martinvonz (Martin von Zweigbergk)
martinvonz added a comment. In D7178#106175 , @martinvonz wrote: > From `test-check-commit.t`: > > @@ -25,3 +25,10 @@ > > fi > > done > > fi > + Revision e4f5ab3faa27 does not comply with rules > +

D7178: [RFC] rust-matchers: add `Matcher` trait and implement `AlwaysMatcher`

2019-11-05 Thread martinvonz (Martin von Zweigbergk)
martinvonz added a comment. From `test-check-commit.t`: @@ -25,3 +25,10 @@ > fi > done > fi + Revision e4f5ab3faa27 does not comply with rules + -- + 6: summary line doesn't start with 'topic:

D7178: [RFC] rust-matchers: add `Matcher` trait and implement `AlwaysMatcher`

2019-10-31 Thread Raphaël Gomès
Alphare added inline comments. INLINE COMMENTS > martinvonz wrote in matchers.rs:20-21 > Is `Empty` needed as an optimization? Or could we just use an empty set? I feel like Rust enums are really cheap to make and maintain, and since the original code hints at possible optimizations for this

D7178: [RFC] rust-matchers: add `Matcher` trait and implement `AlwaysMatcher`

2019-10-31 Thread Raphaël Gomès
Alphare marked 6 inline comments as done. Alphare updated this revision to Diff 17417. REPOSITORY rHG Mercurial CHANGES SINCE LAST UPDATE https://phab.mercurial-scm.org/D7178?vs=17412=17417 BRANCH default CHANGES SINCE LAST ACTION https://phab.mercurial-scm.org/D7178/new/ REVISION

D7178: [RFC] rust-matchers: add `Matcher` trait and implement `AlwaysMatcher`

2019-10-30 Thread kevincox (Kevin Cox)
kevincox added a comment. I see a lot of the functions are here to give optimization hints. In order to make someone non-familiar with the code able to understand it each method should state the contracts that it is making. I am having a really hard time reconciling how the different

D7178: [RFC] rust-matchers: add `Matcher` trait and implement `AlwaysMatcher`

2019-10-30 Thread martinvonz (Martin von Zweigbergk)
martinvonz added inline comments. martinvonz added subscribers: spectral, martinvonz. INLINE COMMENTS > matchers.rs:19-22 > +Recursive, > +Empty, > +Set(HashSet), // Should we implement a `NonEmptyHashSet`? > +This, Could you add a comment explaining what each value means? (I

D7178: [RFC] rust-matchers: add `Matcher` trait and implement `AlwaysMatcher`

2019-10-29 Thread Raphaël Gomès
Alphare created this revision. Herald added subscribers: mercurial-devel, kevincox, durin42. Herald added a reviewer: hg-reviewers. REVISION SUMMARY In our quest of a faster Mercurial, we have arrived at the point where we need to implement the matchers in Rust. This RFC mainly for the