use fully qualified name when extracting variable type

It's not easy to understand what is fixed. So, I would write the following to the commit message title instead. (Also an example)

"[GH-8286] Fix Go to Declaration for an enum method using an FQ name"

Example:

namespace test1;

enum TestA {

    case X;

    public function get(string $param): string {
        return '';
    }
}

namespace test2;

\test1\TestA::X->get('xxx'); // don't work go to declaration & mark occurrences for the get method

Sadly I was not able to create unit tests for this.

It's possible. Please add unit tests for GotoDeclaration and MarkOccurrences. (GotoDeclarationPHP81Test or GotoDeclarationGH8286Test)

Please add the issue number(e.g. [GH-8286]) or URL to the commit message. Thanks!

@junichi11 Thank you for your feedback. It seems I misunderstood something about the unit tests. I added 2 test cases and changed the implementation due to failing tests. I hope it is more clear now what is happening.
It appears I have reformatted the code of VariousUtils, is there any Formatting Guideline active for NB?

It appears I have reformatted the code of VariousUtils, is there any Formatting Guideline active for NB?

Basically just follow the existing source code. Please reformat only your changes.

You have to squash as one commit.
As I wrote above, we should add an example to the commit message.

[GH-8286] Fix Go to Declaration for an enum method using an FQ name

Example:
```php
namespace test1;

enum TestA {

    case X;

    public function get(string $param): string {
        return '';
    }
}

namespace test2;

\test1\TestA::X->get('xxx'); // don't work go to declaration & mark occurrences for the get method
``` 

@junichi11 squashed, changed formatting, added result files

@junichi11 changed to 4 spaces. Is there any correct way to push these kind of changes while keeping it in the same commit? Now I have been using --force, although I have heard it is not good to do that

This should be no problem because it is a topic branch and we can see the diff(https://github.com/apache/netbeans/compare/88a3a985ba388732459deb98aa83c406755ead1b..65cb2cf61af76acf8b1e587186e1562a75d8d3f6).

• fix something
• git commit --amend
• force push

or

• fix something
• git commit
• fix something
• git commit
• ...
• review is done
• squash them as one commit
• force push

Please also change the title of this PR. Thanks!

@NReib, thanks for this PR! 🎉

Regarding Git force-pushing - typically, it is totally OK, if you are the only person working on the branch. It should/cannot be used when more people work on it, since it basically rewrites the Git history (so, if user A force-pushes something, it could overwrite - and therefore loose - changes done by someone else).

@NReib, as @junichi11 wrote, please always try to unify the issue and the PR so it is clear that they belong to each other. For the issue, I can see this:

Also, providing a code example in the PR description helps a lot.

Thank you.

(I changed the PR title now.)