@mvorisek how about this one? Will #7679 fix this one too?

This seems like a duplicate of #7460, this is not touch by my PR, but easy to fix after.

I'm not sure if it's really a duplicate.

7460 wants to convert \foo\bar(); into bar(); (feature)
while this PR asks to prevent \foo\bar::class into bar::class conversion (bug)

#7679 solves all classy bugs :)

can you link a test case in your PR that covers \myNs\myFunction::class case described by this issue?

As I think about it, are we even able to distinguish imports for classes and functions if both can use ::class? Currently we import only classy symbols found in several places. We can safely import functions from FQN-based function call, but for ::class we actually don't know the context 😕. The root cause of this issue shows this clearly...

u::class is basically a refactorable string. It can refer class, it can refer namespace, ... I belive ::class should be always imported as class or do you want to try to guess the context from the surrounding function usage?

I would rather avoid it, because with token-based logic it would be awfully hard probably. However, importing ::class always as class makes this fixer somehow risky... 🤔. But if it's behind an opt-in flag, then we probably can add such information to the option instead of marking whole fixer as such. @keradus what do you think?

I think you folks are wondering of "how to import such ::class usage with use import statement.

This issue is not about it.

This issue is to prevent this conversion:

input

<?php

use function Symfony\Component\String\u;

echo Symfony\Component\String\u::class;

expected output

no change

actual output

<?php

use function Symfony\Component\String\u;

echo u::class;