templater: don't define TemplateLanguage::Context statically #3332
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
martinvonz
approved these changes
Mar 21, 2024
4 tasks
…nguage These .wrap_<type>() functions aren't supposed to capture resources from the language instance. It was convenient that wrap_() could be called without fully spelling the language type, but doing that would introduce lifetime issue in later patches. I added type alias L to several places because the language type is usually called L in generic code.
Because GenericTemplateLanguage doesn't support any global resources, it no longer makes sense to pass the language instance around to 0-ary keyword functions.
This prepares for removal of TemplateLanguage::Context type. "C: Clone" trait bounds looked messy, but they can be removed soon.
…alue of C The idea is basically the same as list.map(|x| ...) template. It compiles the inner template with a placeholder variable of type 'C', and evaluate it for each instance variable by injecting the variable through RefCell.
In short, this enables compilation of template of e.g. Vec<Commit> type by using CommitTemplateLanguage. A Template<C> was originally compiled for a specific type C, and invoked as "Fn(&C) -> _". It was simple and intuitive, but we had to define the context type C statically. Things got even worse by extensions support because we had to provide object-safe hook point for each context type C. This patch basically removes the Context type from compiled templates. The "self" variable is injected through RefCell<Option<C>> placeholder. A compiled template knows its "self" type, but the type can be decided per instance, not per TemplateLanguage type. A drawback is that the "self" variable will have to be cloned one more time. The Template<C> abstraction no longer makes sense, and will be split to inner Template<()> implementations (which usually represent printable types) and the outer Template<C>.
Now a compiled template doesn't have a static Context type internally. A property is basically of "Fn() -> Result<O, _>" type, and a type-erased "self" variable will be injected as needed. Template<C> types will be refactored separately.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Checklist
If applicable:
CHANGELOG.md