Custom MIR: Allow optional RET type annotation

[cbeuw]

This currently doesn't compile because the type of RET is inferred, which fails if RET is a composite type and fields are initialised separately.

#![feature(custom_mir, core_intrinsics)]
extern crate core;
use core::intrinsics::mir::*;
#[custom_mir(dialect = "runtime", phase = "optimized")]
fn fn0() -> (i32, bool) {
    mir! ({
        RET.0 = 0;
        RET.1 = true;
        Return()
    })
}

error[E0282]: type annotations needed
 --> src/lib.rs:8:9
  |
8 |         RET.0 = 0;
  |         ^^^ cannot infer type

For more information about this error, try `rustc --explain E0282`.

This PR allows the user to manually specify the return type with type RET = ...; if required:

#[custom_mir(dialect = "runtime", phase = "optimized")]
fn fn0() -> (i32, bool) {
    mir! (
        type RET = (i32, bool);
        {
            RET.0 = 0;
            RET.1 = true;
            Return()
        }
    )
}

The syntax is not optimal, I'm happy to see other suggestions. Ideally I wanted it to be a normal type annotation like let RET: ...;, but this runs into the multiple parsing options error during macro expansion, as it can be parsed as a normal let declaration as well.

r? @oli-obk or @tmiasko or @JakobDegen

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[JakobDegen]

Actually quite like this solution

[tmiasko]

@bors r=JakobDegen rollup

[bors]

📌 Commit 9dc275b has been approved by JakobDegen

It is now in the queue for this repository.