MIR support is actually not hard (I already have a MIR impl in the compiler after all), but I'm not sure how to properly lower it from hir. become x is only valid if x is a call (f(x), y.m()) and MIR really would like to see this as simple as possible.

In the compiler I lower HIR->THIR as-is, then run a check on THIR that tail calls are well-formed and then do something akin to this:

let Expr::Call { ..... } = expr
    else { bug!("THIR checks should have noticed that tail call doesn't have a call") };

Not sure what is the best way to do this in r-a

What is the problem of doing the same in r-a? Just instead of bug! use not_supported! or add a variant to MirLowerError.

The problem is that THIR has much simpler representation of functions and I'm not sure how to correctly handle both function and method calls.

Aha. How it will be a lowered into mir? It would be a new terminator, like BecomeCall?

Yes, it will be a new TailCall terminator. There is an experimental branch, it looks like this:

    TailCall {
        /// The function that’s being called.
        func: Operand<'tcx>,
        /// Arguments the function is called with.
        /// These are owned by the callee, which is free to modify them.
        /// This allows the memory occupied by "by-value" arguments to be
        /// reused across function calls without duplicating the contents.
        args: Vec<Operand<'tcx>>,
        // FIXME(explicit_tail_calls): should we have the span for `become`? is this span accurate? do we need it?
        /// This `Span` is the span of the function, without the dot and receiver
        /// (e.g. `foo(a, b)` in `x.foo(a, b)`
        fn_span: Span,
    },

So I see three ways to implement it:

1. Handle all cases manually. Assuming that become doesn't support overloaded operators, it is just call and method call.
2. Adding a field to InferenceResult for recording the simple form of function calls (or changing the current method_resolution field). This is similar to THIR in rustc.
3. Adding a flag to MirLowerCtx, which if true it means the next Terminator::Call should be Terminator::TailCall.

If you want to go with 2, I would suggest doing it in a separate PR, to minimize git conflicts (Assuming this PR is going to be not merged in a long time)

I think 3 is error prone with code like

become 1; // invalid
f(); // becomes tail call

2 I'm not exactly sure I understand.

Assuming that become doesn't support overloaded operators

Yes, this is true.

I think 1 would be easiest to go with for now even if it's not the cleanest. 2 seems kind of invasive with the current structure I think

This is also my understanding, yes. I'll try option 1.