auto-gen-config should remove inline disable/enable

[Ana06]

When generating the Rubocop todo file, the inspected files for a cop may change. If those files have inline enable or disable sentences, they should also be modified accordingly or we can end with something that is not the expected result.

---

Steps to reproduce the problem & Expected/Actual behavior

When having something like:

# rubocop:disable  Style/NumericPredicate
assert $? == 0, "#{testfile} does not validate against #{f} -> #{testresult}"
# rubocop:enable Style/NumericPredicate

If when running rubocop --auto-gen-config if the number of offenses is higher than 15, and the cop get automatically disabled, I would expect that the inline disable/enable also get removed. If not when running rubocop again there would be offenses like:

Lint/UnneededDisable: Unnecessary disabling of Style/NumericPredicate

Autocorrecting them would also not work, as it would only remove the disable part leaving the enable one, which is not what we pretend here.

And also if the # rubocop:enable Style/NumericPredicate``is there even if the cop is disabled, would the rest of the file get inspected? Because that would be also not expected.

RuboCop version

$ rubocop -V
0.47.1 (using Parser 2.3.3.1, running on ruby 2.4.1 x86_64-linux-gnu)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding!

[Ana06]

😭

[Ana06]

BTW, I would say this is more a bug than a feature... 🤔

[jonas054]

I don't think rubocop --auto-gen-config should update source code. It should stick to just updating configuration. That means we can't be sure that rubocop --auto-gen-config leaves the project in a state without offenses, which is not perfect but I think acceptable in this "corner case".

But I agree that (part of) what you describe is a bug.

Autocorrecting them would also not work, as it would only remove the disable part leaving the enable one

That's the bug. When auto-correct removes a rubocop:disable, it should also remove the corresponding rubocop:enable.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding!