[red-knot] trace file when inferring types

[carljm]

When poring over traces, the ones that just include a definition or symbol or expression ID aren't very useful, because you don't know which file it comes from. This adds that information to the trace.

I guess the downside here is that if calling .file(db) on a scope/definition/expression would execute other traced code, it would be marked as outside the span? I don't think that's a concern, because I don't think a simple field access on a tracked struct should ever execute our code. If I'm wrong and this is a problem, it seems like the tracing crate has this feature where you can record a field as tracing::field::Empty and then fill in its value later with span.record(...), but when I tried this it wasn't working for me, not sure why.

I think there's a lot more we can do to make our tracing output more useful for debugging (e.g. record an event whenever a definition/symbol/expression/use id is created with the details of that definition/symbol/expression/use), this is just dipping my toes in the water.

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[MichaReiser]

I think there's a lot more we can do to make our tracing output more useful for debugging (e.g. record an event whenever a definition/symbol/expression/use id is created with the details of that definition/symbol/expression/use), this is just dipping my toes in the water.

Possibly, but I think it would make the trace output so verbose that it is no longer useful when working on other parts of the code.