-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Lint/Debugger complains about using "console" when it is not appropriate #9500
Comments
RuboCop is not currently aware of where a method being called is defined, so your various ways of defining That being said, when #8929 changed how |
…vers for debug methods lead to offenses. Prior to rubocop#8929, `Lint/Debugger` looked for a specific receiver/method pair, but that PR changed it so that any of the `DebuggerReceivers` would apply, *or also* no receiver. This caused regressions (rubocop#7636 and rubocop#9500, for instance) because method names specified as debugger by this cop would now register offenses when called with no receiver. In order to fix it, I changed the configuration for `Lint/Debugger` a bit, but in a way that should not cause any major incompatibility. The allow list is now specified including its receiver so that the receiver can be checked. Existing configurations that just pass in a method name will be treated as expecting no receiver (there's a slight incompatibility there because previously `foo` would be matched by `Kernel.foo` but I think this is ok (and is resolvable by adding `Kernel.foo` to the configuration). I've also grouped the debugger methods by source (it's often confusing to me where each method comes from), which also allows an end-user to disable a pre-defined group of methods by specifying `Byebug: ~` for example. Finally I've deprecated the `DebuggerReceivers` configuration as it is no longer useful.
…r debug methods lead to offenses. Prior to #8929, `Lint/Debugger` looked for a specific receiver/method pair, but that PR changed it so that any of the `DebuggerReceivers` would apply, *or also* no receiver. This caused regressions (#7636 and #9500, for instance) because method names specified as debugger by this cop would now register offenses when called with no receiver. In order to fix it, I changed the configuration for `Lint/Debugger` a bit, but in a way that should not cause any major incompatibility. The allow list is now specified including its receiver so that the receiver can be checked. Existing configurations that just pass in a method name will be treated as expecting no receiver (there's a slight incompatibility there because previously `foo` would be matched by `Kernel.foo` but I think this is ok (and is resolvable by adding `Kernel.foo` to the configuration). I've also grouped the debugger methods by source (it's often confusing to me where each method comes from), which also allows an end-user to disable a pre-defined group of methods by specifying `Byebug: ~` for example. Finally I've deprecated the `DebuggerReceivers` configuration as it is no longer useful.
If I define and use a
console
method,attr_reader :console
or a minitest/speclet(:console)
Lint/Debugger says I should "Remove debugger entry point console".I have not
require
d a debugger, nor have I added one to aGemfile
, so I cannot be entering a debugger, I'm working with a method or accessor that is appropriately named for my usage and is in-scope. Nomethod_missing
magic is involved.Expected behavior
Lint/Debugger does not complain by default about methods I define that happen collide with a debugging tool I have not even loaded a gem for.
I expect zero lint warnings for the code included below.
Actual behavior
Steps to reproduce the problem
Run
rubocop -l
on test embedded aboveRuboCop version
The text was updated successfully, but these errors were encountered: