I found that having the whole life of an expression is quite an useful tool when looking at -dflambda (and probably for gdb too). Would you consider it right to always call set_inline_debuginfo , but mark whether it was in tail position to avoid adding it to the stack trace ?

@chambart Seems like a good idea, I tried to implement it. Please have another look.

The tail field of the environment should be set to true inside the body of an inline expression, otherwise, if a function is inlined in non tail position containing a tail call to another one which is also inlined when the first one is, then that tail call will be considered not tail.

This is probably clearer with an example:

let tail_called b =
  if b then (big expression wich prevent inlining)
  raise Exit

let non_tail_called b =
  tail_called b

let () =
  try non_tail_called false with e -> raise e

If inlining non_tail_called trigger the inlining of tail_called then the call to tail_called will be considered non-tail.

For some more complex situations, non_tail_called could be inlined at the first round while tail_called would be during the second. In that case we wouldn't have any information left telling that the application was in tail position. This probably means that the only way to remember that is to annotate the Apply expression with the original tail information. This annotation should be added by closure_conversion.

@chambart Thanks for spending time on this. I spoke to @let-def this morning having considered your comments. I'm concerned that we're not actually going to be able to pin down a reasonable semantics for this and that in fact it may, on balance, not be worth adding this extra code to the compiler at all. (Factors such as optimisations within Flambda turning non-tail calls into tail calls, the various tricky things about inlining as @chambart mentions, the fact that we don't know until well into the backend whether a particular call will actually be tail or not, etc.) I don't think we should add this code if it's going to be fragile and/or hard to understand, which I am now suspecting it might be. Instead, we should discourage the matching in tests on explicit backtraces in almost all cases, on the basis of it being a quality of implementation feature rather than a prescribed language semantics.

I think we decided not to proceed with this.