tlparse should report symint specialization in tensor subclass torch_dispatch

[zou3519]

Today, if a specialization for a symint happens inside a tensor subclass's torch_dispatch, we never actually report it in a call stack.

Instead, we see the user callstack, which can be confusing. Repro: run tlparse on the following, https://gist.github.com/zou3519/476a049ffd8070973dd31a4eba9f2ca7 , this produces the following tlparse output:

Now, everytime I see this, I think the stack trace is wrong. Why is torch.cos causing a specialization??. Then, I realize that Tensor subclasses are a thing. I wish here it would tell me what the Tensor subclass is (TwoTensor in this case!) or the LOC at the Tensor subclass that does the specialization.

Not sure if this is possible, but this would really help with debugging vLLM (where Tensor subclasses are now abundant).

cc @chauhang @penguinwu @ezyang @bobrenjc93

[zou3519]

So I was able to find a mention of the Tensor subclass in the framework stack trace:

And also the direct line that does the specialization!

so... I guess maybe there's nothing to be done here?

[ezyang]

Perhaps one could quibble with the default view generated here. A good candidate for tlparse vibe coding. But yes, it seems PyTorch is generating the correct data you need.

[zou3519]

I think what I want is it be easier to answer the question "is a tensor subclass involved", when a tensor subclass isn't involved, for the uneducated. It looks like the way to answer that question is to check the framework stack for any torch_dispatch frames. But one does not know to do that unless they understand that the tensor subclass frames will appear iff there is a tensor subclass in use.

[ezyang]

An easy thing to do is add a heuristic for when subclass is involved and render it externally.

[ezyang]

@zou3519 perhaps I can persuade you to try my vibe code tlparse frontends experience :) :) :)