iff means if and only if, but readers without that knowledge might
assume this to be a spelling mistake. To me, this seems like
exclusionary language that is unnecessary. Simply using "if and only if"
instead should suffice.
because the name "MJIT" is an internal code name, it's inconsistent with
--jit while they are related to each other, and I want to discourage future
JIT implementation-specific (e.g. MJIT-specific) APIs by this rename.
[Feature #17490]
Previously, due to a change to fix bug 15608, Method#inspect output
changed for class methods:
Ruby 2.7
"#<Method: String.prepend(*)>"
Before change:
"#<Method: #<Class:Object>(Module)#prepend(*)>"
This is wrong because the Method object was created from String and
not Object. This is because the fix for bug 15608 assumed it was
being called on the singleton class of a instance, and would skip
the first singleton class until it got to the class itself. For
class methods, this results in always using the superclass. Fix
behavior to not skip until the superclass if the singleton class
is the singleton class of a module or class.
After change:
"#<Method: #<Class:Object>(Module)#prepend(*)>"
Fixes [Bug #17428]
* Use the wrapper of rb_cObject instead of data access
* Replaced rest of extentions
* Updated the version guard for Data
* Added the version guard of rb_cData
Has been deprecated since 684bdf6171.
Matz says in [ruby-core:83954] that Data should be an alias of Object.
Because rb_cData has not been deprecated, let us deprecate the constant
to make it a C-level synonym of rb_cObject.
This automatically choosess whether to use transfer on a transferring
fiber or resume on a yielding fiber. If the fiber is resuming, it
raises a FiberError.
* Windows: Read ENV names and values as UTF-8 encoded Strings
Implements issue #12650: fix https://bugs.ruby-lang.org/issues/12650
This also removes the special encoding for ENV['PATH'] and some
complexity in the code that is unnecessary now.
* Windows: Improve readablity of getenv() encoding
getenv() did use the expected codepage as an implicit parameter of the macro.
This is mis-leading since include/ruby/win32.h has a different definition.
Using the "cp" variable explicit (like the other function calls) makes it
more readable and consistent.
* Windows: Change external C-API macros getenv() and execv() to use UTF-8
They used to process and return strings with locale encoding,
but since all ruby-internal spawn and environment functions use UTF-8,
it makes sense to change the C-API equally.
* Use UTF-8 as default for Encoding.default_external on Windows
* Document UTF-8 change on Windows to Encoding.default_external
fix https://bugs.ruby-lang.org/issues/16604
This commit deletes
{IO,ARGF,StringIO,Zib::GZipReader}#{bytes,chars,lines,codepoints}, which
have been deprecated since c47c095b97.
Note that String also has those methods. They are neither depreacted
nor deleted because they are not aliases of counterpart each_something.
Random generators are not Ractor-safe, so we need to prepare
per-ractor default random genearators. This patch set
`Random::DEFAULT = Randm` (not a Random instance, but the Random
class) and singleton methods like `Random.rand()` use a per-ractor
random generator.
[Feature #17322]
This modifies the following String methods to return String instances
instead of subclass instances:
* String#*
* String#capitalize
* String#center
* String#chomp
* String#chop
* String#delete
* String#delete_prefix
* String#delete_suffix
* String#downcase
* String#dump
* String#each/#each_line
* String#gsub
* String#ljust
* String#lstrip
* String#partition
* String#reverse
* String#rjust
* String#rpartition
* String#rstrip
* String#scrub
* String#slice!
* String#slice/#[]
* String#split
* String#squeeze
* String#strip
* String#sub
* String#succ/#next
* String#swapcase
* String#tr
* String#tr_s
* String#upcase
This also fixes a bug in String#swapcase where it would return the
receiver instead of a copy of the receiver if the receiver was the
empty string.
Some string methods were left to return subclass instances:
* String#+@
* String#-@
Both of these methods will return the receiver (subclass instance)
in some cases, so it is best to keep the returned class consistent.
Fixes [#10845]
https://rubyci.org/logs/rubyci.s3.amazonaws.com/rhel8/ruby-master/log/20201112T123004Z.fail.html.gz
```
1)
File.utime allows Time instances in the far future to set mtime and
atime (but some filesystems limit it up to 2446-05-10) FAILED
Expected [559444, 2446].include? 2038
to be truthy but was false
/home/chkbuild/chkbuild/tmp/build/20201112T123004Z/ruby/spec/ruby/core/file/utime_spec.rb:80:in
`block (4 levels) in <top (required)>'
/home/chkbuild/chkbuild/tmp/build/20201112T123004Z/ruby/spec/ruby/core/file/utime_spec.rb:3:in
`<top (required)>'
```
```
$ touch foo
$ ./miniruby -e 'time = Time.at(1<<44); File.utime(time, time, "foo")'
$ ls -l foo
-rw-r--r--. 1 mame wheel 0 Jan 19 2038 foo
```
Using Fiber#transfer with Fiber#resume for a same Fiber is
limited (once Fiber#transfer is called for a fiber, the fiber
can not be resumed more). This restriction was introduced to
protect the resume/yield chain, but we realized that it is too much
to protect the chain. Instead of the current restriction, we
introduce some other protections.
(1) can not transfer to the resuming fiber.
(2) can not transfer to the yielding fiber.
(3) can not resume transferred fiber.
(4) can not yield from not-resumed fiber.
[Bug #17221]
Also at the end of a transferred fiber, it had continued on root fiber.
However, if the root fiber resumed a fiber (and that fiber can resumed
another fiber), this behavior also breaks the resume/yield chain.
So at the end of a transferred fiber, switch to the edge of resume
chain from root fiber.
For example, root fiber resumed f1 and f1 resumed f2, transferred to
f3 and f3 terminated, then continue from the fiber f2 (it was continued
from root fiber without this patch).
As [Bug #16662] lchmod available in linux since glibc 2.31.9000, a
system call may exist or not exist depending on the version. It
is not a spec nor responsibility of Ruby.
This adds the following C-API functions that can be used to emit
warnings with categories included:
```c
void rb_category_warn(const char *, const char*, ...)
void rb_category_warning(const char*, const char*, ...)
```
Internally in error.c, there is an rb_warn_category function
that will call Warning.warn with the string and the category
keyword if it doesn't have an arity of 1, and will call
Warning.warn with just the string if it has an arity of 1.
This refactors the rb_warn_deprecated{,_to_remove} functions
to use rb_warn_category.
This makes Kernel#warn accept a category keyword and pass it
to Warning.warn, so that Ruby methods can more easily emit
warnings with categories. rb_warn_category makes sure that
the passed category is a already defined category symbol
before calling Warning.warn.
The only currently defined warning category is :deprecated,
since that is what is already used. More categories can be
added in later commits.
In an executable script, the shebang line should be the first line (the
file needs to start with the bytes 0x23 0x21). Putting a comment above
it will break the script.
(Regression test included per @deivid-rodriguez)
https://github.com/rubygems/rubygems/commit/962e669feb
This reverts commit eeef16e190.
This also reverts the spec change.
Preventing the SystemStackError would be nice, but there is valid
code that the fix breaks, and it is probably more common than cases
that cause the SystemStackError.
Fixes [Bug #17182]
* Enables Mutex to be used as synchronization between multiple Fibers
of the same Thread.
* With a Fiber scheduler we can yield to another Fiber on contended
Mutex#lock instead of blocking the entire thread.
* This also makes the behavior of Mutex consistent across CRuby, JRuby and TruffleRuby.
* [Feature #16792]
`llvm-strip-7` is a sane valid strip command that LLVM 7 ships, albeit
it does not understand `--version`. It is a bad idea to check that
option. Instead just see if the command actually strips something. A
copy of `/bin/sh` should suffice. That file must be ubiquitous.
* Fix debug documents to match Thread#to_s change (Feature #16412 ticket)
* TracePoint#inspect returns "... file:line" (Feature #16513)
* Guard older version of Ruby in Tracepoint inspection tests
* Focus on current thread only when running TracePoint inspection test
The newly added specs needs to be tagged as
:readline, otherwise they fail on Windows with
the backtrace: `ZeroDivisionError: divided by 0`.
Such issues are already being skipped on Windows.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
https://github.com/rubygems/rubygems/commit/391f860af4
Since this PR was made because we missed checking
RuboCop offenses with different flags, therefore
adding tests so that all flag combinations are
tested.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
https://github.com/rubygems/rubygems/commit/d08250efc2
The Gemfile wasn't properly put in the last commit.
As a result, Layout/EmptyLines inspected an offense
in the Gemfile.
This also fixes the spec w.r.t change in the task
default.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
https://github.com/rubygems/rubygems/commit/d1418fddd3
It simplifies things and should avoid issues like the one we had where
the master branch had a bad `.gitattributes` file and changing it on a
PR would be disregarded.
In order for this to work, we need to make sure to fetch all tags from
the repository, so that they can properly be checked out later. This
does not apply to the case of testing against `RGV=..`, since no extra
cloning is needed there.
https://github.com/rubygems/rubygems/commit/d088d936b8
ruby_core has an 'ast.rb' file that gets in the
middle and breaks this spec, so it's better we skip
this test on this workflow for now.
Also, slightly change the spec name from "run" to
"runs" and change the last assertion, it's cleaner
to check empty error.
Thanks to David Rodríguez for this!
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
https://github.com/rubygems/rubygems/commit/ba8eaa70c3
With older versions of rubocop, the dependency on
`jaro_winkler` seems to be a pain.
However, in the later versions of rubocop, this
dependency was dropped. So we only need to use
the older version for ruby2.3.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
https://github.com/rubygems/rubygems/commit/9cd87eaee3
because rubocop configuration inheritance is
messed up and when using `--ignore-parent-exclusion`,
even though the exit status is 0, the example
still fails because of the configuration issue.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
https://github.com/rubygems/rubygems/commit/3e20b2738c
The later RuboCop versions don't work with ruby2.3
so we should lock the version to what works with
ruby2.3 as we haven't dropped the support yet.
And since we're using the older version of rubocop,
also fix `Max` value of `LineLength` to 120, which
is the current standard. Without this, rubocop
will throw the line length offenses.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
https://github.com/rubygems/rubygems/commit/46d0a800a2
Previously, we were using the old syntax like:
`task :default => :spec`, but now this commit
uses the new Ruby 1.9 hash syntax.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
https://github.com/rubygems/rubygems/commit/b41d0fdb56
Using File.open without a block leaves a file reference that causes issues with file operations
commands/binstubs_spec.rb
install/gems/compact_index_spec.rb
install/gems/dependency_api_spec.rb
install/gems/standalone_spec.rb
runtime/executable_spec.rb
https://github.com/rubygems/rubygems/commit/4b9a6ca156
Previously, these were not implemented, and Object#== and #eql?
were used. This tries to check the proc internals to make sure
that procs created from separate blocks are treated as not equal,
but procs created from the same block are treated as equal, even
when the lazy proc allocation optimization is used.
Implements [Feature #14267]
This makes:
```ruby
args = [1, 2, -> {}]; foo(*args, &args.pop)
```
call `foo` with 1, 2, and the lambda, in addition to passing the
lambda as a block. This is different from the previous behavior,
which passed the lambda as a block but not as a regular argument,
which goes against the expected left-to-right evaluation order.
This is how Ruby already compiled arguments if using leading
arguments, trailing arguments, or keywords in the same call.
This works by disabling the optimization that skipped duplicating
the array during the splat (splatarray instruction argument
switches from false to true). In the above example, the splat
call duplicates the array. I've tested and cases where a
local variable or symbol are used do not duplicate the array,
so I don't expect this to decrease the performance of most Ruby
programs. However, programs such as:
```ruby
foo(*args, &bar)
```
could see a decrease in performance, if `bar` is a method call
and not a local variable.
This is not a perfect solution, there are ways to get around
this:
```ruby
args = Struct.new(:a).new([:x, :y])
def args.to_a; a; end
def args.to_proc; a.pop; ->{}; end
foo(*args, &args)
# calls foo with 1 argument (:x)
# not 2 arguments (:x and :y)
```
A perfect solution would require completely disabling the
optimization.
Fixes [Bug #16504]
Fixes [Bug #16500]
Passing paths should work in most cases, but on Windows the driver
letter is interpreted as the scheme and causes some case mismatches
because
```
irb> URI.parse("E:").to_s
=> "e:"
```
We fix this by passing file URI's instead.
https://github.com/rubygems/rubygems/commit/b6bc517628
Currently, there is no `.rubocop.yml` shipped by default.
So when a user runs `rubocop` after creating a new gem via
`bundle gem foo`, it throws a bunch of offenses.
With the default `.rubocop.yml` present, the number of those
offenses significantly reduce by 25.
Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
We have a check on an `at_exit` hook that checks that system bundler is
never loaded instead of our development copy. The check was failing in
these cases, but in a silent way because the errors were being swallowed.
This commit changes these specs to make sure they load the right
bundler.
https://github.com/rubygems/rubygems/commit/cd1c1bc297
On bundler 3, the `--deployment` flag doesn't exist, so the `bundle
install --deployment` command was failing silently and the spec was
verifying a different scenario.
Change the spec to work the same regardless of bundler's major version.
Also, from the spec description it was not apparently that a specific
case involving deployment mode was being tested, so I reworded it to
make it more apparent.
https://github.com/rubygems/rubygems/commit/3e33e2b927
On bundler 3, where the default install path is `.bundle`, these specs
were trying to change permissions of the
`.bundle/ruby/<ruby_abi_version>` folder, which didn't exist yet,so the
permission changing command was failing and the spec was not testing the
right thing.
Change the specs so that the permissions are correctly changed, by first
configuring the local path to be `.bundle` (which creates the `.bundle`
folder), and then changing permissions of the `.bundle` folder
explicitly, which exists already.
https://github.com/rubygems/rubygems/commit/2833162fb0
Bundler 3 installs by default to `.bundle`. That means that, because the
`bar` gem was not previously available at this location but as a system
gem, the initial `bundle install` was silently failing. As a
consequence, the spec was not testing the exact scenario it meant to
test.
https://github.com/rubygems/rubygems/commit/202399521c
This spec is specifically testing for the case where there's no
`Gemfile.lock` file and it's only doing the expected thing because the
`bundle install` command is silently failing. Remove the `bundle
install` to reduce confusion.
https://github.com/rubygems/rubygems/commit/ec39fbde0e
This command is failing because of the same reason that the subsequent
`bundle exec` is failing: the gemspec is invalid. The `bundle install`
here deviates the `bundle exec` focus from the test and is unnecessary:
all we need is a `Gemfile` that will trigger the `bundle exec`, so let's
create and avoid the extra command.
https://github.com/rubygems/rubygems/commit/eb83cf6cf1
It turns out that this test is checking essentially nothing useful. The
paperclip gem doesn't exist in our setup, so initial install is failing
and the test is only checking that calling `bundle check` 3 times on a
broken setup always returns the same thing.
I went to the history of this test:
* 105654a31e
* ae53be1f87
* d19f4a7b32
* 092f169d01
* 36878435b5
And have finally decided to remove it since I'm not sure changing it to
something else will lead to testing something useful and not already
tested.
https://github.com/rubygems/rubygems/commit/6184322967
This spec was broken. The second `bundle install` was silently failing.
This means that the spec was actually checking an scenario completely
different from the one that was supposed to be tested. And also a very
dummy one: that running `bundle cache` twice doesn't cache a completely
unrelated gem.
https://github.com/rubygems/rubygems/commit/f11a5d2df9
The commands these specs run were throwing warnings in bundler 2, and
failing on bundler 3, effectively testing a different scenario to what
they were supposed to.
https://github.com/rubygems/rubygems/commit/97ac1ced49
The `rails_fail` name is misleading because there's no specific reason
why such a gem would need to fail. As a matter of fact, `bundle
install`'ing a Genfile with only that dependency like the spec the
previous commit adds is not expected to fail.
https://github.com/rubygems/rubygems/commit/b947f40701
The `only_update_to_newer_versions` feature flag will enable some new
behaviour in bundler 3 (or maybe earlier if we decide to consider it a
bug fix) that prevents `bundle update` from unexpectedly downgrading
direct dependencies.
This seems reasonable, but the current implementation is adding
additional requirements for all locked dependencies, not only from the
ones in the `Gemfile`. That causes some situations where the `Gemfile`
is edited and will resolve to older versions to start failing.
This commit fixes the problem by making sure extra requirements are
added exclusively for direct dependencies in the `Gemfile`, not for all
direct dependencies in the lock file.
https://github.com/rubygems/rubygems/commit/128b4596e1
The `gem_command` helper was failing to require `support/hax.rb`, which
takes care of making sure rubygems actually picks up the right `ruby`
executable under ruby-core setup (`ENV["RUBY"]`). This caused binstubs
to be generated with a wrong shebang, and that caused `bundle exec` to
not work. The error message was pretty confusing though due to
https://bugs.ruby-lang.org/issues/16952.
I had to pin `redis-namespace` in our spec to 1.6.0 because on ruby
2.3.0 the spec no longer resolved to that version, so the cached `.gem`
file was missing there.
Previously it was failing and not recording. Also, the
`BUNDLER_SPEC_FORCE_RECORD` environment variable was forcing every
request to be recorded, including duplicated requests to the same
endpoint. That meant the recorded `versions` file would be incorrect
because it would contain the result of the last request, which would be
`304 NOT MODIFIED`.
So, to rerecord, delete cassettes and let them be recorded when needed.
* bundle gem previously ignored gem.test when passed empty -t flag,
defaulting to RSpec
* bundle gem will now ask user for test framework when passed empty -t
flag and gem.test is set to false, but will not overwrite gem.test
* thor option parsing for String types falls back to human name for nil,
so setting lazy_default to nil won't work
* c5161501e0/lib/thor/parser/options.rb (L224)
Default to Bundler.settings["gem.test"] for empty --test
Add shared examples for test framework to newgem spec
Add examples for empty --test flag to newgem spec
Simplify conditional for prompting test framework
Follow naming conventions for bundler settings
Add more descriptive test framework help text for bundle gem
Update man pages for bundler
https://github.com/rubygems/rubygems/commit/ab0785a09f
Instead, use the non-deprecated option except when specifically testing
deprecated CLI flags. In that case, pass the flag directly and limit
the specs to `bundler < 3`.
https://github.com/rubygems/rubygems/commit/3d5e186241
Some of them were passing "by chance" because they used a `bundle
install` command that failed, but the assertion was using the result of
the previous. Others were skipped on bundler 3. Now they all pass in all
versions.
https://github.com/rubygems/rubygems/commit/cedf611e11
This spec was originally written many years ago to verity gems were
properly "remembered" in the lock file. At this point, the test feels a
bit dummy since the first `bundle install` already runs on a "clean
machine".
https://github.com/rubygems/rubygems/commit/dbfefb3f5a
When bundler specs are run from a ruby tarball (ruby-core does this),
there's no git folder, so `git ls-files` fails.
Support this case by making specs rely on the list of files from the
bundler gemspec instead, and invert the spec that makes sure we ship the
right set of files.
As per the other quality specs, skip them in this case.
https://github.com/rubygems/rubygems/commit/b28d5ec931
And never recommend it inside CLI messages.
This flag represents the default behaviour of `bundle install`, and the
only reason it exists is to "override" previous `--deployment` flag
usages which were silently remembered. So it should be deprecated just
like all the other flags the rely on remembering their values across
invocations.
https://github.com/rubygems/rubygems/commit/40e50b7190
Benoit Daloze
Kazuhiro NISHIYAMA
Nobuyoshi Nakada
Gannon McGibbon
Takashi Kokubun
Marc-André Lafortune
Hiroshi SHIBATA
Marcus Stollsteimer
Jeremy Evans
卜部昌平
Radosław Bułat
Yusuke Endoh
Kazuki Tsujimoto
nicholas a. evans
Lars Kanis
Koichi Sasada
Lars Kanis
Kenta Murata
Steven Peckins
Samuel Williams
Chris Seaton
Nguyễn Quang Minh
David Rodríguez
Utkarsh Gupta
MSP-Greg
Bart de Water
Frank Lam
Yuki Nishijima
Carsten Wirth
DEVRAJ KUMAR