[rust-dev] Tail call compatibility

Andrea Canciani ranma42 at gmail.com
Sat Dec 27 08:39:04 PST 2014

I tried to collect as much information as possible from IRC and from the
Web about TCO in Rust.

The most recent (and authoritative) reference I can find is
The decision seems to be that it is an interesting feature, but that it
should be postponed for a future release.
To me this looks like a good point, but I'm worried about potential
backward-compatibility hazards.

In particular, the "be" keyword has been removed from the language and the
proposed alternative ("become") has never been introduced. Wouldn't it be
easier to ensure backward compatibility if the "become" keyword was at
reserved in rust 1.0?

Another thing I'm worried about is callee vs. caller cleanup of the call
stack. Changing the rust calling convention post-1.0 would break the ABI,
so it would be very inconvenient.
On IRC I was told that rustc was already using the LLVM "fastcall" calling
convention, but
seems to indicate that the C calling convention is used instead.
In several posts on the TCO, one of the points against supporting TCO was
that it involves using a slower calling convention, but I was unable to
find any benchmark to support that statement.
Where can I find some discussions about the [dis]advantages of the
different calling conventions and what design choices led to the current

I would like to evaluate the performance (speed, code size) impact of
changing the calling convention. What would be the best way to do this? Is
there any "well-known" benchmark for changes that affect the overall
behavior of the compiler?
I would assume that rustc itself is probably one of the most interesting
"real-world" applications written in rust right now. Otherwise, is the
compiler shootout challenge sufficiently interesting for this purpose?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20141227/4ed5f5db/attachment.html>

More information about the Rust-dev mailing list