1). Remove `--threadsafe` CLI option. In general, we don't expose every config option via the CLI. We want to make it easy for users to run `rspec --help` and find the options that they are commonly going to want to customize for a particular CLI run. I don't think `--threadsafe` is one of those -- it's more something that'll be turned off globally for the project or not touched at all, and as such, it adds noise to the `--help` output to include it. 2). Extract Mutex class into its own file. - Remove need for use of `MUTEX` over `Mutex`. - No reason to force Ruby to parse the code for 1.8.7 Mutex implementation on other Rubies. 3). Remove threadsafe scenario. A note about threadsafey is sufficient for the docs. Having a full threadsafety example spec in the scenario is more detail than users are likely to want to read.
…thod) in the same example group." This reverts the lib and spec pieces of e072e53. The warning is overzealous. After upgrading a project to RSpec HEAD, I got spammed with tons of warnings of situations that weren't actually problematic. For example, it's common to define a `let` in a shared context that provides a default value, and than to purposefully override that in a host group where the shared context is included. We should'nt warn in such a situation, but this did warn. See #1903 for the original code this reverts.
`system` returns a boolean value to indicate success/failure, but the use of `failure_message` was in a `rescue` block that never got executed. It appears this has been broken since ea70e4e. Before that commit, we used `Rake::FileUtilsExt#ruby`, which does indicate failure by raising an error (and thus the `rescue` was correct). In ea70e4e, we switched to using `system` and the rescue was left in place but never got hit anymore. The lack of test coverage here is why we never noticed, so I addressed that as well.