Closed Kijewski closed 2 months ago
If this change, if a template file is updated, will it trigger a new compilation (as it should)?
Have you benchmarked the performance impact on parsing?
If the goal is to have nodes from different sources in the same AST, it's not obvious to me that this is the best way to get there. At least in theory we can just keep String
s for each source on the stack and keep an AST containing references to any of these sources with the same lifetime, right?
Have you benchmarked the performance impact on parsing?
I didn't, but I daresay the change is not for free. Rc::clone has a check to guard against integer overflows like loop { forget(rc.clone()); }
which adds stack unwinding code.
At least in theory we can just keep
String
s for each source on the stack and keep an AST containing references to any of these sources with the same lifetime, right?
Sounds like a good idea! Simply have a Vec<String>
of sources. When merging two ASTs, we simply move the sources.
This enables having nodes in the same AST that were produced from multiple source files.
Essentially:
%s/&str/RcStr/g
This is a draft. For now, I removed all the parser tests, but will re-add them later.
👍🏻 What I like about this PR: The lifetimes are gone, which makes the code much easier on the eyes.
👎🏻 What I dislike about this PR: The lifetimes are gone, so I have to touch every other line of the source code to remove any
'a
.Do you think the PR is worth investing more time into? I hate that I had to change so many lines; this makes the change extremely un-reviewable and makes it difficult to
git blame
in the future.The change is part of #1034. I want to do the inclusions directly in the parsing step, not only when generating code. Just as if you replaced
{% include "foo.html" %}
with the content offoo.html
in the template file.