| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Let users generate gemfiles inside paths whos parent contains a Gemfile
### What was the end-user problem that led to this PR?
Users are unable to generate a new Gemfile with `bundle init` if there is a Gemfile in any
parent folder.
Closes #6205
### What is your fix for the problem, implemented in this PR?
Don't use `SharedHelpers.default_gemfile` as that searches up the paths for a Gemfile. Instead only check the current directory.
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Show warning message about binstub outside generation.
/cc @indirect
Fixes #6149.
Originated from https://github.com/bundler/bundler/issues/6149#issuecomment-347783823
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Fixes #6149.
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Ignore to generate documentation of templates.
### What was the end-user problem that led to this PR?
When users invoke `rdoc -o rdoc lib`, it generates documentation contains template files under the `lib/bundler/template` like `rdoc/lib/bundler/templates/newgem/bin/setup_tt.html`
These files are not useful for users.
### What is your fix for the problem, implemented in this PR?
I added `.document` file to its directory.
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Setup custom Gemfile path before loading bundler for binstubs
### What was the end-user problem that led to this PR?
While you have several gemfiles: `Gemfile` and `Gemfile.tools`.
and generates binstubs for gems from second gemfile: `BUNDLE_GEMFILE=Gemfile.tools bundle binstubs rubocop`
when you invoke those bin `bin/rubocop`
then you see error like:
```bash
/usr/local/opt/rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/bundler-1.16.0/lib/bundler/rubygems_integration.rb:458:in `block in replace_bin_path': can't find executable rubocop for gem rubocop. rubocop is not currently included in the bundle, perhaps you meant to add it to your Gemfile? (Gem::Exception)
from /usr/local/opt/rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/bundler-1.16.0/lib/bundler/rubygems_integration.rb:489:in `block in replace_bin_path'
from bin/rubocop:21:in `<main>'
```
### What was your diagnosis of the problem?
When you have generated `bin/bundler` by rails or by `bundler` it has setup of `BUNDLE_GEMFILE` by default as `Gemfile` or by gemfile which has been setup on `bundle binstub bundler`.
So your binstub for rubocop could not change it.
### What is your fix for the problem, implemented in this PR?
I propose to use`BUNDLE_GEMFILE` from gem's binstub over bundler's binstub version
### Why did you choose this fix out of the possible options?
This was default behavior before #5878 introduced. Just added some fix to related PR.
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Allow test execution in paths containing dash.
PR #5036 added restriction on what characters can be contained in path,
from where the specs are executed. But they dissallows even dash, which
is hopefully handled just fine on all systems.
This patch fixes #6185 by relaxing the restriction a bit and allowing
path to contain dash.
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
PR #5036 added restriction on what characters can be contained in path,
from where the specs are executed. But they dissallows even dash, which
is hopefully handled just fine on all systems.
This patch fixes #6185 by relaxing the restriction a bit and allowing
path to contain dash.
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Ensure git is executed inside the gemspec dir
### What was the end-user problem that led to this PR?
Executables from bundled gems weren't available.
```
Gem::Exception: can't find executable <EXEC-FILENAME> for gem <GEM-NAME>
/Users/elia/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0/bundler/rubygems_integration.rb:458:in `block in replace_bin_path'
/Users/elia/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0/bundler/rubygems_integration.rb:478:in `block in replace_bin_path'
…
```
### What was your diagnosis of the problem?
When a Gemfile was pointing to a local gem using git to list its files the git command
was executed from within the wrong dir.
### What is your fix for the problem, implemented in this PR?
Initially I added `-C #{__dir__}` to the `git ls-files -z` command.
### Why did you choose this fix out of the possible options?
Realized `-C` wasn't safe and opted for stuff already available in the corelib, i.e. `Dir.chrid` instead of, say, escaping with `shellwords`.
---
I know the line is long-ish, happy to fix it in the way you want
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
When a Gemfile was pointing to a local gem using git to list its files the git command
was executed from within the wrong dir. This fixes the issue without:
1. introducing new dependencies (e.g. `shellwords`)
2. any risks with non-trivial paths (e.g. paths containing spaces)
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Stop overriding specs during double-checks
This fixes my test-case reproduction of #6072. I’m pretty sure it’s because
the double-check was overriding the locally installed index specs with
specs fetched from the RubyGems API, causing Bundler to conclude that the
gems aren’t installed, even though they are.
@deivid-rodriguez @y-yagi can you verify that this patch fixes the issues with `inline` that you were seeing?
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
this test appears to only fail when the server is rubygems.org, so I
moved the test into realworld and pulled in vcr.
|
| | | | | |
|
| | |/ /
| | |
| | |
| | |
| | |
| | | |
This fixes my test-case reproduction of #6072. I’m pretty sure it’s
because the double-check was overriding the locally installed index
specs with specs fetched from the RubyGems API, causing Bundler to
conclude that the gems aren’t installed, even though they are.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Be more precise when replacing Bundler version in lock file.
Lets say the current Bundler version is 1.16.0. If the test suite is, by a chance, executed in directory which contains such version string, this path is stored in Gemfile.lock file. Later, the test tries to replace
the version of Bundler in the lock file, but instead, it replaces the version in path. Be more careful what should be actually replaced.
This is related to #6185 although it does not resolve the original concern.
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Lets say the current Bundler version is 1.16.0. If the test suite is, by
a chance, executed in directory which contains such version string, this
path is stored in Gemfile.lock file. Later, the test tries to replace
the version of Bundler in the lock file, but instead, it replaces the
version in path. Be more careful what should be actually replaced.
This is related to #6185 although it does not resolve the original
concern.
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Include bundler.gemspec in the gem because warbler breaks w/o it
f06405 caused a regression with warbler, described in #6165 and jruby/warbler#421
If the fix is ok, it should probably be cherry-picked to 1-16-stable.
### What was the end-user problem that led to this PR?
Upgrading from bundler v1.15.x to v1.16.0 causes warbler to break/abort with error.
### What was your diagnosis of the problem?
1. error message from warbler: missing file
2. see why file is missing
3. google to see if it's just me 😄
### What is your fix for the problem, implemented in this PR?
Put the missing (from warblers point of view at least) back.
### Why did you choose this fix out of the possible options?
Seems easier than to fix warbler.
|
| |/ /
| |
| |
| | |
f06405 caused a regression with warbler, described in #6165
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
r=indirect
Resolver: treat dependencies with prerelease versions as slightly constrained
Fixes https://github.com/bundler/bundler/issues/6181.
In Bundler 1.15.4, the way we checked for pre-releases meant that dependencies with a lot of them sorted as more constrained than those with few/none. When we moved to our updated resolution strategy in 1.16.0 we accidentally lost that behaviour.
I'm not wild about this PR, but it fixes the resolver regression. It's unsatisfying because it would be nice to believe the resolver will always resolve performantly, regardless of the sort order thrown at it, but clearly that isn't the case.
Conceptually, this can be justified as "when two resolutions are possible, we prefer the one that does not require one dependency to be at a pre-release version".
If others are happy with this I can write a test for it.
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Stop requesting changelogs in PRs
We added this requirement before the changelog was automated. Now that the changelog generated by a script, it's not helpful for PRs to update the changelog anymore, so we shouldn't expect it anymore.
### What was the end-user problem that led to this PR?
We had to [ask a PR to remove a changelog entry](https://github.com/bundler/bundler/pull/6157#discussion_r149701953), even though the PR was following [the docs](https://github.com/bundler/bundler/blob/374caf6ede2cf4de7d2196aa2e2adef782bea5bd/doc/development/PULL_REQUESTS.md#changelogmd).
### What was your diagnosis of the problem?
It looks like we failed to update the docs when we automated generating the changelog.
### What is your fix for the problem, implemented in this PR?
Removing the changelog requirement from the docs hopefully means that future PRs will not include changelog entries, and we can generate future changelogs automatically.
### Why did you choose this fix out of the possible options?
I chose this fix because it seemed like the smallest change that would accomplish the goal.
/cc @mattbrictson
|
| | |
| |
| | |
We added this requirement before the changelog was automated. Now that the changelog generated by a script, it's not helpful for PRs to update the changelog anymore, so we shouldn't expect it anymore.
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
r=indirect
Fix NoMethodError during `bundle update --group`
### What was the end-user problem that led to this PR?
#6156: NoMethodError: undefined method `version' for nil:NilClass
### What was your diagnosis of the problem?
The `bundler` gem does not participate in the lockfile, but it can still be included in the list of dependencies that are being updated by `bundle update` if `--group` is specified.
For example, if a Gemfile contains `bundler-audit` (which depends on `bundler`) in the `:development` group, then updating with the option `--group=development` will naturally include `bundler` in the list of gems to evaluate for updating.
The trouble is that since `bundler` is excluded from the lockfile, searching the locked gems for a gemspec for bundler will return `nil`. This caused the following error during `bundle update`:
NoMethodError: undefined method `version' for nil:NilClass
### What is your fix for the problem, implemented in this PR?
This PR solves this bug by skipping over gems (i.e `bundler`) that are not in the lockfile when comparing gem versions at the conclusion of the upgrade command.
Fixes #6156.
### Why did you choose this fix out of the possible options?
I chose this fix because the bug seems to have been introduced by 618c09b59d1318958c23b1b0031c68c93186851a. My fix takes place within the new feature that was added in that commit, so it seems safe and unlikely to have side-effects.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `bundler` gem does not participate in the lockfile, but it can still
be included in the list of dependencies that are being updated by
`bundle update` if `--group` is specified.
For example, if a Gemfile contains `bundler-audit` (which depends on
`bundler`) in the `:development` group, then updating with the option
`--group=development` will naturally include `bundler` in the list of
gems to evaluate for updating.
The trouble is that since `bundler` is excluded from the lockfile,
searching the locked gems for a gemspec for bundler will return `nil`.
This caused the following error during `bundle update`:
NoMethodError: undefined method `version' for nil:NilClass
This commit solves this bug by skipping over gems (i.e `bundler`) that
are not in the lockfile when comparing gem versions at the conclusion of
the upgrade command.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Update `config` page link to the recent version
### What was the end-user problem that led to this PR?
In the `man/bundle-gem.ronn`, we are using a hard-coded version number to link the `bundle-config` doc, which is `v1.14` in this case. Ref: https://bundler.io/v1.16/man/bundle-gem.1.html
### What is your fix for the problem, implemented in this PR?
<del>This commit updates the link and uses a relative path so it will always point to the recent version.</del>
Edit: This commit updates the link to the current stable version.
|
| |/
|
|
|
|
|
|
| |
In the `man/bundle-gem.ronn`, we are using a reference from the
old version, which is `v1.14` in this case. This commit updates
that link to the current stable version.
Ref: https://bundler.io/v1.16/man/bundle-gem.1.html
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Bail out of reducing depency trees on huge dependency conflict sets
### What was the end-user problem that led to this PR?
The problem is described in #6114 - An unusually large set of conflicting dependencies leads to bundler get stuck and lead to very unhealthy amounts of memory and CPU time be consumed.
### What was your diagnosis of the problem?
This happens because because a too large array is fed into Array#combination in the "reduce_trees" lambda in `version_conflict_message`.
### What is your fix for the problem, implemented in this PR?
By simply bailing out when the conflict set is bigger than a certain size,
we'll get a result that is similar to what happened in earlier bundler versions
but skip a ton of CPU cycles and memory allocations.
I've chosen the limit rather unscientifically by playing around with the result
set sizes. 15 seems to be a good compromise but really anything larger than 10
should work (and with work I mean "should not usually not have to be invoked").
### Why did you choose this fix out of the possible options?
Reducing the conflict trees has been a rather new addition to bundler, so defaulting back to the old behavior of not reducing the trees seems like an OK option. It may be possible to also optimize the reduction algorithm, but since this is very much an edge case that only happens when using Bundler slightly out of the normal procedures, I think a simple bail out is sufficient.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a simple fix for #6114, in which sometimes conflict sets get so huge that
the current reducing code (which is based on Array#combination) breaks down.
By simply bailing out when the conflict set is bigger than a certain size,
we'll get a result that is similar to what happened in earlier bundler versions
but skip a ton of CPU cycles and memory allocations.
I've chosen the limit rather unscientifically by playing around with the result
set sizes. 15 seems to be a good compromise but really anything larger than 10
should work (and with work I mean "should not usually not have to be invoked").
|
| |\ \
| |/
|/|
| |
| |
| | |
[Travis] Test against RubyGems 2.7.0
Since I just released 2.7.0, we now have to test against it!
|
| |/ |
|
| |\
| |
| |
| | |
Version 1.16.0
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
r=colby-swandale
Ensure that autoloads are resolved in the real working directory
Fixes an issue on 2.5.0-dev where using local git overrides would cause an exception because the default bundler had been loaded
### What was the end-user problem that led to this PR?
The problem was Bundler was failing 8 specs against ruby trunk.
### What was your diagnosis of the problem?
My diagnosis was when the autoload for `URICredentialsFilter` fired in a `chdir` block, the default bundler gem was getting activated.
### What is your fix for the problem, implemented in this PR?
My fix eagerly trips that auto-load in the git proxy.
### Why did you choose this fix out of the possible options?
I chose this fix because it's a one-liner.
(cherry picked from commit ccc5d6130c68c6989a2553f454d2d5d67caff025)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Update vendored Molinillo to 0.6.4
### What was the end-user problem that led to this PR?
The problem was uncovered in #6114.
### What is your fix for the problem, implemented in this PR?
My fix updates molinillo to 0.6.4.
### Why did you choose this fix out of the possible options?
See https://github.com/CocoaPods/Molinillo/releases/tag/0.6.4 for release notes.
(cherry picked from commit b20214d10ac9883eb54b7c08bdeb3e2724bc018e)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Prioritise explicitly requested gems in dependency resolution sort order
### What was the end-user problem that led to this PR?
Calling `bundle update github-pages` on https://github.com/Floppy/cv was causing a downgrade in the `github-pages` version.
### What was your diagnosis of the problem?
The `Bundler::Resolver#sort_dependencies` method didn't have any logic to prioritise explicitly requested gems. Therefore, where two rival resolutions were possible (in this case one with `activesupport` at 5.1.4 and `github-pages` at 24, and one with `github-pages` at 166 and `activesupport` at 4.2.9), Bundler didn't always correct the most desirable resolution.
### What is your fix for the problem, implemented in this PR?
My fix is to explicitly prioritise requested gems in the dependency sort order during resolution.
### Why did you choose this fix out of the possible options?
I chose this fix because it's intuitive.
(cherry picked from commit 23316ffeafa83b460a86da95e51b3704c6faec12)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Avoid activating stdlib digest under Ruby 2.5
The problem was, under ruby 2.5, Bundler would activate digest, which is now a stdlib gem, preventing users from choosing a different version.
With this change, the travis build against trunk should go green, hopefully.
My diagnosis was we needed to lazy-load digest.
My fix removes all `require "digest"` top-level statements from the Bundler codebase, and replaces the top-level `Digest` method with one that will `require "digest"`.
I chose this fix because it would keep the use of digest classes thread-safe.
\c @hsbt
(cherry picked from commit b9c12ee67661581f8a4fb5f47a375b5c7da2ed1e)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Avoid bundle exec rescue of SignalException
Avoid rescue of SignalException in kernel_load and with_friendly_errors This allows SignalException to be handled gracefully by the ruby interpreter.
This supersedes #6091.
### What was the end-user problem that led to this PR?
Fixes #6090
### What was your diagnosis of the problem?
CLI::Exec#kernel_load should not rescue the SignalException. Neither should with_friendly_errors, so it unwinds all the way to the ruby interpreter.
### What is your fix for the problem, implemented in this PR?
Two rescue and re-raises specific to SignalException.
### Why did you choose this fix out of the possible options?
My first naive attempt was #6091, where I had missed the outer rescue in with_friendly_errors, all of the other special friendly error behavior, and the spec dependencies. While I still suspect that kernel_load and friendly_errors might be rescuing/handling more than they should (for comparison: binstub doesn't do this) this is a much more minimal, safer, and easier fix to #6090.
(cherry picked from commit 6d0b74cde28ea0c1724f37ff799cd7524ff0d9b4)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix doubled message in verbose mode
The problem was doubled informative message in verbose mode (#6028)
`Bundler::Definition#missing_specs?` clears the `@resolve` ivar due to
the fact that `ensure` clause evaluates regardless whether exception
occurred. That results in repeated resolution, and, therefore, in
repeated debug messages.
This change moves ivars clearing into the `rescue` clause, so
`@resolve` will be cleared only in case when `BundlerError` occurs
I chose this fix because running deps resolution twice is a bad idea anyway and it needs to be prevented.
(cherry picked from commit 6c90bcb2969a302c33c8117b50c06543f3ba4741)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
remove non-ascii chars from binstubs man page
### What was the end-user problem that led to this PR?
There are some non-ascii characters in `man/bundle-binstubs.ronn` that is causing a build failure when `ronn` is compiling the man pages on linux
```
...
/usr/local/bin/ruby -S ronn --roff --pipe man/bundle-binstubs.ronn > man/bundle-binstubs.1
/usr/local/bundle/gems/ronn-0.7.3/lib/ronn/document.rb:192:in `split': invalid byte sequence in US-ASCII (ArgumentError)
from /usr/local/bundle/gems/ronn-0.7.3/lib/ronn/document.rb:192:in `sniff'
from /usr/local/bundle/gems/ronn-0.7.3/lib/ronn/document.rb:76:in `initialize'
from /usr/local/bundle/gems/ronn-0.7.3/bin/ronn:166:in `new'
from /usr/local/bundle/gems/ronn-0.7.3/bin/ronn:166:in `block in <top (required)>'
from /usr/local/bundle/gems/ronn-0.7.3/bin/ronn:166:in `map'
from /usr/local/bundle/gems/ronn-0.7.3/bin/ronn:166:in `<top (required)>'
from /usr/local/bundle/bin/ronn:23:in `load'
from /usr/local/bundle/bin/ronn:23:in `<main>'
rake aborted!
Command failed with status (1): [/usr/local/bin/ruby -S ronn --roff --pipe ...]
/opt/bundler/Rakefile:275:in `block (3 levels) in <top (required)>'
/opt/bundler/Rakefile:32:in `block in invoke'
/opt/bundler/Rakefile:31:in `invoke'
Tasks: TOP => man:build => man:build_all_pages => man/bundle-binstubs.1.txt => man/bundle-binstubs.1
(See full trace by running task with --trace)
/opt/bundler/spec/support/manpages.rb:11:in `setup': Failed building man pages (RuntimeError)
from /opt/bundler/spec/spec_helper.rb:47:in `<top (required)>'
from /usr/local/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/local/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/local/bundle/gems/rspec-core-3.6.0/lib/rspec/core/configuration.rb:1453:in `block in requires='
from /usr/local/bundle/gems/rspec-core-3.6.0/lib/rspec/core/configuration.rb:1453:in `each'
```
### What is your fix for the problem, implemented in this PR?
Replace characters with their ascii equivalent
(cherry picked from commit 69ca440c3a122b65e95dbcc203383ee835158e1c)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix "assigned but unused variable" warning in Ruby 2.5
We're seeing several "assigned but unused variable" warnings when we run `bundle` in Ruby 2.5 with `RUBYOPT=-w`.
This is because Ruby 2.5's unused variable check has been improved since https://github.com/ruby/ruby/commit/37b04894f20a5d3701309a2055bfa03b9d760090, and [previous double-assignment technique](https://github.com/bundler/bundler/blob/fea177f61df71121c6f9422a74b093e42c504388/lib/bundler/installer.rb#L116) no longer works as an anti-warning workaround.
For example, here's a short reproducible code that doesn't warn in 2.4 but warns in 2.5:
```ruby
`def a() x = x = 1; end`
```
So here are updated workarounds against this warning, which are valid for both Ruby < 2.5 and >= 2.5.
(cherry picked from commit 3847fd5e9605c794fd1f6362029c57c466d3d77a)
|
