Carl Meyer f82bb67555 [red-knot] trace file when inferring types (#12401) ... 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.		2024-07-19 07:13:51 -07:00
..
src	[red-knot] trace file when inferring types (#12401)	2024-07-19 07:13:51 -07:00
Cargo.toml	[red-knot] per-definition inference, use-def maps (#12269)	2024-07-16 11:02:30 -07:00