implement the `?` operator

[japaric]

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]

r? @arielb1

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

[oli-obk]

this line is too long for make tidy

[durka]

Needs a feature gate, right?

[japaric]

? is now behind a feature gate.

[brson]

🎉

[brson]

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

[brson]

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]

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]

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]

r? @nikomatsakis

(stealing review)

[nikomatsakis]

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]

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]

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

[japaric]

☔️ 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]

@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.

[japaric]

@bors: r=nikomatsakis

[bors]

📌 Commit 210dd61 has been approved by nikomatsakis

[bors]

⌛️ Testing commit 210dd61 with merge fc751a0...

[bors]

💔 Test failed - auto-linux-64-opt

[nikomatsakis]

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

[japaric]

@bors: r=nikomatsakis

[bors]

📌 Commit 2de4932 has been approved by nikomatsakis

[bors]

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

[bors]

☀️ 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]

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!