Calling `tokens_to_s` gets an error if `token_stream` is nil:
```
undefined method `compact' for nil:NilClass (NoMethodError)
```
So, fall back to an empty array if `@token_stream` is nil.
452e4a2600
test/runner.rb and tool/lib/test/unit/parallel.rb must use the same
settings. However, some settings were copied and pasted, while some were
added only to test/runner.rb.
This changeset creates tool/test/init.rb for all settings of test-unit,
which is loaded not only by test/runner.rb but also
tool/lib/test/unit/parallel.rb.
Background: the GEM_HOME environment variable was removed in
test/runner.rb, which prohibit `require "rake"` (note that rake is a
bundled gem). However the parallel mode didn't refrect this setting,
i.e., `require "rake"` was allowed.
This leads to an inconsistency, which actually affected a test test
defines s test class *only when* `require "rake"` is successful.
(test/rubygems/test_gem_package_task.rb)
1851105563 (step):8:1714
```
/home/runner/work/ruby/ruby/src/tool/lib/test/unit.rb:729:in `const_get': uninitialized constant TestGemPackageTask (NameError)
suites.map! {|r| ::Object.const_get(r[:testcase])}
^^^^^^^^^^
```
* Revert "Fixup da2c2931a6"
This reverts commit e1978a905a.
* Revert "Skip Type completion tests related with IRB::VERSION"
This reverts commit da2c2931a6.
* require irb/version to test IRB::VERSION
---------
Co-authored-by: tompng <tomoyapenguin@gmail.com>
librubyparser was an artifact of the prototype that was initially
named ruby-parser. Instead, this renames it to libprism to be
consistent with the actual name.
8600b06811
Because the lex mode may be freed when popped, we need to store off
this value for dedentation.
64007322f5
Co-authored-by: Kevin Newton <kddnewton@gmail.com>
This test suite is flaky on CI, because the test asserts events from
finalizers also. Tracing events from finalizers is not deterministic
and is not a part of test interests, so this commit changes the test
to assert only events originated from the test file itself.
Context: https://github.com/ivoanjo/gvl-tracing/pull/4
Some hooks may want to collect data on a per thread basis.
Right now the only way to identify the concerned thread is to
use `rb_nativethread_self()` or similar, but even then because
of the thread cache or MaNy, two distinct Ruby threads may report
the same native thread id.
By passing `thread->self`, hooks can use it as a key to store
the metadata.
NB: Most hooks are executed outside the GVL, so such data collection
need to use a thread-safe data-structure, and shouldn't use the
reference in other ways from inside the hook.
They must also either pin that value or handle compaction.
Resetting `@default_specifications_dir` to `nil` means that the
`Gem.default_specifications_dir` needs to be invoked. However, given
that this method might be overridden by operating_system.rb and similar,
this might lead to various test failures. Providing the default value
makes the issues go away.
59626cb650
Original output:
~~~
Failure: test_realworld_upgraded_default_gem(TestGemRequire): <false> is not true.
/mnt/test/rubygems/test_require.rb:474:in `test_realworld_upgraded_default_gem'
471: File.write(path, code)
472:
473: output = Gem::Util.popen({ "GEM_HOME" => @gemhome }, *ruby_with_rubygems_in_load_path, path).strip
=> 474: assert $?.success?
475: refute_empty output
476: assert_equal "999.99.9", output.lines[0].chomp
477: # Make sure only files from the newer json gem are loaded, and no files from the default json gem
~~~
New output:
~~~
Failure: test_realworld_upgraded_default_gem(TestGemRequire)
/mnt/test/rubygems/test_require.rb:475:in `test_realworld_upgraded_default_gem'
472:
473: output = Gem::Util.popen({ "GEM_HOME" => @gemhome }, *ruby_with_rubygems_in_load_path, path).strip
474: refute_empty output
=> 475: assert_equal "999.99.9", output.lines[0].chomp
476: # Make sure only files from the newer json gem are loaded, and no files from the default json gem
477: assert_equal ["#{@gemhome}/gems/json-999.99.9/lib/json.rb"], output.lines.grep(%r{/gems/json-}).map(&:chomp)
478: assert $?.success?
<"999.99.9"> expected but was
<"/mnt/tmp/test_rubygems_20231110-36663-of405r/test_realworld_upgraded_default_gem.rb:3:in `<main>': undefined method `version' for nil:NilClass (NoMethodError)">
diff:
? 999 .99.9
? /mnt/tmp/test_rubygems_20231110-36663-of405r/test_realworld_upgraded_default_gem rb:3:in `<main>': undefined method `version' for nil:NilClass (NoMethodError)
? ??? ????
~~~
It is more valuable to check the command output then the error code. If
the command fails for some reason, the output probably contains some
detail, while checking the return code tells not much.
b76062e852
Originally, the failed test case reported following error:
~~~
Failure: test_gem_exec_gem_uninstall(TestGemCommandsExecCommand):
<""> was expected to include
<"Successfully uninstalled a-2\n">.
/mnt/test/rubygems/test_gem_commands_exec_command.rb:742:in `block in test_gem_exec_gem_uninstall'
739:
740: # assert_empty @ui.error
741: refute_includes @ui.output, "running gem exec with"
=> 742: assert_includes @ui.output, "Successfully uninstalled a-2\n"
743:
744: invoke "--verbose", "gem", "uninstall", "b"
745: assert_includes @ui.output, "Successfully uninstalled b-2\n"
/mnt/lib/rubygems/user_interaction.rb:46:in `use_ui'
/mnt/lib/rubygems/user_interaction.rb:69:in `use_ui'
/mnt/test/rubygems/test_gem_commands_exec_command.rb:726:in `test_gem_exec_gem_uninstall'
~~~
This does not tell much. Empty string is more often good sign, but not
in this case. However, checking error output first helps with
understanding possible issue:
~~~
Failure: test_gem_exec_gem_uninstall(TestGemCommandsExecCommand):
<"ERROR: While executing gem ... (Gem::FilePermissionError)\n" +
" You don't have write permissions for the /builddir/bin directory.\n" +
"\t/mnt/lib/rubygems/uninstaller.rb:213:in `remove_executables'\n" +
... snip ...
/mnt/test/rubygems/test_gem_commands_exec_command.rb:740:in `block in test_gem_exec_gem_uninstall'
737: nil
738: end
739:
=> 740: assert_empty @ui.error
741: refute_includes @ui.output, "running gem exec with"
742: assert_includes @ui.output, "Successfully uninstalled a-2\n"
743:
/mnt/lib/rubygems/user_interaction.rb:46:in `use_ui'
/mnt/lib/rubygems/user_interaction.rb:69:in `use_ui'
/mnt/test/rubygems/test_gem_commands_exec_command.rb:726:in `test_gem_exec_gem_uninstall'
~~~
BTW this issue is caused by operating_system.rb overriding
`Gem.operating_system_defaults` method and explicitly adding `--bindir`
option.
d98e36bbe7
