Don't back up past the caller when looking for an FnEntry span

[saethlin]

Fixes #2536

This adds a fix for the logic as well as a regression test. In the new test tests/fail/stacked_borrows/fnentry_invalidation2.rs, before this PR, we display this diagnostic:

help: <3278> was later invalidated at offsets [0x0..0xc] by a Unique FnEntry retag
  --> tests/fail/stacked_borrows/fnentry_invalidation2.rs:13:5
   |
13 |     inner(&mut t);
   |     ^^^^^^^^^^^^^

Which is very misleading. It is not this call itself, but what happens within the call that invalidates the tag we want. With this PR, we get:

help: <2798> was later invalidated at offsets [0x0..0xc] by a Unique FnEntry retag inside this call
  --> tests/fail/stacked_borrows/fnentry_invalidation2.rs:20:13
   |
20 |     let _ = t.sli.as_mut_ptr();
   |             ^^^^^^^^^^^^^^^^^^

Which is much better.

[RalfJung]

With this PR, we get:

What's still confusing me here is that I would expect a FnEntry retag to point at the beginning of a fn call.

[saethlin]

What's still confusing me here is that I would expect a FnEntry retag to point at the beginning of a fn call.

That's not how these spans work in general. Perhaps adding the detail about the "FnEntry retag" but not suggesting that it may be above this on the stack (my brain want to say below, but I suppose based on the above we'd say above) is what's confusing? These spans always walk the stack from the top until they get to some code in the local project, because that is usually where the user can take action.

I think the ideal output here would include both a local span which indicates where the issue is in the user's code, and also the FnEntry span which points at the argument, and possibly to another library's internals. I'll update with an attempt at that soon.

[RalfJung]

Conceptually, stacks always grow upwards. Have you ever tried adding something to the bottom of a stack of books? ;)

The fact that on x86 in the call stack, "higher" frames are located at "smaller" memory addresses, is entirely an implementation detail of how the stack is represented in the machine, but changes nothing about the conceptual orientation of the stack. IMO.

[RalfJung]

I think the ideal output here would include both a local span which indicates where the issue is in the user's code, and also the FnEntry span which points at the argument, and possibly to another library's internals. I'll update with an attempt at that soon.

Makes sense, though we can also make this a separate PR -- now that I understand the spec and purpose of get_parent.

[bors]

☔ The latest upstream changes (presumably #2548) made this pull request unmergeable. Please resolve the merge conflicts.

[RalfJung]

Thanks!
@bors r+

[bors]

📌 Commit fdc7dc3 has been approved by RalfJung

It is now in the queue for this repository.

[bors]

⌛ Testing commit fdc7dc3 with merge 3e91125...

[bors]

☀️ Test successful - checks-actions
Approved by: RalfJung
Pushing 3e91125 to master...