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
Do not override Kernel#warn when there is no need #4075
Merged
deivid-rodriguez
merged 3 commits into
rubygems:master
from
eregon:no-kernel-warn-monkey-patch
Dec 7, 2020
Merged
Do not override Kernel#warn when there is no need #4075
deivid-rodriguez
merged 3 commits into
rubygems:master
from
eregon:no-kernel-warn-monkey-patch
Dec 7, 2020
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
@deivid-rodriguez Could you or some other maintainer (who should I ping?) review this? |
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.
Looks good to me, just a minor comment but looks fine either way!
simi
reviewed
Dec 4, 2020
* On Ruby implementations where https://bugs.ruby-lang.org/issues/17259 is available, backtrace entries starting with `<internal:` are ignored for Kernel#warn. We can then define RubyGems's Kernel#require with such a filename and it will automatically be skipped for Kernel#warn. * This is much less fragile (overriding Kernel#warn causes multiple issues and is very difficult to do properly) and it is also more efficient (the override would walk the stack multiple times).
eregon
force-pushed
the
no-kernel-warn-monkey-patch
branch
from
December 4, 2020 11:03
b02c21e
to
09726ae
Compare
Thanks @eregon! |
deivid-rodriguez
added a commit
that referenced
this pull request
Dec 7, 2020
Do not override Kernel#warn when there is no need (cherry picked from commit 058e858)
deivid-rodriguez
added a commit
that referenced
this pull request
Dec 7, 2020
Do not override Kernel#warn when there is no need (cherry picked from commit 058e858)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
is available, backtrace entries starting with
<internal:
are ignoredfor Kernel#warn. We can then define RubyGems's Kernel#require with
such a filename and it will automatically be skipped for Kernel#warn.
issues and is very difficult to do properly) and it is also more
efficient (the override would walk the stack multiple times).
Based on the idea in #3987 (comment)
cc @deivid-rodriguez
What was the end-user or developer problem that led to this PR?
There were various issues due to monkey patching Kernel#warn, a quick search reveals at least:
#3053
#2588
#2911
and ~12 PRs seem to match
Kernel#require
: https://github.com/rubygems/rubygems/pulls?q=is%3Apr+Kernel%23warn(original PR: #2442)
Also as a Ruby implementor, I can say overriding Kernel methods when it's not strictly needed leads to all kind of troubles.
Notably I got some headaches to handle the filtering in TruffleRuby and still let the filtering on RubyGems understand what's going on (it was not enough to just filter twice to give an idea of the complexity).
And of course having subtle behavior differences when passing
--disable-gems
for Kernel#warn is very confusing (I got tricked by this multiple times).What is your fix for the problem, implemented in this PR?
This PR is a nice way to not need to monkey-patch at all, and still always skip RubyGems'
require
when usingwarn('message', uplevel: 1)
, for instance at the top of a file to emit a deprecation warning. So it fixes the original problem #2442 without monkey-patching anything.Make sure the following tasks are checked