Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace DUMMY_SPAN with Span::Panic and Span::Rust #498

Merged
merged 4 commits into from
Dec 26, 2024

Conversation

Alex-Fischman
Copy link
Collaborator

This PR improves error messages by introducing two new types of spans. The first is Span::Rust, which stores a location in a Rust file using the file! macro family. The second is Span::Panic, which can be used when you know that the span should not be introspected; for an example, see the changes in serialize.rs.

@Alex-Fischman Alex-Fischman requested review from saulshanabrook and oflatt and removed request for saulshanabrook and oflatt December 17, 2024 22:17
Copy link

codspeed-hq bot commented Dec 17, 2024

CodSpeed Performance Report

Merging #498 will not alter performance

Comparing Alex-Fischman:span-macro (64a3a2e) with main (cb44ce9)

Summary

✅ 9 untouched benchmarks

@saulshanabrook
Copy link
Member

For Python code I have been using a dummy span for all nodes. The thought would be eventually I could add tracebacks to the Python source lines but I haven't done that yet.

For now, I guess I could just make up a dummy rust span that doesn't exist? Like it won't crash if the line/file aren't real right?

@Alex-Fischman
Copy link
Collaborator Author

Alex-Fischman commented Dec 17, 2024

Oh, I wasn't thinking about Python. Yeah, Span::Rust shouldn't try to read the file or anything. Can you think of a better name for it? It would be great for the Python bindings to support line numbers as well, and you should be able to reuse the file/line/column variant to do it.

@Alex-Fischman
Copy link
Collaborator Author

I think the performance regression is coming from spans getting larger from 3 words to 4, since the compiler can't distinguish between Egglog and Rust without an extra word for the tag. This would explain the slowdown because to_core_actions does a lot of span.clone().

The only potential fix I can think to try would be to wrap spans in an Rc/Arc. If that doesn't make things faster then I'm not sure how to improve it.

@Alex-Fischman
Copy link
Collaborator Author

Okay, that seems to have improved things. Opening for review.

@Alex-Fischman Alex-Fischman marked this pull request as ready for review December 18, 2024 00:16
@Alex-Fischman Alex-Fischman requested a review from a team as a code owner December 18, 2024 00:16
@Alex-Fischman Alex-Fischman requested review from FTRobbin, saulshanabrook, oflatt and yihozhang and removed request for a team and FTRobbin December 18, 2024 00:16
@saulshanabrook
Copy link
Member

saulshanabrook commented Dec 24, 2024

Yeah, Span::Rust shouldn't try to read the file or anything. Can you think of a better name for it?

What about just File? Or SourceFile?

--+

I'm not sure also. I wouldn't worry about it now actually and can just leave it as rust and I can set it to a dummy file for now.

We could revisit this once I add proper source tracking into egglog Python, to carry that info forward and add the proper spans.

@RiscInside
Copy link
Contributor

RiscInside commented Dec 25, 2024

If this gets merged, it would be cool to have var!, call! and primitive! macro replacements for deleted *_no_span functions (implemented by calling Expr constructors with span!()).

@Alex-Fischman
Copy link
Collaborator Author

@RiscInside Done, assuming that by primitive! you meant lit!?

@RiscInside
Copy link
Contributor

Great, thank you!

assuming that by primitive! you meant lit!?

Indeed, my bad.

@@ -321,7 +317,7 @@ impl EGraph {
.extract_term(self, *value, &extractor, &mut termdag)
.expect("Extraction should be successful since extractor has been fully initialized");

termdag.term_to_expr(&term).to_string()
termdag.term_to_expr(&term, Span::Panic).to_string()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not use the span!() macro here? Just trying to understand when you want panic vs that one.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The to_string method ignores spans, so using Span::Panic is just a runtime check that the spans are in fact ignored.

In general, I think Span::Panic is useful when you know that the spans are not observable by outside code; i.e. I would avoid it if the function returned an Expr.

Copy link
Member

@saulshanabrook saulshanabrook left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems good, better than what we have now, thank you @Alex-Fischman!

@Alex-Fischman Alex-Fischman merged commit bdb9cda into egraphs-good:main Dec 26, 2024
5 checks passed
@Alex-Fischman Alex-Fischman deleted the span-macro branch December 26, 2024 21:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants