What is the stability guarantee of `#[track_caller]` locations?

[scottmcm]

This is inspired by #87401

The general version of that bug is that any time a call to a trait method that might have had #[track_caller] in its impl is moved or wrapped, then the location can change. When, if ever, is a change to a location a breaking change?

[Aaron1011]

I would argue that the stability guarantees should be the same as for the output of Backtrace - that is, no guarantees at all. Both allow a program to observe private details about libcore/libstd, but we want to reserve the right to change those details at any time.

[the8472]

I think to do this correctly we need better backtrace support, similar to java's stack walker. That was introduced because their internal #[track_caller] equivalent (Reflection.getCallerClass()) that they used for security checks proved too brittle as the language evolved.

In other words prior art shows that relying on fixed-count stack frame inspection for important functionality is a maintenance burden and traversal with filtering is a more robust approach.

[m-ou-se]

We discussed this in the library api meeting just now. We agreed that #[track_caller] is not a promise that that attribute will stay there in the future. We can imagine such a promise might be made in the public documentation of a function, but that's not an implicit guarantee.

#[track_caller] is an important part of the quality of the standard library. Not having it in certain situations might be bad, but it's not a stability guarantee by itself.

[scottmcm]

Given that this is answered in #88302 (comment), I'll close it.