implement the `?` operator#31954

japaric · 2016-02-28T23:27:34Z

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

rust-highfive · 2016-02-28T23:27:39Z

r? @arielb1

(rust_highfive has picked a reviewer for you, use r? to override)

oli-obk · 2016-02-29T08:22:48Z

src/librustc_front/lowering.rs

this line is too long for make tidy

durka · 2016-02-29T14:52:28Z

Needs a feature gate, right?

japaric · 2016-02-29T15:57:04Z

? is now behind a feature gate.

brson · 2016-02-29T21:23:07Z

🎉

brson · 2016-02-29T21:29:22Z

It might be useful to have tests of what happens when the try expansion fails to resolve. Is it nice? Hideous?

brson · 2016-02-29T21:31:29Z

Here's the try test case. I think it looks nice. The ? really gets out of the way so you don't notice the error handling.

seanmonstar · 2016-03-01T07:23:02Z

The RFC claims this feature flag should be question_mark. https://github.com/rust-lang/rfcs/blob/master/text/0243-trait-based-exception-handling.md

japaric · 2016-03-01T14:38:42Z

It might be useful to have tests of what happens when the try expansion fails to resolve. Is it nice? Hideous?

I don't have a build at hand, but the error message should be similar to the one for unresolved for loops. The one for for loops looks like this:

#![feature(no_core)]
#![no_core]

fn main() {
    for x in xs {}
}

$ rustc for.rs
for.rs:5:14: 5:16 help: run `rustc --explain E0425` to see a detailed explanation
for.rs:5:5: 5:9 error: failed to resolve. Maybe a missing `extern crate iter`? [E0433]
for.rs:5     for x in xs {}
             ^~~~
for.rs:5:5: 5:9 help: run `rustc --explain E0433` to see a detailed explanation
for.rs:5:5: 5:19 error: unresolved name `iter::IntoIterator::into_iter` [E0425]
for.rs:5     for x in xs {}
             ^~~~~~~~~~~~~~
for.rs:5:5: 5:19 help: run `rustc --explain E0425` to see a detailed explanation
for.rs:5:5: 5:9 error: failed to resolve. Maybe a missing `extern crate iter`? [E0433]
for.rs:5     for x in xs {}
             ^~~~
for.rs:5:5: 5:9 help: run `rustc --explain E0433` to see a detailed explanation
for.rs:5:5: 5:19 error: unresolved name `iter::Iterator::next` [E0425]
for.rs:5     for x in xs {}
             ^~~~~~~~~~~~~~
for.rs:5:5: 5:19 help: run `rustc --explain E0425` to see a detailed explanation
for.rs:5:5: 5:19 error: unresolved enum variant, struct or const `Some` [E0419]
for.rs:5     for x in xs {}
             ^~~~~~~~~~~~~~
for.rs:5:5: 5:19 help: run `rustc --explain E0419` to see a detailed explanation
for.rs:5:5: 5:19 error: unresolved enum variant, struct or const `None` [E0419]
for.rs:5     for x in xs {}
             ^~~~~~~~~~~~~~

@seanmonstar will push a commit renaming the feature gate in a bit.

nikomatsakis · 2016-03-04T17:11:32Z

r? @nikomatsakis

(stealing review)

nikomatsakis · 2016-03-04T17:13:34Z

So first review done, comments:

Move parsing code into parse_dot_or_call_expr_with_ instead
Move feature-gate code into PostExpansionVisitor
Feels like there could/should be some negative tests, but I'm not sure precisely what :) maybe not needed

(I'll take another look afterwards.)

japaric · 2016-03-06T00:39:57Z

Move parsing code into parse_dot_or_call_expr_with_ instead
Move feature-gate code into PostExpansionVisitor

Done. The impl looks simpler now. :-)

Feels like there could/should be some negative tests, but I'm not sure precisely what :) maybe not needed

You mean like checking that ExprKind::Try(ExprKind::Binary) is never created?

This seems to be roughly what we do elsewhere -- but do we need to do anything to make hygiene work out for us? Can we make a test where the context defines const val: u32 = 0 or something, just to make sure that the name val here is always a binding and does not conflict with this in-scope constant?

I've added a test for this.

bors · 2016-03-06T09:22:56Z

☔ The latest upstream changes (presumably #30884) made this pull request unmergeable. Please resolve the merge conflicts.

japaric · 2016-03-06T13:01:19Z

☔ The latest upstream changes (presumably #30884) made this pull request unmergeable. Please resolve the merge conflicts.

Will rebase after @nikomatsakis takes a second look :-).

nikomatsakis · 2016-03-07T19:05:50Z

@japaric

The changes look great. r=me, feel free to rebase. :)

You mean like checking that ExprKind::Try(ExprKind::Binary) is never created?

No, I meant some kind of test that a + b? parses as expected, but it doesn't seem necessary now with the newer code.

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

japaric · 2016-03-07T20:28:02Z

@bors: r=nikomatsakis

bors · 2016-03-07T20:28:04Z

📌 Commit 210dd61 has been approved by nikomatsakis

bors · 2016-03-07T22:03:35Z

⌛ Testing commit 210dd61 with merge fc751a0...

bors · 2016-03-07T22:49:36Z

💔 Test failed - auto-linux-64-opt

nikomatsakis · 2016-03-08T01:25:12Z

@japaric some error messages need correcting: http://buildbot.rust-lang.org/builders/auto-linux-64-opt/builds/8286/steps/test/logs/stdio

japaric · 2016-03-08T02:18:36Z

@bors: r=nikomatsakis

bors · 2016-03-08T02:18:37Z

📌 Commit 2de4932 has been approved by nikomatsakis

bors · 2016-03-08T09:31:04Z

⌛ Testing commit 2de4932 with merge 3af60f8...

@aturon

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

bors · 2016-03-08T11:31:28Z

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-mac-ios-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt

perlun · 2017-08-11T18:33:32Z

For the record, this was stabilized as part of 1.13.0, i.e no longer behind a feature gate. I hadn't seen it until now, when I happened to see it being referred to in the docs. 😉 Nice with some more syntactic sugar!

rust-highfive assigned arielb1 Feb 28, 2016

japaric mentioned this pull request Feb 28, 2016

Tracking issue for ? operator and try blocks (RFC 243, question_mark & try_blocks features) #31436

Open

16 tasks

oli-obk reviewed Feb 29, 2016
View reviewed changes

src/librustc_front/lowering.rs Outdated

Copy link

Contributor

oli-obk Feb 29, 2016

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

rust-highfive assigned nikomatsakis and unassigned arielb1 Mar 4, 2016

japaric force-pushed the rfc243 branch from d6a9621 to 210dd61 Compare March 7, 2016 20:27

update error messages in parse-fail tests

2de4932

bors merged commit 2de4932 into rust-lang:master Mar 8, 2016

This was referenced Mar 8, 2016

Consistent no_prelude attribute #32025

Closed

[RFC] Implement .. in tuple (struct) patterns #32079

Closed

mcarton mentioned this pull request Mar 9, 2016

Rustup to rustc 1.9.0-nightly (eabfc160f 2016-03-08) rust-lang/rust-clippy#752

Merged

japaric deleted the rfc243 branch March 10, 2016 16:34

janhohenheim mentioned this pull request Jul 24, 2017

Use ? instead of try! TrionProg/nes#1

Open

stevenroose mentioned this pull request Apr 28, 2020

Support overriding the ? behavior locally (by redefining the try! macro) #71643

Closed

Uh oh!

Conversation

japaric commented Feb 28, 2016

Uh oh!

rust-highfive commented Feb 28, 2016

Uh oh!

oli-obk Feb 29, 2016

Choose a reason for hiding this comment

Uh oh!

durka commented Feb 29, 2016

Uh oh!

japaric commented Feb 29, 2016

Uh oh!

brson commented Feb 29, 2016

Uh oh!

brson commented Feb 29, 2016

Uh oh!

brson commented Feb 29, 2016

Uh oh!

seanmonstar commented Mar 1, 2016

Uh oh!

japaric commented Mar 1, 2016

Uh oh!

nikomatsakis commented Mar 4, 2016

Uh oh!

nikomatsakis commented Mar 4, 2016

Uh oh!

japaric commented Mar 6, 2016

Uh oh!

bors commented Mar 6, 2016

Uh oh!

japaric commented Mar 6, 2016

Uh oh!

nikomatsakis commented Mar 7, 2016

Uh oh!

japaric commented Mar 7, 2016

Uh oh!

bors commented Mar 7, 2016

Uh oh!

bors commented Mar 7, 2016

Uh oh!

bors commented Mar 7, 2016

Uh oh!

nikomatsakis commented Mar 8, 2016

Uh oh!

japaric commented Mar 8, 2016

Uh oh!

bors commented Mar 8, 2016

Uh oh!

bors commented Mar 8, 2016

Uh oh!

bors commented Mar 8, 2016

Uh oh!

perlun commented Aug 11, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants