Only support implicit tuples in variable expressions

They cause super inconsistent parsing behaviour if they show up
pretty much anywhere else because there is no difference between an
implicit tuple and a set of comma-separated parameters.

Switch to parameterizing api tests

Properly handle implicit tuples

This adds support for implicit tuple literals and removes support for
identifier tuples for now.

Add proper parsing for {% for %} parameters

Previously a lot of the parsing was done through implicit variable
tuples, but that ended up causing a lot of special cases because we
were only allowing variables in those tuples. Now that we are going
to move towards having tuples be handled consitently, whether they
are identifier tuples or tuple literals, the logic for handling the
`{% for %}` block needed to be cleaned up.

Raise expected syntax errors on bad calls

Properly handle signed variables

Previously we were only handling signed numbers but we were handling
them as constants. Jinja implements a full system for unarary
operators that can be customized, so this switches the grammar and
the parser to use that system instead.

Switch some tests to be parameterized

Right now they are using a for loop which makes it more difficult
to properly trace what iteration failed on. Additionally, it hides
cases where multiple items in the loop fail but not all do.

Require at least one space between line block parameters

Do not require a newline before line statements

As we discovered in the tests, the logic for line statements only
enforces that when they are found, the remaining portion of the line
is treated as a statement declaration. This means that a line statement
can follow things such as text, which the grammar did not previously
allow. The grammar also did not allow a line statement to be the first
line in a file, wich this change also now supports. All non-newline
whitespace preceding the line statement will continue to be stripped.

Implement proper line block closing logic

The documentation implies that line statements are terminated once a
newline statement is found, which would make sense when you think of
what a line block does. The lexer though does not quite implement this
logic, and instead will strip out additional whitespace past the newline
when the line statement is the last non-whitespace in the file.

This has to do with how the current regex is "\s*(\n|$)" which means
"strip any whitespace until a newline or end of file is reached".
Because the regex is greedy, this will strip any whitespace (including
newlines) to the end of the file, or it will only strip whitespace to
the first newline found if the end of the file is not possible. In
order to remain consistent with the old parser, the grammar has been
updated to reflect this behaviour.

Properly split up line blocks from line block pairs

This is necessary for us to do proper pairing of line blocks since
otherwise the rejection would disallow line blocks of any type.

Allow assignment values to be complex expressions

Fix print block

The print block would not actually print the value before because it
was not able to properly parse the variable that needed to be printed.

Add line block pair checking

Similar to how it is done in regular Jinja blocks, line blocks will
now check to make sure that start and end blocks are properly paired
together. When they are not paired together, it will fall back to
parsing them separately like one would expect.

Fix parsing math1 expressions in comparisons

When a math1 expression was used in a comparison before, the right
side would consume the comparison instead of letting it fall back to
the comparison being above it in the AST. This was fixed by restricting
the right side of math1 comparisons to be complex operations only, so
that is any operation that does not involve a comparison, since it's
unlikely that you are looking to do math expressions on the result of
a comparison.

Additionally, this also allows conditional expressions involving basic
operators to consume a complex expression on the left side. Previously
they were restricted to only allowing variables on the left side, so
this allows for more complex comparisons to be made.

Because of the way that conditional expressions with parentheses are
consumed, they have been moved to be the last check within conditional
expressions. This should help to guard against other conditional
expressions which can consume parenthese themselves from being blocked
from parsing because the parentheses have already been consumed.

In order to make things generally easier to understand, the complex
expressions wihch return an actual value (instread of just comparisons)
are now grouped together within the grammar.

Fix parsing of the {% from %} block

There was an issue in the parser before where it was not properly
hanlding variable tuples within the parameters. Additionally, it was
not validating that "import" came after the template name, or that
when it did that any variables were actually specified. Both of those
are now being enforced properly.

Fix grammar parsing for block separators

Previously this allows blocks to be separated by commas and have one
trailing off. Now this only allows blocks to be properly separated
by commas and trailing comms are no longer allowed. This also now
enforces that when parameters are not separated by commas, they are
spearated by at least one space.

Fix "not" expressions consuming variable starting with not

The `not` expression should have a space between the word "not" and
the expression which is being negated. Otherwise it will incorrectly
pick up things like "nothing" as "not thing" because it technically
meets the criteria.

Add support for dot accessors to be numbers

This is an interesting special case in the old parser where numbers
are allowed as dot accessors, but they are specifically convertred
to being an item accessor during the parsing phase. We now support
numbers being parsed for dot accessors in the new parser.

Add support for the filter block

Add support for negative numbers

This also fixes a bug where the exponent was not being properly
captured as well, just the sign of the number

Allow symbols to be overwritten by the environment

This introduces a change to both the grammar and the parsing
environment that allows people to override start/end symbols in the
grammar through the environment. This finally brings the parser on
the same level as the old parser and lexer when it comes to handling
those customizations.

This means that the grammar must be compiled dynamically to account
for these customizations per environment. A module-level LRU cache
has been implemented to handle this fact, so grammars can be cached
instead of compiled every time. This should handle most cases other
than the unit tests, since most people aren't frequently changing up
their environment within their applications.

This also adds proper handling to the closing line block statement
so it waits for the end of a line or the end of the expression.

Support chained comparisons in parser

Add support for complex math expressions with +/-

Support for complex math expressions with other operators will come
eventually.

Fix broken arguments for call blocks

Support for dyanamic args and kwargs in calls

Fix call argument parsing

This temporarily break how `{% call %}` blocks work when arguments
are passed into them because it did not work consistently before. It
only worked for a single argument being passed in because of how
conditional expressions stripped out the parentheses if they were
present. Now they are properly captured but the parser does not yet
put them into the correct location within the Jinja AST.

Add undocumented print block support

Support variables in lists

Fix whitespace handling on blocks

Because of the way it was ordered, it was properly picking up the
non-whitespace stripping block in some cases and failing to parse
as a result.

Handle undocumented whitespace parsing in variables

Parse test variable as conditional expression

This was necessary to fix some of the tests for tests which relied
on parentheses in place.

Fix handling of tests which check constants

Because of how the parser works, it does not differentiate between
constants and function names, so this needs to convert it back.

Fix parsing of the ** operator

Fix blank iterables not parsing correctly

The AST returns `None` instead of an empty array of the value of an
empty iterable literal, so we need to special case when that happens
to get them to parse consistently.

Add support for math expressions to grammar/parser

Tuples must contain a comma

This fixes an issue where parentheses-wrapped variables were being
interpreted by the grammar as tuples. This was because we were lacking
a definiiton for variable wrapped in parentheses and because the grammar
wasn't enforcing multiple values to be present in tuples.

Test function single parameter should a variable

Previusly we were expecting it to be a conditional expression which
allowed it to swallow conditional expressions as if they were a single
variable. This fixes that issue so it only swallows variables.

Fix parsing of filters to allow chained calls

Properly set environment on parsed template

Support filters being call chained

Previously filters were not treated the same as variable, as a
result it was not possible to call the result of a filter. Since
filters are treated as regular variable and therefore can be called
any number of times, this change was necessary to allow them to be
parsed the same way.

Switch testing to use jinja internals

Swap out the old parser with the new one

This will allow us to figure out where the gaps are within the test
suite and also start running a comparison on the timing changes.

Add TatSu as a depdendency

Move semantics object into new_parser

Moved new_parser into jinja package

Remove empty extra files

Add support for test function arguments

Add support for scoped blocks

Add support for tests in `{% for %}`

Add full support for `{% if %}` block

Add support for call block

Add support for parsing `{% else %}` blocks in for loops

Added semantics for pairing blocks together

This required us to modify how the parser works so that once it
detects a pair of blocks, it kicks it back to our specific function
which allows us to detect if the pair of blocks it detected were a
matching pair. This is required in order to allow single blocks to
be included within paired blocks, as otherwise it would always match
the last single block to the end block.

This required changing the grammar so the pair blocks had their own
named expression. This allows us to reject the parse as invalid with
incorrect semantics and allows it to try to just parse the first
block alone.

Add support for `{% include ignore missing %}`

Fix with_context defaulting to false on include block

Add support for import block parsing

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.