-
Notifications
You must be signed in to change notification settings - Fork 20
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
The logic of searching for consecutive replacements is broken #46
Comments
😫 Is there any entry for |
@platisd this is the entire |
So, from what I understand, to reproduce this I need to return a I.e.: // Foo.h
struct Foo {
const int bar();
};
// Foo.cpp
#include "Foo.h"
const int Foo::bar() {
return 42;
} |
@platisd and also we need to have an offset of the second entry to be no more than offset+length of the first entry, because that's how intersection is currently checked: if current_offset + current_length < next_offset - 1:
replacements_are_consecutive = False
break BTW this logic can recognize even fragments of the same file as "consecutive" even if they are in fact not, but they are just specified in "reverse order" for some reason. |
The current logic here:
clang-tidy-pr-comments/run_action.py
Lines 218 to 233 in 3fae50b
is problematic. Consider the following
fixes.yml
:First of all, these replacements are for different files with different
FilePath
s in each replacement, but this is not taken into account when checking for continuity. Second, even though these replacements are not consecutive, they are still considered as such, because7837 + 6
is not less than4838 - 1
.The text was updated successfully, but these errors were encountered: