WIP Switch x? desugaring to use QuestionMark trait and Try enum

[bluss]

I opened a PR because I wanted this to compile on travis.

[rust-highfive]

r? @aturon

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

[bluss]

Edit: Fixed Stops on type inference error

error[E0282]: unable to infer enough type information about `_`
   --> /checkout/src/librustc/hir/def_id.rs:124:21
    |
124 |                     write!(f, " => {}", def_path.to_string(tcx))?;
    |                     ---------------------------------------------
    |                     |
    |                     cannot infer type for `_`
    |                     in this macro invocation
    |
    = note: type annotations or generic parameter binding required

error: aborting due to previous error

error: Could not compile `rustc`.

source is:

impl fmt::Debug for DefId {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        write!(f, "DefId {{ krate: {:?}, node: {:?}",
               self.krate, self.index)?;

        ty::tls::with_opt(|opt_tcx| {
            if let Some(tcx) = opt_tcx {
                if let Some(def_path) = tcx.opt_def_path(*self) {
                    write!(f, " => {}", def_path.to_string(tcx))?;       //  <--- LINE 124
                }
            }
            Ok(())
        })?;

        write!(f, " }}")
    }
}

Note the second ? on line 128.

[withoutboats]

Do you have any idea why inference is failing there? It seems to me that between line 124 and 127 the full return type of the closure should be inferrable.

[bluss]

Not sure. It must be the Err(X) part that is the problem? Without thinking, I used e.into() here instead of using From as the old desugaring; I must try again while sticking to From. (Edit: This worked out ✅ )

[bluss]

I'm sorry for all the noise it took to get this to compile and be type inference compatible. Now we have proven one of the popular shapes of the API from the discussion of the future of Carrier. (Now: onto harder problems like naming and optimization?)

For completeness, I test ran this compiler against #37939 and there is (not surprisingly) no improvement. But: this PR's implementation could be what we have to optimize in the future for instead of the Carrier trait currently in the tree.