-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial support for ..=
syntax
#44709
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @aturon (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
@@ -153,5 +153,5 @@ fn exclusive_to_inclusive_range(slice: &[u32]) -> &[u32] { | |||
#[rustc_metadata_clean(cfg="cfail2")] | |||
#[rustc_metadata_clean(cfg="cfail3")] | |||
fn exclusive_to_inclusive_range(slice: &[u32]) -> &[u32] { | |||
&slice[3...7] | |||
&slice[3..=7] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sigh, the syntax is incredibly ugly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now I see all these examples, I am more convinced than ever that this syntax is a bad idea.
src/libsyntax/parse/token.rs
Outdated
@@ -147,6 +147,8 @@ pub enum Token { | |||
Dot, | |||
DotDot, | |||
DotDotDot, | |||
DotDotEquals, | |||
DotEq, // HACK(durka42) never produced by the parser, only used for libproc_macro |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is the token called DotDotEquals
, not DotDotEq
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, that's a good name! I will probably change it.
I should have mentioned this earlier: right now we issue a warning if |
@Badel2: |
src/libcore/slice/mod.rs
Outdated
@@ -16,6 +16,9 @@ | |||
|
|||
#![stable(feature = "rust1", since = "1.0.0")] | |||
|
|||
// FIXME: replace remaining ... by ..= after next stage0 | |||
// Silence warning: "... is being replaced by ..=" | |||
#![cfg_attr(not(stage0), allow(warnings))] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Errr is there no way to silence just the `...` is being replaced by `..=`
message, instead of all warnings?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's because the warn_dotdoteq
function just shows a generic warning without any flag.
@kennytm how do you output a warning that has a name to use in
`#[allow(xxx)]`?
…On Wed, Sep 20, 2017 at 1:06 PM, kennytm ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In src/libcore/slice/mod.rs
<#44709 (comment)>:
> @@ -16,6 +16,9 @@
#![stable(feature = "rust1", since = "1.0.0")]
+// FIXME: replace remaining ... by ..= after next stage0
+// Silence warning: "... is being replaced by ..="
+#![cfg_attr(not(stage0), allow(warnings))]
Errr is there no way to silence just the `...` is being replaced by `..=`
message, instead of all warnings?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#44709 (review)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAC3n0SAa_AvtFHv1wjPdDXS-Z8LmnzIks5skUYSgaJpZM4PdN3Z>
.
|
@durka Turn the I'm just afraid |
@kennytm want to join as a co-mentor? I have no idea how to make lints.
…On Wed, Sep 20, 2017 at 1:16 PM, kennytm ***@***.***> wrote:
@durka <https://github.com/durka> Turn the ... checking into an early
lint?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#44709 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAC3n94QeDtdH-6Fw9yMVYZ0rVB0fgxHks5skUhegaJpZM4PdN3Z>
.
|
Actually a lint may be not desirable, since lints are run after the AST is built, but these warnings are emitted during parsing. So either the AST needs to retain knowledge whether the closed range is of the form |
Yeah, for the lint we would need to add an "old syntax was used" flag to
the AST.
…On Wed, Sep 20, 2017 at 1:51 PM, kennytm ***@***.***> wrote:
Actually a lint may be not desirable, since lints are run after the AST is
built, but these warnings are emitted during parsing. So either the AST
needs to retain knowledge whether the closed range is of the form x ... y
or x ..= y, or the lint pass will need to re-parse the expression to
figure out which operator is used.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#44709 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAC3n0PlBaBjfMZmamF_rwFSjHZNuwUAks5skVC9gaJpZM4PdN3Z>
.
|
@kennytm I guess one solution would be temporally replacing |
@Badel2 LGTM. Retain the "Change |
@@ -2770,12 +2774,13 @@ impl<'a> Parser<'a> { | |||
} | |||
}; | |||
continue | |||
} else if op == AssocOp::DotDot || op == AssocOp::DotDotDot { | |||
// If we didn’t have to handle `x..`/`x...`, it would be pretty easy to | |||
} else if op == AssocOp::DotDot || op == AssocOp::DotDotEq { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like op == AssocOp::DotDotDot
shouldn't be removed from here yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, it's AssocOp
, nevermind.
@Badel2 |
a42fc89
to
ff012da
Compare
All right, I admit it looks way better now with only two commits. |
@bors r+ |
📌 Commit ff012da has been approved by |
@petrochenkov You mean like this?
And how I call the feature? dotdoteq_in_patterns? |
@Badel2 enum RangeSyntax {
DotDotDot,
DotDotEq,
} and it's better inserted into
LGTM. |
720782b
to
c947e05
Compare
💔 Test failed - status-appveyor |
[01:05:00] error[E0532]: expected unit struct/variant or constant, found tuple variant `RangeEnd::Included`
[01:05:00] --> src\tools\rustfmt\src\patterns.rs:62:17
[01:05:00] |
[01:05:00] 62 | RangeEnd::Included => rewrite_pair(&**lhs, &**rhs, "", "...", "", context, shape),
[01:05:00] | ^^^^^^^^^^--------
[01:05:00] | |
[01:05:00] | did you mean `Excluded`? Does this need the synchronized rustfmt update dance? |
@scottmcm if the "synchronized rustfmt update dance" is too complicated, a simple workaround would be temporarily replacing |
@Badel2 |
@petrochenkov that's the only error. So I guess now I need to submit a PR to the rustfmt repo? |
Yes. |
dde0c7c
to
5102309
Compare
@bors r+ |
📌 Commit 5102309 has been approved by |
☀️ Test successful - status-appveyor, status-travis |
This shows one warning in a case and no warning in another case:
|
@leonardo-m yes, that's the expected behavior, and in the near future the second case will not compile. We can't warn on the first case because that's been stable for a long time. |
I don't understand why an unstable |
Because some people fear that |
@Flaise the unstable |
The syntax decision was extensively discussed in the tracking issue (linked
at the top of this PR). We don't need to rehash it here.
…On Oct 4, 2017 16:31, "b-ambrus" ***@***.***> wrote:
@Flaise <https://github.com/flaise> the unstable ... syntax is utterly
confusing to some people, because in Ruby, .. means an inclusive range
and ... means a half-inclusive.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#44709 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAC3n_eG31F6K1NtQmhBuIYxdJqwqwx4ks5so5angaJpZM4PdN3Z>
.
|
To Rust Core Team: Regardless of community's opposition and made a wrong decision, You'll regret it!
|
I just realized there is one test that still uses the old syntax in expressions, doesn't show my warning, and doesn't use the feature gate.
|
@Badel2 |
#28237
This PR adds
..=
as a synonym for...
in patterns and expressions.Since
...
in expressions was never stable, we now issue a warning.cc @durka
r? @aturon