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

Remove syn and proc-macro2 and quote dependencies from askama_derive #953

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

GuillaumeGomez
Copy link
Collaborator

So overall, I think it'll be much more efficient to parse the derive proc-macro (not sure exactly how to test it...) as this code doesn't try to make sense of most tokens it parses.

However, and I think it's quite important to note: it has a maintenance cost (as does any code) and if you don't think it's worth it, we can close it. The proc-macro performance isn't that critical and the three dependencies are still in the dependency tree since askama uses serde.

Even if not merged, some improvements in the code can still be retrieved from this code, mostly around how the code is generated. I think that splitting code generation into a lot of small calls to writeln makes it much more difficult to have an idea of what the generated code will look like.

Anyway, it was fun to do. Parsing rustc tokens is pretty easy so I did it originally to see how hard it would be to not use syn and all the crates (which are great, but because they need to support a lot of cases, are bound to be slower than hand-made code, specific to one use case).

@GuillaumeGomez
Copy link
Collaborator Author

And fixed mendes (forgot to generate with the where clause).

@djc
Copy link
Owner

djc commented Jan 22, 2024

So what is/was the motivation for this? What are you hoping to get out of it? It's a little hard to get excited about a +780/-230 diff.

@GuillaumeGomez
Copy link
Collaborator Author

Performance mostly. Do you have a way to measure it for askama_derive?

@djc
Copy link
Owner

djc commented Jan 22, 2024

I don't think we have a great way to do that, no. I think informally we've used something like roughly checking the compile time for the testing crate in this repo?

Performance is a good goal, though -- if you can show that this moves the needle there, I'd be interested!

@Kijewski
Copy link
Collaborator

Kijewski commented Feb 1, 2024

I think that splitting code generation into a lot of small calls to writeln makes it much more difficult to have an idea of what the generated code will look like.

Currently every line is written in its own statement, because the code is generated with (more or less) correct indentation. I don't know if this feature is actually needed, because "cargo expand" reformats the resulting code anyway. Using multiline strings is more readable, if we can live without our manual indenting.

@@ -0,0 +1,158 @@
// This code is a simplified version of the `rustc_lexer` unescape.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Hm, sorry, but I quite dislike this file. It kinda gives me paranoia that we miss some obscure corner case, which could lead to the rise of Skynet. :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Don't believe in me, believe in the rust compiler people who wrote it. 😆

Copy link
Owner

Choose a reason for hiding this comment

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

Yeah, but then by copying this we no longer benefit from their continued maintenance.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Code hasn't changed in a long time, so we should be fine on that end. But yes, would be much better if we could get the "string value" of a raw string directly from proc-macro crate instead of having to handle it ourselves...

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.

None yet

3 participants