bug#67141: 30.0.50; Missing element in the backtrace

[Stefan Monnier]

>>> If you want then I think we should consider this bug not only native
>>> comp related, as I explained we have this issue since long time in
>>> other circumstances.
>> I think it's qualitatively different, but yes, this is not the only
>> occurrence of the problem.  AFAICT, we have 3 different cases:
>>
>> A. Native compiled code making a "direct call" to a C primitive.
>> B. ELisp primitives with their own bytecode.
>> C. C code calling `Ffoo` instead of `Ffuncall (Qfoo, ...)`.
>>
>> (B) and (C) have been with us for ever.  They also suffer from being
>> unaffected by advice.  (A) on the other hand is new, but obeys advice.
>>
>> I think (C) is qualitatively very different from (A) because
>> (C) can be fixed by hand whenever we decide that it's a problem,
>
> Well ATM we can fix A by hand as well with a (declare (speed 0)) in the
> calling function.  Admittedly would be nice to have a more narrowed way
> to handle this at call site.  I'd e in favor of adding it.  Do you think
> this would be sufficient?

Don't know if it would be sufficient, nor if it would be useful.
I don't yet have enough experience with it to get a good intuition about
when we need that info and how we use it.  So far, most of the cases
where I noticed the absence of a function in the backtrace:

- I wasn't sure whether it was an occurrence of the current problem,
  or simply some misunderstanding on my part.
- I wouldn't have known which function call to annotate (I needed the
  backtrace info specifically to find that out :-(
- I de-optimized the function by redefining it (i.e. non-compiled) in
  order to solve the immediate lack of info.  It'd be good to reduce our
  reliance on interpreted ELisp code for debugging purposes, but so far,
  that's still our go-to tool, AFAICT.

I suspect that for the non-expert ELisp coder the above are serious problems.


        Stefan