- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Tokens::overrideRange() block cache pruning #8240
Conversation
493d769
to
4092701
Compare
4092701
to
692622d
Compare
can you explain how it is different from a regular fix? It seems to me like unnecessary dramaturgy. |
Of course - crtical = core bug that leads to a code corruption. Here the cache was able to get out of sync and thus answering wrong, I stress this mainly because it should deserve a patch release after it is merged. |
What code corruption? Fixer does not corrupt any file.
"Should"? Does some international law of bugfixing dictate this? I don't think so, then not "should", but "would be nice" or something. Every time you use the phrase "should" (or "must etc.) - and you do it quite often - you sound like someone ordering others (e.g. maintainers) what they are obligated to do, but, hello 👋🏼, this is open source, a place where all people are doing what they are doing in their free time, for free. |
I would love to get this PR integrated ❤ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mvorisek in our contribution guide you can see:
if you work on a bug fix, please start with reproducing the problem by adding failing test case(s). When you have failing test case(s), you can create pull request just to reproduce fail in the CI. Then you can provide fix in the subsequent commits, it will make code review easier. It's allowed to modify existing test cases in bug fix pull request, but only if current behavior is proved to be invalid.
Not only it proves there actually is a bug, but also saves reviewers' time 🙂.
Anyway, I checked it locally and confirmed the buggy behaviour. For those who like code representation more than tokens, the flow here is:
- There's a code
<?php $a= [ ];
- Token 3 (whitespace before
[
) is replaced with[
- Token 5 (whitespace inside brackets) is replaced with
]
- The code now is
<?php $a=[[]];
which is valid (syntax-wise), but right now if you want to get index of a block end for token 4 (opening bracket for inner[]
), it should result with 5, but results with 6, which comes fromTokens::$blockStartCache
Thanks for the fix 🍻!
Thank you very much, it took me almost a day to figure what was going on! |
critical fix #8228 as currently
Tokens::overrideRange()
might leave the block cache corruptedneeded for #8225