fix: fully_qualified_strict_types must honor kind uses
#7704
Conversation
mvorisek
force-pushed
the
fix_kind_uses
branch
2 times, most recently
from
1d5e223
to
b396a40
Compare
mvorisek
force-pushed
the
fix_kind_uses
branch
from
b396a40
to
156820d
Compare
| $namespaceName = $namespace->getFullName(); | ||
| $uses = []; | ||
| $lastUse = null; | ||
| foreach ([self::KIND_CLASS, self::KIND_FUNCTION, self::KIND_CONST] as $kind) { |
There was a problem hiding this comment.
To be honest I think I prefer my implementation in #7705 because it does not multiply iterations over file. "Everything" is collected and fixed in dedicated phase, because caches are sliced by import kind.
There was a problem hiding this comment.
The performance will be nearly the same in reality.
I actually prefer mine, because there is no point for passing $kind into resolve/shorten type. We should pass only relevant (for relevant kind) uses.
Also filtering for specific kind fixes can be done easier in the future.
There was a problem hiding this comment.
The performance will be nearly the same in reality.
How's that? You iterate over 3 kinds, for each of them you determine namespace declarations, and for each namespace you do 2 phases of processing. That's 9 iterations over tokens list (considering single namespace in file), comparing to 3 in my implementation. For large files it will have significant difference 🙂.
there is no point for passing $kind into resolve/shorten type. We should pass only relevant (for relevant kind) uses.
It is required with cache-per-kind approach, because symbol comparison must be done within the same kind. So even if there's one additional thing to pass around, it's much less overhead than 3 times more iterations over same tokens list.
Also filtering for specific kind fixes can be done easier in the future.
What kind of filtering? You mean "fix only functions"? Probably that if tree should be sliced by kind, I don't see as a problem in my implementation 😅.
There was a problem hiding this comment.
Iterating million of tokens should not be that slow. Do you have some numbers?
But you PR is fine as well, maybe get inspired by self::KIND_ constants and cherry pick the 2nd refactor, then the PRs outside the main loop are basically the same.
Also feel free to impl. the actual function/const locating, I do not plan to implement it.
fix #7652