-
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
implement the ?
operator
#31954
implement the ?
operator
#31954
Conversation
r? @arielb1 (rust_highfive has picked a reviewer for you, use r? to override) |
expr_call(lctx, e.span, err_ctor, hir_vec![from_expr], None) | ||
}; | ||
let err_pat = pat_err(lctx, e.span, pat_ident(lctx, e.span, err_ident)); | ||
let ret_expr = expr(lctx, e.span, hir::Expr_::ExprRet(Some(err_expr)), None); |
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.
this line is too long for make tidy
Needs a feature gate, right? |
|
🎉 |
It might be useful to have tests of what happens when the try expansion fails to resolve. Is it nice? Hideous? |
Here's the |
The RFC claims this feature flag should be |
I don't have a build at hand, but the error message should be similar to the one for unresolved #![feature(no_core)]
#![no_core]
fn main() {
for x in xs {}
}
@seanmonstar will push a commit renaming the feature gate in a bit. |
(stealing review) |
So first review done, comments:
(I'll take another look afterwards.) |
Done. The impl looks simpler now. :-)
You mean like checking that
I've added a test for this. |
☔ The latest upstream changes (presumably #30884) made this pull request unmergeable. Please resolve the merge conflicts. |
Will rebase after @nikomatsakis takes a second look :-). |
The changes look great. r=me, feel free to rebase. :)
No, I meant some kind of test that |
The `?` postfix operator is sugar equivalent to the try! macro, but is more amenable to chaining: `File::open("foo")?.metadata()?.is_dir()`. `?` is accepted on any *expression* that can return a `Result`, e.g. `x()?`, `y!()?`, `{z}?`, `(w)?`, etc. And binds more tightly than unary operators, e.g. `!x?` is parsed as `!(x?)`. cc rust-lang#31436
@bors: r=nikomatsakis |
📌 Commit 210dd61 has been approved by |
⌛ Testing commit 210dd61 with merge fc751a0... |
💔 Test failed - auto-linux-64-opt |
@japaric some error messages need correcting: http://buildbot.rust-lang.org/builders/auto-linux-64-opt/builds/8286/steps/test/logs/stdio |
@bors: r=nikomatsakis |
📌 Commit 2de4932 has been approved by |
implement the `?` operator The `?` postfix operator is sugar equivalent to the try! macro, but is more amenable to chaining: `File::open("foo")?.metadata()?.is_dir()`. `?` is accepted on any *expression* that can return a `Result`, e.g. `x()?`, `y!()?`, `{z}?`, `(w)?`, etc. And binds more tightly than unary operators, e.g. `!x?` is parsed as `!(x?)`. cc #31436 --- cc @aturon @eddyb
The
?
postfix operator is sugar equivalent to the try! macro, but is more amenable to chaining:File::open("foo")?.metadata()?.is_dir()
.?
is accepted on any expression that can return aResult
, e.g.x()?
,y!()?
,{z}?
,(w)?
, etc. And binds more tightly than unary operators, e.g.!x?
is parsed as!(x?)
.cc #31436
cc @aturon @eddyb