A list type isn't so useful without a map operation, but List<CommitId>
is at least printable. Maybe we can experiment with it to craft a map
operation.
If a map operation is introduced, this keyword might be replaced with
"parents.map(|commit| commit.commit_id)", where parents is of List<Commit>
type, and the .map() method will probably return List<Template>.
The argument order is different from Mercurial's indent() function. I think
indent(prefix, content) is more readable for lengthy content. However,
indent(content, prefix, ...) might be better if we want to add an optional
firstline_prefix argument.
This eliminates ambiguous parsing between "func()" and "expr ()".
I chose "++" as template concatenation operator in case we want to add
bit-wise negate operator. It's also easier to find/replace than "~".
Now it's ready to split template_parser/templater into base template functions
and "commit" templater. I think Signature and Timestamp are basic types, so
they aren't moved to CommitTemplatePropertyKind. Perhaps, a duration type from
OpTemplate will also be added to CoreTemplatePropertyKind.
The idea is that a derived language will do wrap_<core_type>() as
DerivedProperty::Core(CoreProperty::<Type>(property)). This could be dealt
with some From<CoreProperty> trait impls, but the resulting code looked
a mess, and compile errors would be cryptic. I think this is somewhat similar
to serde::Serializer API.
I also rejected the idea of abstracting property types over Box<dyn>. Maybe
it's okay for method dispatching and extraction of some basic types, but it
wouldn't work if we want to implement comparison operators for any compatible
types.
wrap_commit_or_change_id() and wrap_shortest_id_prefix() will be moved to
the CommitTemplateLanguage. I'll add impl_wrap_fns() macro after splitting
the modules.
The "core" template parser wouldn't know how to dispatch property of types
added by a derived language. For example, CommitOrChangeId/ShortestIdPrefix
will be moved to the "commit" templater.
This trait will provide ways to dispatch keyword/method nodes, and wrap
TemplateProperty object with a dedicated "Property" enum.
build_keyword() and context parameter "I"/"C" have been migrated to it.
Since type/name checking is made after alias substitution, we need to preserve
the original context to generate a readable error message.
We could instead attach a stack of (alias_id, span) to ExpressionNode, but
the extra AliasExpanded node helps to capture downstream error by a single
.map_err() call.
This is basically a copy of revset::RevsetAliasesMap. We could extract a
common table struct, but that wouldn't be worth the effort since the core
alias substitution logic can't be easily abstracted.
This prepares for template aliases support #1190. Unlike revset, template
expressions can be of various types, whereas alias substitution will process
untyped nodes. That's one reason that ExpressionNode is closer to parsed tree
than evaluatable Property structs. Another reason is that it's uneasy to split
name/type checking into "parsing" and "building property function" stages.
We could do alias expansion at once while building Property functions, but
that would make testing harder because Property isn't Debug + PartialEq.
I'm going to split 'parse() -> Expression' functions into 'parse() -> AST'
and 'build(AST) -> Expression'. The duplicated functions will be baseline of
new 'parse() -> AST' functions.
