This reverts commit e63e844bc7444c6a489fcde0dc7011c6c4807edd.
It was introduced to resolve some failing tests at the cost of making
the intention of the spec much less clear.
Thanks to the previous fixes we have added to this spec, we can revert
that patch now.
https://github.com/bundler/bundler/commit/b29a40820f
Previously it was being installed to the :bundle_path
(`/tmp/bundled_app/.bundle`), but the `bundle` helper uses the
`system_gem_path("bin/bundle")`. That means the first `bundle install`in
the spec was actually failing, but not affecting the test status because
of not being called as `bundle!`.
https://github.com/bundler/bundler/commit/ad75f75539
Previously, if bundler-2.1.0.pre.1 would be installed globally, it would
fail. Now we force that a locally installed version of bundler is used,
so it always passed regardless of which bundler is installed globally.
https://github.com/bundler/bundler/commit/764d8e8fd1
When Gemfile would specify path sources as relative paths starting with
"./", the lockfile would have inconsistent order on `bundle install` and
`bundle update`.
https://github.com/bundler/bundler/commit/c7532ced89
The full scan of the C source code (`@content.scan`) is very slow.
The old code invokes the scan six times in `do_classes` and
`do_modules`.
This change integrates the six scans into one by merging the regexps.
The integrated regexp is a bit hard to maintain, but the speed up is
significant: approx. 30 sec -> 20 sec in Ruby's `make rdoc`.
In addition, this change omits `do_boot_defclass` unless the file name
is `class.c`. `boot_defclass` is too specific to Ruby's source code, so
RDoc should handle it as a special case.
Before this change:
TOTAL (pct) SAMPLES (pct) FRAME
858 (13.6%) 858 (13.6%) (garbage collection)
292 (4.6%) 264 (4.2%) RDoc::Parser::C#do_define_class
263 (4.2%) 250 (3.9%) RDoc::Parser::C#do_define_module
275 (4.3%) 241 (3.8%) RDoc::Parser::C#do_define_class_under
248 (3.9%) 237 (3.7%) RDoc::Parser::C#do_define_module_under
234 (3.7%) 234 (3.7%) RDoc::Parser::C#gen_body_table
219 (3.5%) 219 (3.5%) Ripper::Lexer#state_obj
217 (3.4%) 216 (3.4%) RDoc::Parser::C#do_struct_define_without_accessor
205 (3.2%) 205 (3.2%) RDoc::Parser::C#do_boot_defclass
205 (3.2%) 205 (3.2%) RDoc::Parser::C#do_singleton_class
The six methods take approx. 22.2%.
`do_define_class` (4.2%) + `do_define_class_under` (3.8%) +
`do_define_module` (3,9$) + `do_define_module_under` (3.7%) +
`do_struct_define_without_accessor` (3.4%) + `do_singleton_class` (3.2%)
After this change, the methods are integrated to `do_classes_and_modules`
which takes only 5.8%.
TOTAL (pct) SAMPLES (pct) FRAME
812 (16.7%) 812 (16.7%) (garbage collection)
355 (7.3%) 284 (5.8%) RDoc::Parser::C#do_classes_and_modules
225 (4.6%) 225 (4.6%) RDoc::Parser::C#gen_body_table
429 (8.8%) 210 (4.3%) RDoc::Parser::RubyTools#get_tk
208 (4.3%) 208 (4.3%) RDoc::TokenStream#add_tokens
The old version of `add_tokens` accepts an array of tokens, and
multiple arguments of tokens by using `Array#flatten`.
And `add_token` was an alias to `add_tokens`.
I think it is unnecessarily flexible; in fact, all callsites of
`add_tokens` (except test) passes only an array of tokens.
And the code created a lot of temporal arrays.
This change makes `add_tokens` accept only one array of tokens,
and does `add_token` accept one token. It is a bit faster (about
1 second in Ruby's `make rdoc`), and it ls also cleaner in my point of
view.
This change introduces a wrapper of StringScanner that is aware of the
current position (column and lineno).
It has two advantages: faster and more modular.
The old code frequently runs `@input.byteslice(0, byte_offset).length`
to get the current position, but it was painfully slow. This change
keeps track of the position at each scan, which reduces about half of
time of "Generating RI format into ..." in Ruby's `make rdoc`
(5.5 sec -> 3.0 sec).
And the old code used four instance variables (`@input`, `@line`,
`@line_pos`, and `@s`) to track the position. This change factors them
out into MyStringScanner, so now only one variable (`@s`) is needed.
When we use `define_method` and `define_singleton_method`,
if we supply block parameters to a block then a generated
method has corresponding parameters.
However, the doc doesn't mention it, so this info has been added.
My previous attempt to correct #2068 apparently failed and the confusing
wording ("instances") was merged into trunk instead.
This should address any potential confusion.
