Base update to PHP 8.2

[SenseException]

This PR is for the plain update to PHP 8.2 with its composer dependencies. Refactorings and rewrites aren't included in this step.

[SenseException]

The update is pretty much close to the end, but generating the docs end in multiple errors based on the outdated rst format of the doc-files, especially

• the tables in dbal (Cannot find column for index "0")
• doctrine-data-fixtures (Failed building file "source/projects/doctrine-data-fixtures/en/1.6/how-to/sharing-objects-between-fixtures.html" with error "Unexpected token "name" of value "if" ("end of statement block" expected))

I don't know how the docs will look like either until I manage a docs-build without exceptions.

[greg0ire]

doctrine-data-fixtures (Failed building file "source/projects/doctrine-data-fixtures/en/1.6/how-to/sharing-objects-between-fixtures.html" with error "Unexpected token "name" of value "if" ("end of statement block" expected))

Might be because of the linebreak right in the middle of a link? There's only one occurrence of if in this document

[greg0ire]

Cc @linawolf in case you think this might be a bug in the parser, or in case linebreaks in the middle of a link are invalid.

[SenseException]

When I remove doctrine/data-fixtures from the build then the next project is affected by the same error. In my casesource/projects/doctrine-orm-module/en/5.0/index.html.

[greg0ire]

🤔 no occurrence of if in that one

[linawolf]

There needs to be a new line after .. code-block:: php otherwise the codeblock is invalid

[greg0ire]

I created doctrine/data-fixtures#428 to address this on the data-fixtures repo.

[SenseException]

Failed building file "source/projects/doctrine-data-fixtures/en/1.6/how-to/sharing-objects-between-fixtures.html" with error "Unexpected token "name" of value "if" ("end of statement block" expected)

I'm not sure if this error is connected to the rst-parser. The html file already exists and contains html+twig code, so the rst got parsed.

sharing-objects-between-fixtures.txt

[greg0ire]

Should you maybe add -vvv somewhere to get a full stack trace?
Here?

doctrine-website/.github/workflows/deployment.yml

Line 65 in a13875d

run: "bin/console --env=${{ inputs.environment }} build-all"

[SenseException]

The workflow breaks earlier because of the dbal table I mentioned in a comment earlier, but I already got myself a stack-trace on my local machine. I'd expect a Twig error, but I haven't pinned it down to the actual cause.

This file contains the complete output of one of my test runs. (I skipped the Exceptions of the dbal tables)
build.txt

[greg0ire]

Looking at that stack trace, I think it might be about this line:

doctrine-website/templates/layouts/documentation.html.twig

Line 119 in a13875d

{% for version in project.maintainedVersions if version.hasDocs %}

Of maybe this one:

doctrine-website/templates/layouts/documentation.html.twig

Line 139 in a13875d

{% for version in project.unmaintainedVersions if version.hasDocs %}

[greg0ire]

Ah yes it checks out: https://github.com/twigphp/Twig/blob/78c18ad58e48d3fff2f7812bb60b6176ee52689a/CHANGELOG#L156

[greg0ire]

The failure seems to relate to doctrine/dbal#5197

[greg0ire]

But if we had to reuse this commit on lower branches, well there are a lot of branches to backport it to: https://github.com/doctrine/dbal/blob/3.6.x/.doctrine-project.json

I don't understand why this wasn't an issue sooner 🤔

UPDATE: ah that's probably the update of the RST Parser

[SenseException]

Yes, it's the newer versions of the rst-parser. It's breaking the website build in the latest 0.5 release and the 0.6 branch. I've created an issue that described the behavior of one of the errors a long time ago, but I don't find it anymore and I'm not sure yet if it's the same issue again. Once my workstation is ready to use, I can resume my work.

[SenseException]

When it comes to the build of the docs with the rst-parser, the build-breaking exception happens on dbal only:

Cannot find column for index "0"
#0 doctrine-website/vendor/doctrine/rst-parser/lib/Nodes/TableNode.php(188): Doctrine\RST\Nodes\TableNode->compilePrettyTable()
#1 doctrine-website/vendor/doctrine/rst-parser/lib/Nodes/TableNode.php(146): Doctrine\RST\Nodes\TableNode->compile()
#2 doctrine-website/vendor/doctrine/rst-parser/lib/Parser/DocumentParser.php(587): Doctrine\RST\Nodes\TableNode->finalize()
#3 doctrine-website/vendor/doctrine/rst-parser/lib/Parser/DocumentParser.php(378): Doctrine\RST\Parser\DocumentParser->flush()
#4 doctrine-website/vendor/doctrine/rst-parser/lib/Parser/DocumentParser.php(216): Doctrine\RST\Parser\DocumentParser->parseLine()
#5 doctrine-website/vendor/doctrine/rst-parser/lib/Parser/DocumentParser.php(153): Doctrine\RST\Parser\DocumentParser->parseLines()
#6 doctrine-website/vendor/doctrine/rst-parser/lib/Parser.php(179): Doctrine\RST\Parser\DocumentParser->parse()
#7 doctrine-website/vendor/doctrine/rst-parser/lib/Parser.php(163): Doctrine\RST\Parser->parseLocal()
#8 doctrine-website/vendor/doctrine/rst-parser/lib/Parser.php(205): Doctrine\RST\Parser->parse()
#9 doctrine-website/vendor/doctrine/rst-parser/lib/Builder/ParseQueueProcessor.php(81): Doctrine\RST\Parser->parseFile()
#10 doctrine-website/vendor/doctrine/rst-parser/lib/Builder/ParseQueueProcessor.php(65): Doctrine\RST\Builder\ParseQueueProcessor->processFile()
#11 doctrine-website/vendor/doctrine/rst-parser/lib/Builder.php(214): Doctrine\RST\Builder\ParseQueueProcessor->process()
#12 doctrine-website/vendor/doctrine/rst-parser/lib/Builder.php(151): Doctrine\RST\Builder->parse()
#13 doctrine-website/lib/Docs/RST/RSTBuilder.php(57): Doctrine\RST\Builder->build()
#14 doctrine-website/lib/Docs/RST/RSTBuilder.php(36): Doctrine\Website\Docs\RST\RSTBuilder->buildRst()
#15 doctrine-website/lib/Docs/BuildDocs.php(92): Doctrine\Website\Docs\RST\RSTBuilder->buildRSTDocs()
#16 doctrine-website/lib/Commands/BuildDocsCommand.php(62): Doctrine\Website\Docs\BuildDocs->build()
#17 doctrine-website/vendor/symfony/console/Command/Command.php(326): Doctrine\Website\Commands\BuildDocsCommand->execute()
#18 doctrine-website/lib/Commands/BuildAllCommand.php(101): Symfony\Component\Console\Command\Command->run()
#19 doctrine-website/lib/Commands/BuildAllCommand.php(85): Doctrine\Website\Commands\BuildAllCommand->runCommand()
#20 doctrine-website/vendor/symfony/console/Command/Command.php(326): Doctrine\Website\Commands\BuildAllCommand->execute()
#21 doctrine-website/vendor/symfony/console/Application.php(1063): Symfony\Component\Console\Command\Command->run()
#22 doctrine-website/vendor/symfony/console/Application.php(320): Symfony\Component\Console\Application->doRunCommand()
#23 doctrine-website/vendor/symfony/console/Application.php(174): Symfony\Component\Console\Application->doRun()
#24 doctrine-website/lib/Application.php(121): Symfony\Component\Console\Application->run()
#25 doctrine-website/bin/console(21): Doctrine\Website\Application->run()

There's also an exception on ORM, but I haven't confirmed yet if this has something to do with rst tables.

[SenseException]

Looks like ORM and DBAL are the only ones that cause the build to break now. If I skip/ignore these, then the build runs to the end and I can see the website with its docs (minus the versions that cause the problems)

ORM

https://github.com/doctrine/rst-parser/blob/0.5.x/lib/Parser/LineDataParser.php#L177-L179

These lines are the ones that are involved in the ORM build failure "Warning: Undefined array key 0". definitionNodes is an empty array at this point starting with 2.12.x (and probably lower). Considering the content that was parsed at the time I assume that strategy-cookbook-introduction.rst was parsed at the point of where the build breaks. I can't tell yet if the empty array could be correct, because the only difference is, that the paragraph that starts with "As you can see, we have a method setBlockEntity which" is bold.

DBAL

The newer versions work fine. 3.3 is the last version that gets its docs generated, but 3.2 is the first in line that causes the build to break. The trace of the exception in my previous comment reduces the source of this error to the types-table. A diff between 3.3 and 3.2 shows an indent of the table and reference fixes as the only changes.

[greg0ire]

As you can see, we have a method setBlockEntity which

With 2.12.x, that sentence is preceded with a seemingly empty line. Seemingly, because it in fact has trailing whitespace (3 spaces). It would be interesting to push a commit removing that trailing whitespace to 2.12.x and see what happens.

[SenseException]

I came to the same conclusion, because $definitionListTerm['definition'] contains a \n . Maybe that behavior can be reproduced in a rst-parser test.

[greg0ire]

Yes and I think the fix will be to change line 312 of DocumentParser.php to if (trim($this->lines->getNextLine()) !== '' && $this->lineChecker->isIndented($this->lines->getNextLine())) {

EDIT: or maybe not. I cannot reproduce the bug, and the change above breaks the test suite 😞

[greg0ire]

Ah hang on, if I copy paste the file literally, I do reproduce the issue. I'll try reducing it to what's strictly necessary.

[greg0ire]

The magical formula is:

• line with whitespace
• single line
• line with whitespace
• line of random content

See doctrine/rst-parser#271

[greg0ire]

Oh and my fix works. I must have copy/pasted it wrong last attempt.

[SenseException]

Before converting this draft to a PR, and therefore before merging this, We have to test the website on staging. I did a deployment yesterday, but for yet unknown reasons, some versions are missing in the dbal docs. There are probably other projects affected too. This needs to be checked if this issue is connected to the updates of this branch.

[SenseException]

Let's do this 💪

[greg0ire]

Thanks and congrats @SenseException !!!

[derrabus]

Great work!