This PR was submitted for the 3.x branch but it was merged into the 2.x branch instead.
Discussion
----------
Add `Twig Language Server` and `Modern Twig` extension to docs
Commits
-------
a949600c Add `Twig Language Server` and `Modern Twig` extension to docs
This PR was squashed before being merged into the 2.x branch.
Discussion
----------
Bump PHP version used by Drupal tests
Commits
-------
da38e858 Update Drupal version in tests
64543c3c Fix code
4c4f73ca Bump PHP version used by Drupal tests
This PR was merged into the 3.x branch.
Discussion
----------
Fix callable phpdoc for twig elements
Hi `@fabpot`
I made a stupid mistake in https://github.com/twigphp/Twig/pull/3856
The correct phpdoc is `array{class-string, string}` and not `array<class-string, string>`.
Code is used this way
```
$compiler->raw(sprintf('$this->env->getRuntime(\'%s\')->%s', $callable[0], $callable[1]));
```
which means the key 0 is a class string, and the key 1 is a string.
`array{class-string, string}` is same as `array{0: class-string, 1: string}`
`array<class-string, string>` is saying all the keys are class-string, and values are string.
Commits
-------
1b58589d Fix callable phpdoc
This PR was merged into the 2.x branch.
Discussion
----------
add return type for Symfony 7 compatibility
Commits
-------
fac08ec7 add return type for Symfony 7 compatibility
This PR was squashed before being merged into the 3.x branch.
Discussion
----------
Adding support for the ...spread operator on arrays and hashes
Hi!
Long time user, first time contributor of a real future. I hope I didn't miss anything - but this seemed quite straightforward in the end.
Notes:
* In PHP 7.3 or lower, using the spread operator will result in a Twig syntax error.
* In 8.0 or lower, using the spread operator on a hash will result in a Twig syntax error.
fabbot failures are unrelated, so I'm not touching them.
Cheers!
Commits
-------
ba4fe3ba Adding support for the ...spread operator on arrays and hashes
This PR was merged into the 3.x branch.
Discussion
----------
Fix callable phpdoc for twig elements
Hi `@fabpot`
```
[MyRuntime::class, 'myMethod]
```
is not a valid callable in PHP 8 https://3v4l.org/tWqPs
But this syntax is supported because twig has a special behavior
```
$compiler->raw(sprintf('$this->env->getRuntime(\'%s\')->%s', $callable[0], $callable[1]));
```
The PHPDoc should be updated in order to reflect the real behavior and solve static analysis errors.
A phpstan discussion can be found here: https://github.com/phpstan/phpstan/discussions/9567
Commits
-------
cd68de5e Fix callable phpdoc for twig elements
This PR was merged into the 3.x branch.
Discussion
----------
add extra example to slice filter
Commits
-------
0170dc3c add extra example to slice filter
This PR was merged into the 2.x branch.
Discussion
----------
Mention where named arguments are supported
This follows up on #929. I tend to forget this detail, so it confuses me over and over again.
Commits
-------
ef9d7855 Mention where named arguments are supported
This PR was merged into the 3.x branch.
Discussion
----------
Suppress native return type deprecation msg
> Method "Symfony\Component\DependencyInjection\Extension\ExtensionInterface::load()" might add "void" as a native return type declaration in the future. Do the same in implementation "Twig\Extra\TwigExtraBundle\DependencyInjection\TwigExtraExtension" now to avoid errors or add an explicit ``@return`` annotation to suppress this message.
Commits
-------
72d6f205 suppress native return type deprecation msg
This PR was submitted for the 3.x branch but it was merged into the 2.x branch instead.
Discussion
----------
Making the Lexer initialize itself lazily, to avoid loading the extension set early
Hi!
Over on Symfony UX, we are pushing Twig in some crazy, "unconventional" ways by overriding the lexer to add a new HTML-like syntax - e.g. `<twig:Alert type="success">` - https://github.com/symfony/ux/blob/2.x/src/TwigComponent/src/Twig/ComponentLexer.php
Normally, the internal `Lexer` is not instantiated until it's needed - i.e. when a template is rendered. However, when overriding the lexer, our `ComponentLexer` needs to be instantiated early and set onto the `Environment`. And since it needs to extend `Lexer`, `Lexer::__construct()` is called much earlier than normal. One line in the constructor - https://github.com/twigphp/Twig/blob/f5ee1b6815a28fbab6e6fbb8c48b7964f0d93dd4/src/Lexer.php#L108 - causes the "extension set" to be loaded inside `Environment`. Some applications rely on being able to set extra Twig extensions after `Environment` is created, but before a template is rendered and our custom lexer currently breaks that.
So, the suggestion is to make the work inside `__construct()` done later. Everything is private, so I believe this is safe.
Cheers!
Commits
-------
2f7e8680 Making the Lexer initialize itself lazily, to avoid loading the extension set early
This PR was merged into the 3.x branch.
Discussion
----------
Put example all on one line
Fixes#3833
Commits
-------
9bb05aca Put example all on one line
This PR was merged into the 3.x branch.
Discussion
----------
return annotation to suppress deprecation warning
(finally PRed in the right repo - sorry about that)
> !! 2023-04-14T10:59:02+00:00 [info] User Deprecated: Method "Symfony\Component\HttpKernel\Bundle\Bundle::build()" might add "void" as a native return type declaration in the future. Do the same in child class "Twig\Extra\TwigExtraBundle\TwigExtraBundle" now to avoid errors or add an explicit ``@return`` annotation to suppress this message.
Commits
-------
b7a8ebbe return annotation to suppress deprecation warning
Fabien Potencier
Stanislav Romanov
Christian Flothmann
Vincent Langlet
Nicolas Grekas
Ryan Weaver
Robin Martijn
Matthias Pigulla
Phil E. Taylor
Terence Eden