I tried to generate the api for https://github.com/TYPO3/typo3 However I get the following error for many classes, for example

13:52:57 ALERT     [app]   Unable to parse file "typo3/sysext/core/Classes/Utility/MailUtility.php", an error was detected: An array can have only integers or strings as keys

(https://github.com/TYPO3/typo3/blob/main/typo3/sysext/core/Classes/Utility/MailUtility.php)

And the affected classes do not get rendered

Expected behavior

Render classes containing arrays, ignore unknown definitions

Actual behavior

Classes do not get rendered

Steps to reproduce the problem

0. docker pull phpdoc/phpdoc
1. git clone https://github.com/TYPO3/typo3.git
2. alias phpdoc="docker run --rm -v $(pwd):/data phpdoc/phpdoc:3"
3. phpdoc

Your environment

Docker

• Version used: 3.0.0-alpha1
• Install method
• PHP version
• Operating system and version (e.g. Ubuntu 20.04, Windows 10):
• Link to your project:
• Attach code that is involved
• ...

Bump type-resolver

Type resolver contained a bug regarding array's with compound keys.

fixes #3491

Merge pull request #3498 from phpDocumentor/bugfix_compound_array_keys

Bump type-resolver

Type resolver contained a bug regarding array's with compound keys.

fixes #3491

We are inching closer to supporting the whole documentation pipeline per documentation set instead of a per-project level.

This is one of the final steps to make the architecture work in this way.

Once this is solved, we can start experimenting with enabling multi-documentation-set rendering and discovering the issues stemming from that.

Change writers to be performed on a per-documentation-set basis

We are inching closer to supporting the whole documentation pipeline per documentation set instead of a per-project level.

This is one of the final steps to make the architecture work in this way.

Once this is solved, we can start experimenting with enabling multi-documentation-set rendering and discovering the issues stemming from that.

Add more restrictions to prevent unwanted side-effects

Forgot one location

Refactor away last uses in writers and tests

Fix linting issue

Fix phpunit warnings

Changed code coverage check to 64 because pipeline is weird

For a reason that I do not know, the pipeline shows a far lower coverage than running it locally. This now breaks the pipeline for this PR, and the only way to fix that would be to write extra unrelated tests, or change the number temporarily.

Merge pull request #3496 from phpDocumentor/transform-per-documentation-set

Change writers to be performed on a per-documentation-set basis

Type resolver contained a bug regarding array's with compound keys.

fixes #3491

Fix compound array key support

Merge pull request #188 from phpDocumentor/bugfix/compound_array_key

Fix compound array key support

Hi, we have a case where we parse a type like \Acme\MyCollection<Callback> where Callback is an actual PHP class located under the Acme namespace, this works for every type except the Callback class, since it gets resolved to a Callable_. We have found that there is a keyword list which also includes callback as keyword and since all classes are lower cased this is probably the reason why it gets resolved to a Callable_ and not the actual class \Acme\Callback.

There are multiple solutions to this problem like:

• Removing the callback type since we have already callable
• Make the keyword detection case sensitive
• Add a removeKeyword method to the TypeResolver

Please let me know your thoughts, if needed I can also provide a PR for this.

⚠️ Dependabot is rebasing this PR ⚠️

Rebasing might not happen immediately, so don't worry if this takes some time.

Note: if you make any changes to this PR yourself, they will take precedence over the rebase.

Bumps phpstan/phpstan from 1.10.7 to 1.10.8.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

composer(deps-dev): bump phpstan/phpstan from 1.10.7 to 1.10.8

Bumps phpstan/phpstan from 1.10.7 to 1.10.8.

• Release notes
• Changelog
• Commits

updated-dependencies:

• dependency-name: phpstan/phpstan dependency-type: direct:development update-type: version-update:semver-patch ...

Signed-off-by: dependabot[bot] support@github.com

Merge pull request #267 from phpDocumentor/dependabot/composer/phpstan/phpstan-1.10.8

composer(deps-dev): bump phpstan/phpstan from 1.10.7 to 1.10.8

Bumps league/commonmark from 2.3.8 to 2.4.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

composer(deps): bump league/commonmark from 2.3.8 to 2.4.0

Bumps league/commonmark from 2.3.8 to 2.4.0.

• Release notes
• Changelog
• Commits

updated-dependencies:

• dependency-name: league/commonmark dependency-type: direct:production update-type: version-update:semver-minor ...

Signed-off-by: dependabot[bot] support@github.com

Merge pull request #269 from phpDocumentor/dependabot/composer/league/commonmark-2.4.0

composer(deps): bump league/commonmark from 2.3.8 to 2.4.0

Thanks for reaching out to us!

I think this is not an easy bug to fix, this library introduced a number of keywords that will always be reserved for certain cases.

As this library is just focusing on type resolving per file, which makes it lightning fast, we have some limitations, for example we are not able to detect the existence of classes in the same namespace. Php itself could do that, but as far as I know, classes are only loaded when they are used to create an object.

The callback keyword does exist for a while now, and we cannot remove it as this would impact other users, so that would be a backwards compatibility break. It's not worth it to do that for just one use case.

Making keywords case sensitive is also a breaking change, but even a bigger one than removing the keyword. This would have to many impact and would make the library unusable for some coding standards. This is a no go for me.

Your final solution to be able to remove keywords could be an option... But it will possibly cause side effects or give more issues as we cannot assume that all consumers are using the same instance of the type resolver. For example when using symfony you could run into issues when the framework creates an instance. Which it will do when using the serializer.

Given the amount of downloads of this project we have to be careful with changes. Unless this was a unintended bc break, which I think it wasn't, I would not be open for any changes regarding this particular issue.

I would recommend to alter the class name in your project as that will not impact others, or import in in this file with an alias.

I don't see why we have to change our code as the keyword was reserved for more than 10 years without any issues, and give the possible impact of such a change on the php-ecosystem.

I'm sorry to make this statement. But I hope you understand our position.

We could solve that by adding priorities to the rules and inject them in a priority queue.

So it doesn't matter in what order they are injected in the InlineMarkupRule.

Other thing to solve are escaped chars.

Yes this looks 👍

We need to introduce other spantoken types for each rule. I guess you already understood that 😁 And when looking at this, i realized that order of the rules might matter. Because of the overlapping start characters for types of links.

Thanks for taking this effort

Refactor Integration Tests

• clean up temp directories after general test runs
• introduce make cleanup-tests command
• ignore empty lines and trim lines before comparison

Merge pull request #263 from linawolf/integration-tests

Refactor Integration Tests

• clean up temp directories after general test runs
• introduce make cleanup-tests command
• ignore empty lines and trim lines before comparison

Fix issue with ignore symlinks

Ignore symlinks was not migrated correctly with the symfony upgrades. By now the flags are --ignore-symlinks and --no-ignore-symlinks.

fixes #3494

Update docs for ignore docs

Merge pull request #3495 from phpDocumentor/bugfix/3494_ignore_symlinks

Bugfix/3494 ignore symlinks

The setting --ignore-symlinks was not implemented correctly. I introduced the --no-ignore-symlinks to have the negative flag without the need for a value. This makes more sense in the way command line tools work in general.

Fixes #3494

Bump php