Skip to content

Support ? mark in nightlies as alternative to try! #867

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

Closed
tupshin opened this issue Mar 14, 2016 · 12 comments
Closed

Support ? mark in nightlies as alternative to try! #867

tupshin opened this issue Mar 14, 2016 · 12 comments

Comments

@tupshin
Copy link

tupshin commented Mar 14, 2016

No description provided.

@nrc
Copy link
Member

nrc commented Mar 14, 2016

Should be behind an option until ? is stable.

@kamalmarhubi
Copy link
Contributor

This is behind the question_mark lang feature.

kamalmarhubi added a commit to kamalmarhubi/rustfmt that referenced this issue Mar 29, 2016
This bump includes ability to parse inclusive ranges (`a...b`) and the
question mark operator.

Refs rust-lang#867, rust-lang#890
@marcusklaas marcusklaas self-assigned this Mar 29, 2016
@marcusklaas
Copy link
Contributor

This makes method chain formatting a bit more complex. Looking into this.

@kamalmarhubi
Copy link
Contributor

Should be behind an option until ? is stable.

Shouldn't we format code that uses it? Or use the #![feature(question_mark)] as a mark that the code is opting in.

@marcusklaas
Copy link
Contributor

Yea, I don't think it needs to be behind an option either.

@kamalmarhubi
Copy link
Contributor

Having written that, I realize that if we are formatting individual files, we'd also have to find the crate root to see what features are in use. I kind of lean towards just accepting it unconditionally anyway.

@marcusklaas
Copy link
Contributor

Me too.

@nrc
Copy link
Member

nrc commented Apr 4, 2016

To clarify I meant that there should be an option which changes try!(expr) to expr?. Just formatting expr? doesn't need to be behind an option,

@nrc nrc added this to the 1.0 milestone Apr 6, 2016
@mcarton
Copy link
Member

mcarton commented Apr 14, 2016

Pinging that issue, rustfmt produces weird diffs on Clippy:

@@ -57,11 +57,11 @@ impl<'a, 'tcx, 'v> Hir2Qmm<'a, 'tcx, 'v> {
         for a in a {
             if let ExprBinary(binop, ref lhs, ref rhs) = a.node {
                 if binop.node == op {
-                    v = self.extract(op, &[lhs, rhs], v)?;
+                    v = self.extract(op, &[lhs, rhs], v)?;;
                     continue;
                 }
             }
-            v.push(self.run(a)?);
+            v.push(self.run(a)?));
         }
         Ok(v)
     }
@@ -70,22 +70,22 @@ impl<'a, 'tcx, 'v> Hir2Qmm<'a, 'tcx, 'v> {
         // prevent folding of `cfg!` macros and the like
         if !in_macro(self.cx, e.span) {
             match e.node {
-                ExprUnary(UnNot, ref inner) => return Ok(Bool::Not(box self.run(inner)?)),
+                ExprUnary(UnNot, ref inner) => return Ok(Bool::Not(box self.run(inner)?))),
                 ExprBinary(binop, ref lhs, ref rhs) => {
                     match binop.node {
-                        BiOr => return Ok(Bool::Or(self.extract(BiOr, &[lhs, rhs], Vec::new())?)),
-                        BiAnd => return Ok(Bool::And(self.extract(BiAnd, &[lhs, rhs], Vec::new())?)),
-                        _ => {},
+                        BiOr => return Ok(Bool::Or(self.extract(BiOr, &[lhs, rhs], Vec::new())?))),
+                        BiAnd => return Ok(Bool::And(self.extract(BiAnd, &[lhs, rhs], Vec::new())?))),

@marcusklaas
Copy link
Contributor

marcusklaas commented Apr 14, 2016

@mcarton: is that on the master branch, or using #893?

Edit: either way, it's a bug in the rustc parser that has been fixed, but is still in syntex.

@mcarton
Copy link
Member

mcarton commented Apr 14, 2016

@marcusklaas didn’t see that PR, just tested with it, works as expected 👍

@marcusklaas
Copy link
Contributor

Closed by #893.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants