The gem doesn't even install on old rubies, but since the gemspec claims
it's supported, `gem install pathname` will try to install it and print
an error.
This commit doesn't fix the above issue. The only way to fix it would be
to restore support and release a new version that actually supports old
rubies. However, such a change has been proposed and ignored for a long
time.
So this issue proposes to leave that broken but at least bring the
gemspec manifest and the CI matrix in sync to hopefully avoid this issue
from happening again in the future.
https://github.com/ruby/pathname/commit/3ee010b538
Currently when calling any of the "FileUtils" methods on pathname `require` is called every time even though that library might already be loaded. This is slow:
We can speed it up by either checking first if the constant is already defined, or by using autoload.
Using defined speeds up the action by about 300x and using autoload is about twice as fast as that (600x faster than current require method).
I'm proposing we use autoload:
```ruby
require 'benchmark/ips'
Benchmark.ips do |x|
autoload(:FileUtils, "fileutils")
x.report("require") { require 'fileutils' }
x.report("defined") { require 'fileutils' unless defined?(FileUtils) }
x.report("autoload") { FileUtils }
x.compare!
end
# Warming up --------------------------------------
# require 3.624k i/100ms
# defined 1.465M i/100ms
# autoload 2.320M i/100ms
# Calculating -------------------------------------
# require 36.282k (± 2.4%) i/s - 184.824k in 5.097153s
# defined 14.539M (± 2.0%) i/s - 73.260M in 5.041161s
# autoload 23.100M (± 1.9%) i/s - 115.993M in 5.023271s
# Comparison:
# autoload: 23099779.2 i/s
# defined: 14538544.9 i/s - 1.59x (± 0.00) slower
# require: 36282.3 i/s - 636.67x (± 0.00) slower
```
Because this autoload is scoped to Pathname it will not change the behavior of existing programs that are not expecting FileUtils to be loaded yet:
```
ruby -rpathname -e "class Pathname; autoload(:FileUtils, 'fileutils'); end; puts FileUtils.exist?"
Traceback (most recent call last):
-e:1:in `<main>': uninitialized constant FileUtils (NameError)
```
This method is explicitly documented to not access the filesystem,
and the only way to get the correct behavior for a case where the
filesystem's case sensitivity differs from the operating system
default would be to access the filesystem.
Fixes [Bug #15417]
This removes the related tests, and puts the related specs behind
version guards. This affects all code in lib, including some
libraries that may want to support older versions of Ruby.
Cfuncs that use rb_scan_args with the : entry suffer similar keyword
argument separation issues that Ruby methods suffer if the cfuncs
accept optional or variable arguments.
This makes the following changes to : handling.
* Treats as **kw, prompting keyword argument separation warnings
if called with a positional hash.
* Do not look for an option hash if empty keywords are provided.
For backwards compatibility, treat an empty keyword splat as a empty
mandatory positional hash argument, but emit a a warning, as this
behavior will be removed in Ruby 3. The argument number check
needs to be moved lower so it can correctly handle an empty
positional argument being added.
* If the last argument is nil and it is necessary to treat it as an option
hash in order to make sure all arguments are processed, continue to
treat the last argument as the option hash. Emit a warning in this case,
as this behavior will be removed in Ruby 3.
* If splitting the keyword hash into two hashes, issue a warning, as we
will not be splitting hashes in Ruby 3.
* If the keyword argument is required to fill a mandatory positional
argument, continue to do so, but emit a warning as this behavior will
be going away in Ruby 3.
* If keyword arguments are provided and the last argument is not a hash,
that indicates something wrong. This can happen if a cfunc is calling
rb_scan_args multiple times, and providing arguments that were not
passed to it from Ruby. Callers need to switch to the new
rb_scan_args_kw function, which allows passing of whether keywords
were provided.
This commit fixes all warnings caused by the changes above.
It switches some function calls to *_kw versions with appropriate
kw_splat flags. If delegating arguments, RB_PASS_CALLED_KEYWORDS
is used. If creating new arguments, RB_PASS_KEYWORDS is used if
the last argument is a hash to be treated as keywords.
In open_key_args in io.c, use rb_scan_args_kw.
In this case, the arguments provided come from another C
function, not Ruby. The last argument may or may not be a hash,
so we can't set keyword argument mode. However, if it is a
hash, we don't want to warn when treating it as keywords.
In Ruby files, make sure to appropriately use keyword splats
or literal keywords when calling Cfuncs that now issue keyword
argument separation warnings through rb_scan_args. Also, make
sure not to pass nil in place of an option hash.
Work around Kernel#warn warnings due to problems in the Rubygems
override of the method. There is an open pull request to fix
these issues in Rubygems, but part of the Rubygems tests for
their override fail on ruby-head due to rb_scan_args not
recognizing empty keyword splats, which this commit fixes.
Implementation wise, adding rb_scan_args_kw is kind of a pain,
because rb_scan_args takes a variable number of arguments.
In order to not duplicate all the code, the function internals need
to be split into two functions taking a va_list, and to avoid passing
in a ton of arguments, a single struct argument is used to handle
the variables previously local to the function.
This is how Kernel#{Array,String,Float,Integer,Hash,Rational} work.
BigDecimal and Complex instances are always frozen, so this should
not cause backwards compatibility issues for those. Pathname
instances are not frozen, so potentially this could cause backwards
compatibility issues by not returning a new object.
Based on a patch from Joshua Ballanco, some minor changes by me.
Fixes [Bug #7522]
* file.c (rb_file_s_birthtime): export for pathname to check if
birthtime is supported.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67097 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Moving public headers was 12-years ago, no depend files would
expect ruby.h in the top source directory now.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@67033 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
I reconsidered because simpler code would have better maintainablity.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66431 b2dd03c8-39d4-4d8f-98ff-823fe69b080e