PHP array shapes in „fix imports”
- Dominant language
- Java
- Stars
- 3.1k
- Forks
- 935
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 17
Description
### Description
When I have a code with „[array-shapes](https://phpstan.org/writing-php-code/phpdoc-types#array-shapes)“ phpDoc, the „fix import“ functionality don't understand them.
Steps to reproduce:
### Steps to reproduce:
- Create a new file `Foo.php` with the content
```php
$data
*/
public function doSomething(array $data): Foo {
return $data['foo'];
}
/**
* @param array<'baz', Baz> $data
*/
public function doSomethingElse(array $data): void {
$data['baz']->doSomething();
}
}
```
- Shift + Ctrl + I (_Menu: Source > Fix Imports_)
### Actual Result:
The „fix import“ functionality don't understand:

### Expected Result:
The „fix import“ functionality don't show the `array<'foo',` and `array<'baz',` parts

### Perfect Result:
The „fix import“ shows the missing `\Vendor\Project\Baz\Baz` part

### Use case/motivation
I want to have code compatible with static-analysis but sometimes I have to describe the array-shapes like this.
And because the Netbeans don't understand this, they can't see, that `Foo` class there is from different namespace and remove the definition from usages.
### Related issues
_No response_
### Are you willing to submit a pull request?
I want to, but I'm not a Java developer
### Code of Conduct
Yes
Contributor guide
Research direction
Start with the Foo.php, Baz.php, and Bar.php reproducer and run Source > Fix Imports in NetBeans. Trace the PHP import-fixing behavior for the array-shape annotations, especially the array<'foo', Foo> and array<'baz', Baz> parts. Done means the array-shape keys are not treated as imports and the missing Baz namespace can be suggested correctly.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- php
- Domain
- tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100