Fix tail calls to #[track_caller] functions

[WaffleLapkin]

We want #[track_caller] to be semver independent, i.e. it should not be a breaking change to add or remove it. Since it changes ABI of a function (adding an additional argument) we have to be careful to preserve this property when adding tail calls.

The only way to achieve this that I can see is:

• we forbid tail calls in functions which are marked with #[track_caller] (already implemented)
• tail-calling a #[track_caller] marked function downgrades the tail-call to a normal call (or equivalently tail-calls the shim made by fn def to fn ptr cast) (this pr)

Ideally the downgrade would be performed by a MIR pass, but that requires post mono MIR opts (cc @saethlin, #131650). For now I've changed code in cg_ssa to accomodate this behaviour (+ added a hack to mono collector so that the shim is actually generated)

Additionally I added a lint, although I don't think it's strictly necessary.

Alternative to #144762 (and thus closes #144762)
Fixes #144755

[rustbot]

r? @fee1-dead

rustbot has assigned @fee1-dead.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[WaffleLapkin]

I do not get it, both tests pass for me locally ?_?

[WaffleLapkin]

Update: @jieyouxu figured this out. It looks like the test suite that failed was running with --pass=check, which caused the tests that depend on diagnostic from codegen backend to fail. I've added //@ ignore-pass so it should be good now

[fee1-dead]

not too familiar with tail calls but the diff looks good to me

r? compiler

[WaffleLapkin]

r? lqd maybe (since you were excited about tail calls ^^')

[lqd]

It also LGTM -- though to be clear, I'm not familiar with the #[track_caller] infra. I wonder if people will have questions about the wording "has no special effect", as in "will not be TCEd yet".

Also, do we have to involve t-lang for new lints?

[VorpalBlade]

tail-calling a #[track_caller] marked function downgrades the tail-call to a normal call (or equivalently tail-calls the shim made by fn def to fn ptr cast) (this pr)

Would this be a silent downgrade? I think that would be a terrible idea, since for me the main usage of become is guaranteed tail calls for threaded interpreters. The tail call turning into a normal call means the code won't work and will eventually overflow the stack. This sort of implicit behaviour is the antithesis of what rust stands for.

[WaffleLapkin]

@lqd the wording is certainly not ideal, although I'm not entirely sure what would be the proper way to describe this situation. I don't think T-lang needs to be involved, since this lint is triggered only by an unstable/experimental feature (but they'll certainly have to look into the lint before stabilizing the feature).

@VorpalBlade it will not be silent, as this PR also adds a lint. However, note that functions marked with #[track_caller] can't tail call other functions, and as such can't participate in any tail call cycles, so you don't have any guarantees about stack exhaustion regardless.

[lqd]

Ok I wasn't aware of the procedure for new lints.

[lqd]

👍

[lqd]

nit, "a function" or "functions"