Add support for parsing `{% include %}` tags

This does not yet support the `ignore_missing` flag that can be
passed as a parameter to an `{% include %}` tag

Add support for `{% from with context %}`

Add support for not() expressions in parser

Add support for parentheses grouping in expressions

Add support for negated test expressions

Add support for not() expressions to grammar

This allows for boolean expressions to be negated on the fly

Add support for "not in"/"notin" to grammar/parser

Fix `{% for in %}` loop parsing

This fixes the fact that most `{% for in %}` loops will be parsed
using the `in` operator now, so that operator must be detected and
extracted out in order to make it parse the same way as before. This
is the start of the special cases within the parser for handling
Jinja's previous parsing style.

Support in/notin operator expressions in parser

Support "in" operator in grammar

This changes the previous comparison operations from being marked
as solely comparion expressions and expands them out to be generation
operator expressions. This allows us to easily support the "in"
operator, which in the current Jinja parser is handled exactly the
same as the other operations, but it does require us to special case
the automated conversion of the "not ... in" expression to a "notin"
expression.

Add concat expression support to grammar and parser

This is probably going to be reclassified in the grammar and parser
as something different from the conditional expressions once more
support for math operators is added in.

Simplify variable values in grammars

Now that variable identifers are able to be used as conditional
expressions, we can just specify that variable expressions in the
grammar are looking for a conditional expression as the name of the
variable.

Add support for the extends block

Support if/else expressions in parser

Allow variable identifiers to be conditionals

This aligns with the Python behaviour and pre-existing Jinja behaviour
where a variable expression can be used as a test for a conditional.
This was necessary to allow variable identifiers to be used in places
which was expecting a possible conditional expression, like in a if/else
expression.

Restrict where conditional expressions are allowed

Previously conditional expressions were only allowed in things which
accepted parameters to call accessors, which is most things, but this
was found to be too broad. Many contexts to not actually allow conditional
expressions so this was restricted back to block parameters and variable
calls.

Add support for if/else expressions in grammar

These fall under a special type of conditional expression and can
only be used in certain places. The grammar for test functions
needed to be updated to rejected test function parameters if they
are only called "else", since that is likely to be for an if/else
expression. This matches the existing behaviour of the Jinja parser.

Add support for "None" and "none" to grammar/parser

Add support for parsing dictionary literals

Add support dictionary literals to grammar

This also allows dictionary values to be variables instead of just
regular identifiers, a change which might be made to other literals
such as lists and tuples in the future as we determine what those
also support.

Support single-parameter tests without parentheses

This adds support for the optional parantheses in tests that are only
being supplied a single parameter. Tests which use parantheses are
currently not supported in the parser, but are supported in the grammar.

Remove unused variable_tests from grammar

Support the autoescape block

Add parsing of conditional expressions

Fix AST for conditional expressions

Previously all conditional expressions were left associative which
produced an AST that was nothing like the one in Jinja and one which
did not respect order of operations within conditions. The conditional
expression part of the grammar has been rewritten to be more explicit
about what can and cannot match which appears to have fixed those
issues with the AST.

Fix macros not marking args as params

It was only marking keyword arguments as params which is not totally
correct.

Fix block set params being marked for load

Fix macro params being marked to load

These are being used as variables within the macro itself so these
should be marked as parameters so they do not escape the scope of the
block.

Fixed elif/else sections of if node being None

The default should be an empty list to match the existing AST but
we were incorrectly setting it to `None`.

Combine common template data/outputs in AST

This makes it easier to compare the AST generated by the old Jinja
parser and the AST generated by the new one, since the new AST
separates out template data character by character currently.

Filter out `None` from parsed blocks

This allows for comments to not appear in the generated AST.

Allow variable identifiers to be aliased in block params

This is only really supported on the `{% from %}` block currently,
but the ability exists to use this elsewhere if someone is looking
for the ability to alias variable identifiers. This also allows
value-only parameters to be comma-separated within the block
parameters, since before that was only allows for key-value parameters.

Mark with targets as parameters

This fixes a bug where the targets of a `{% with %}` block would not
be marked as a parameter. This is because they were not being marked
at all as a variable which results in an invalid AST. For reference
counting purposes, this must also be marked specifically as a parameter
variable instead of as a stored variable to ensure it does not leak
out of the block.

Properly mark set target as variable

Previously it wasn't being marked as a variable at all if it was just
a string literal, so this fixes it so Jinja knows that the assignment
should be stored on the target variable.

Switch From node to use constructor

This ensures that `with_context` is properly initialized even though
we don't currently support it.

Allow optional comma after block keyword parameters

It looks like this is only currently support within `{% with %}`
blocks in Jinja, instead of space-separating the parameters, but
this may also be happening in extensions as well.

Parse macro blocks

Support assignment blocks using `{% set %}`

This adds support for the usage of `{% set %}` where the contents of
the block are assigned to the variable instead of handling that within
the block parameters.

Because Jinja separates the filter from the variable within the
`AssignBlock` node, we have to detect when there is a wrapping filter
and extract it so that it can slot in properly.

Parse isolated set blocks

This adds support for set blocks where a key-value pair is being
sent in so there is no matching pair of statement.

Parse arguments to calls

This can be combined with the logic for parsing arguments to filters
then they both generate the same AST.

Initial support for if blocks

This currently only supports tests which are a simple condition and
do not span multiple sides of a comparison.

Add parsing of boolean literals

This should finish off all of the parsing of currently supported
literals.

Support parsing `{% block %}` blocks

This does not currently parse out the scoped parameter but that will
come soon enough.

Properly support recursive in for loops

This adds an example to the test file that is being used to verify
that the generated ASTs are comparable.

Add initial parsing of for blocks

This will correctly parse out most of the starting block as well as
the contents, but it does not yet handle the parsing of the `{% else %}`
block that can be contained within the contents of the block.

Parse variable tuples

Right now these are custom parsed since they are not the same as
tuple literals and generally serve a different purpose. They are
tuples which contain variable identifiers and are generally used
for assignment.

Add initial support for call accessors

This only currently supports call accessors that do not take any
parameters. For now it is hard-coded to have no parameters.

Add list and tuple literal parsing

Enable line parsing in Jinja environment

Right now the grammar is being tested with line parsing enabled so
this makes them match

Parse raw blocks and comments

Comments get ignored by the parser and raw blocks just get output
directly as a string into the AST.

Add parsing for numeric literals

Add filter parsing for variables

Filters and their arguments are now properly parsed into the right
Jinja nodes. Dynamic arguments (`*args`) and dynamic keyword arguments
(`**kwargs`) are not currently parsed as they are not supported by
the grammar.

Dot accessors can only be identifiers

This fixes a bug where the grammar allowed dot accessors to be any
variable type. This results in the filters that were meant for the
variable that was being accessed to be captured by the accessor
itself, which generated an unexpected and invalid AST.

Output nodes are always lists

Right now we don't optimize Output nodes so that ones next to each
other are combined, but they should all contain a list of a single
node in preparation for eventually doing that.

Parse the contents of the body of with block

This logic will inevitable be generalized out in the future for
other full blocks, but for now it properly handled parsing the
contents of the block and converting it to the Jinja AST.

Properly parse with targets

The targets of with expressions (the variables to load) should be
properly parsed as a variable using the same load logic which is
used in other areas of the parser.

Start working on new AST parser

This parser will take the Tatsu-generated AST and generate a compatible
Jinja AST from it. This should allow us to refine the grammar to
generate a better AST and also verify that it is producing comparable
Jinja ASTs that can be used by the current compiler.

Support filters on all variables

This adds support to filters on all variables instead of to just
variables which are being printed within templates. This now allows
us to pass in variables that are using filters as parameters within
a block, so they can be used for setting new variables or to perform
transformations on the fly.

Rename grammar to grammar.ebnf

This will enable syntax higlighting on GitHub and also makes it more
clear what format is being used within the file.

Case insensistive exponent parsing

Variable filters should not capture whitespace

This should have no functional difference on the behaviour of the
parser but it does make filters consistent with other areas where
it expects to start with the first character instead of starting
with whitespace.

This also changes the test script to time the individual steps so
we can confirm that the grammar compilation is considerably slower
than the parsing of the template using the grammar.

Enable leading whitespace stripping for blocks

Enable whitespace control within closing blocks

This enables the ability to force whitespace to be stripped following
the end of a block statement by adding a `-` before the closing
tag. This is supported both for stripped the space at the beginning
of a block as well as stripping the space that follows a block.

Name contents of raw blocks

This will also strip the open/close blocks from the AST which cleans
up the final part of it.

Name parts of a block

Remove whitespace parsing from inside block

This fixes an issue where trailing whitespace within blocks was being
processed as an expression instead of being collected into the block
definition. Now the whitespace is consisitently stored within the
block expression which should make whitespace handling easier to
implement.

Add support for optional ":" at end of line statement

This does not fully work for the example file because the grammar
for a test expression can span multiple lines which causes the HTML
in the line following the block expression to be detected as a test
expression instead of being detected as content.

Fix parameters eating whitespace

This was causing issues for anything that depends on significant
whitespace to follow a parameter, since it wasn't being made
available within the grammar.

Support independent line statement

This allows you to have a line statement that is not paired with an
ending one.

Strip spaces before line statements and prefixes

Add suport for line comments

This also switches comments to produce the same AST whether it is
an inline comment or a line comment.

Consistent formatting of OR within grammar

Add support for line statements

These are block expresions but the start/end tags take up an entire
line and are marked by a leading symbol.

Ensure macro definitions are properly parsed

Test specific imports are supported

Converted more of parse tree to dictionary

This should make it easier to detect what type of literal has been
parsed (we don't differentiate between single and double quoted
strings) as well as determining the specific accessors that are
called on a given variable.

Tuple and list literals have also been normalized to hold their
values in a key called `value` which is the same as other literals.
Implicit identifier tuples have not been switched yet because those
are not currently parses like tuple literals.

Support implicit tuples in block parameters

This fixes an issue where implicit tuples were not parsed correctly
when they were used as a key in a block parameter. Now for loops
and set statements with implicit tuples work properly. This only
supports implicit tuples when all values are identifiers, since
these are generally used for assignment and you cannot assign a
new value to a literal.

Add support for tests

Right now these are very basic and don't appear to form the correct
parse tree for logical comparisons which use tests as well. But it
parses at lease somewaht correctly, so there is something to work
with here.

Support assignment expressions in generic blocks

Because of the way assignment expressions handle implicit tuples,
it's now possible to support the complex for loops within the
standard generic block grammar.

Added grammar for `for` loops

Since this needs to support assignment targets, it is difficult to
properly support this within a generic block syntax because of the
ability to create implicit tuples.

Added tuple literal support

This maintains the expectation that tuple literals will always end
with a comma if there is a single item.

The example is the combined one from the Jinja docs but it does not
include the comma for the tuple assignment since the grammar does
not currently support that.

Support list literals

Support boolean literals

This will transparently convert them into an actual boolean which
should skip any variable-like parsing that would otherwise be done.

Add integer and float literals

These align with the one already supported by Jinja.

Switch blocks and variables to dictionaries

This should make it easier to differentiate them based on their
type but also allow for the different pieces to have proper names.

Switch to named dict for filters

This will make it easier to determine what filters need to be
called like a function with parameters and which ones assume
default parameters.

Support key-value block parameters

Block parameters should support all of the things that a function
call parameter would normally support. This includes key-value
paramters and in our test we include the transaltion example from
the documentation.

Support named parameters to calls

This also switches the parameters in calls to be returned as a
dictionary which should make it easier to differentiate between a
value-only parameter and a key-value parameter.

Variable calls support multiple parameters

This also updates filter parameters to be handled the same as calling
a variable.

Filter parameters are variable identifiers

The filter parameters list is actually the same as a variable
accessor for a call but that does not currently support multiple
parameters.

Add function calls for variables

This allows for functions to be called, currently with a single
variable optionally passed.

This also adds a check to make sure that variable literals are
supported.

Parse block parameter values like variables

This allows for complex values to be used in parameters while also
supporting standard literals.

Support dot accessors on variables

This adds support for dot accessors on variables in such a way that
it is flexible enough to match the handling provided by the existing
template engine.

Start definining variable identifiers

Variables are standard identifiers or literals that can be
augmented by accessors (either dictionary or dot style). This
finally defines what a string is.

Strip parens from filter params list

This isn't necessary, we will always know that the second item within
the filter list is the set of filter parameters.

This also ensures that any time the filter separator is detected,
we force parsing the next token as a filter parameter.

Use variable names in content definition

This should make it easier later to override these variables without
needing to make additional changes.

Fix content overtaking expressions

This fixes a issue where content would try to overtake everything
following it, even if there was a better expression to match after
the content. This was fixed by telling content to match everything
but the start of different expressions, which appears to solve a
bunch of issues.

Initial commit

Merge pull request #1196 from pallets/remove-vim

remove vim syntax file

remove vim syntax file

remove unmaintained information from integration doc