Skip to content

[red-knot] trace file when inferring types#12401

Merged
carljm merged 1 commit intomainfrom
cjm/better-tracing
Jul 19, 2024
Merged

[red-knot] trace file when inferring types#12401
carljm merged 1 commit intomainfrom
cjm/better-tracing

Conversation

@carljm
Copy link
Copy Markdown
Contributor

@carljm carljm commented Jul 19, 2024

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.

@carljm carljm added the ty Multi-file analysis & type inference label Jul 19, 2024
@github-actions
Copy link
Copy Markdown
Contributor

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

@MichaReiser
Copy link
Copy Markdown
Member

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.

@carljm carljm merged commit f82bb67 into main Jul 19, 2024
@carljm carljm deleted the cjm/better-tracing branch July 19, 2024 14:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ty Multi-file analysis & type inference

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants