opal-rspec 0.8.0 → 1.0.0

data/rspec-core/upstream/DEV-README.md

@@ -1,6 +1,6 @@
 ## Set up the dev environment
 
-    git clone git://github.com/rspec/rspec-core.git
+    git clone https://github.com/rspec/rspec-core.git
     cd rspec-core
     gem install bundler
     bundle install
@@ -20,7 +20,7 @@ Or ...
     bundle install --binstubs
     bin/rspec
 
-## Customize the dev enviroment
+## Customize the dev environment
 
 The Gemfile includes the gems you'll need to be able to run specs. If you want
 to customize your dev enviroment with additional tools like guard or

data/rspec-core/upstream/DEVELOPMENT.md

@@ -0,0 +1,131 @@
+<!---
+This file was generated on 2020-12-25T18:48:30+00:00 from the rspec-dev repo.
+DO NOT modify it by hand as your changes will get lost the next time it is generated.
+-->
+
+# Development Setup
+
+Generally speaking, you only need to clone the project and install
+the dependencies with [Bundler](https://bundler.io/). You can either
+get a full RSpec development environment using
+[rspec-dev](https://github.com/rspec/rspec-dev#README) or you can
+set this project up individually.
+
+## Setting up rspec-core individually
+
+For most contributors, setting up the project individually will be simpler.
+Unless you have a specific reason to use rspec-dev, we recommend using this approach.
+
+Clone the repo:
+
+```
+$ git clone git@github.com:rspec/rspec-core.git
+```
+
+Install the dependencies using [Bundler](https://bundler.io/):
+
+```
+$ cd rspec-core
+$ bundle install
+```
+
+To minimize boot time and to ensure we don't depend upon any extra dependencies
+loaded by Bundler, our CI builds avoid loading Bundler at runtime
+by using Bundler's [`--standalone option`](https://myronmars.to/n/dev-blog/2012/03/faster-test-boot-times-with-bundler-standalone).
+While not strictly necessary (many/most of our contributors do not do this!),
+if you want to exactly reproduce our CI builds you'll want to do the same:
+
+```
+$ bundle install --standalone --binstubs
+```
+
+The `--binstubs` option creates the `bin/rspec` file that, like `bundle exec rspec`, will load
+all the versions specified in `Gemfile.lock` without loading bundler at runtime!
+
+## Using rspec-dev
+
+See the [rspec-dev README](https://github.com/rspec/rspec-dev#README)
+for setup instructions.
+
+The rspec-dev project contains many rake tasks for helping manage
+an RSpec development environment, making it easy to do things like:
+
+* Change branches across all repos
+* Update all repos with the latest code from `main`
+* Cut a new release across all repos
+* Push out updated build scripts to all repos
+
+These sorts of tasks are essential for the RSpec maintainers but will
+probably be unnecessary complexity if you're just contributing to one
+repository. If you are getting setup to make your first contribution,
+we recommend you take the simpler route of setting up rspec-core
+individually.
+
+## Gotcha: Version mismatch from sibling repos
+
+The [Gemfile](Gemfile) is designed to be flexible and support using
+the other RSpec repositories either from a local sibling directory
+(e.g. `../rspec-<subproject>`) or, if there is no such directory,
+directly from git. This generally does the "right thing", but can
+be a gotcha in some situations. For example, if you are setting up
+`rspec-core`, and you happen to have an old clone of `rspec-expectations`
+in a sibling directory, it'll be used even though it might be months or
+years out of date, which can cause confusing failures.
+
+To avoid this problem, you can either `export USE_GIT_REPOS=1` to force
+the use of `:git` dependencies instead of local dependencies, or update
+the code in the sibling directory. rspec-dev contains rake tasks to
+help you keep all repos in sync.
+
+## Extra Gems
+
+If you need additional gems for any tasks---such as `benchmark-ips` for benchmarking
+or `byebug` for debugging---you can create a `Gemfile-custom` file containing those
+gem declarations. The `Gemfile` evaluates that file if it exists, and it is git-ignored.
+
+# Running the build
+
+The [Travis CI build](https://travis-ci.org/rspec/rspec-core)
+runs many verification steps to prevent regressions and
+ensure high-quality code. To run the Travis build locally, run:
+
+```
+$ script/run_build
+```
+
+See [build detail](BUILD_DETAIL.md) for more detail.
+
+# What to Expect
+
+To ensure high, uniform code quality, all code changes (including
+changes from the maintainers!) are subject to a pull request code
+review. We'll often ask for clarification or suggest alternate ways
+to do things. Our code reviews are intended to be a two-way
+conversation.
+
+Here's a short, non-exhaustive checklist of things we typically ask contributors to do before PRs are ready to merge. It can help get your PR merged faster if you do these in advance!
+
+- [ ] New behavior is covered by tests and all tests are passing.
+- [ ] No Ruby warnings are issued by your changes.
+- [ ] Documentation reflects changes and renders as intended.
+- [ ] RuboCop passes (e.g. `bundle exec rubocop lib`).
+- [ ] Commits are squashed into a reasonable number of logical changesets that tell an easy-to-follow story.
+- [ ] No changelog entry is necessary (we'll add it as part of the merge process!)
+
+# Adding Docs
+
+RSpec uses [YARD](https://yardoc.org/) for its API documentation. To
+ensure the docs render well, we recommend running a YARD server and
+viewing your edits in a browser.
+
+To run a YARD server:
+
+```
+$ bundle exec yard server --reload
+
+# or, if you installed your bundle with `--standalone --binstubs`:
+
+$ bin/yard server --reload
+```
+
+Then navigate to `localhost:8808` to view the rendered docs.

data/rspec-core/upstream/Filtering.md

@@ -0,0 +1,173 @@
+# Filtering
+
+RSpec supports filtering examples and example groups in multiple ways,
+allowing you to run a targeted subset of your suite that you are
+currently interested in.
+
+## Filtering by Tag
+
+Examples and groups can be filtered by matching tags declared on
+the command line or options files, or filters declared via
+`RSpec.configure`, with hash key/values submitted within example group
+and/or example declarations. For example, given this declaration:
+
+``` ruby
+RSpec.describe Thing, :awesome => true do
+  it "does something" do
+    # ...
+  end
+end
+```
+
+That group (or any other with `:awesome => true`) would be filtered in
+with any of the following commands:
+
+    rspec --tag awesome:true
+    rspec --tag awesome
+    rspec -t awesome:true
+    rspec -t awesome
+
+Prefixing the tag names with `~` negates the tags, thus excluding this
+group with any of:
+
+    rspec --tag ~awesome:true
+    rspec --tag ~awesome
+    rspec -t ~awesome:true
+    rspec -t ~awesome
+
+## Filtering by Example description
+
+RSpec provides the `--example` (short form: `-e`) option to allow you to
+select examples or groups by their description. All loaded examples
+whose full description (computed based on the description of the example
+plus that of all ancestor groups) contains the provided argument will be
+executed.
+
+    rspec --example "Homepage when logged in"
+    rspec -e "Homepage when logged in"
+
+You can specify this option multiple times to select multiple sets of examples:
+
+    rspec -e "Homepage when logged in" -e "User"
+
+Note that RSpec will load all spec files in these situations, which can
+incur considerable start-up costs (particularly for Rails apps). If you
+know that the examples you are targeting are in particular files, you can
+also pass the file or directory name so that RSpec loads only those spec
+files, speeding things up:
+
+    rspec spec/homepage_spec.rb -e "Homepage when logged in"
+    rspec -e "Homepage when logged in" spec/homepage_spec.rb
+
+Note also that description-less examples that have generated descriptions
+(typical when using the one-liner syntax) cannot be directly filtered with
+this option, because it is necessary to execute the example to generate the
+description, so RSpec is unable to use the not-yet-generated description to
+decide whether or not to execute an example. You can, of course, pass part
+of a group's description to select all examples defined in the group
+(including those that have no description).
+
+## Filtering by Example Location
+
+Examples and groups can be selected from the command line by passing the
+file and line number where they are defined, separated by a colon:
+
+    rspec spec/homepage_spec.rb:14 spec/widgets_spec.rb:40 spec/users_spec.rb
+
+This command would run the example or group defined on line 14 of
+`spec/homepage_spec.rb`, the example or group defined on line 40 of
+`spec/widgets_spec.rb`, and all examples and groups defined in
+`spec/users_spec.rb`.
+
+If there is no example or group defined at the specified line, RSpec
+will run the last example or group defined before the line.
+
+## Focusing
+
+RSpec supports configuration options that make it easy to select
+examples by temporarily tweaking them. In your `spec_helper.rb` (or
+a similar file), put this configuration:
+
+``` ruby
+RSpec.configure do |config|
+  config.filter_run_when_matching :focus
+end
+```
+
+This configuration is generated for you by `rspec --init` in the
+commented-out section of recommendations. With that in place, you
+can tag any example group or example with `:focus` metadata to
+select it:
+
+``` ruby
+it "does something" do
+# becomes...
+it "does something", :focus do
+```
+
+RSpec also ships with aliases of the common example group definition
+methods (`describe`, `context`) and example methods (`it`, `specify`,
+`example`) with an `f` prefix that automatically includes `:focus =>
+true` metadata, allowing you to easily change `it` to `fit` (think
+"focused it"), `describe` to `fdescribe`, etc in order to temporarily
+focus them.
+
+## Options files and command line overrides
+
+Command line option declarations can be stored in `.rspec`, `~/.rspec`,
+`$XDG_CONFIG_HOME/rspec/options` or a custom options file. This is useful for
+storing defaults. For example, let's say you've got some slow specs that you
+want to suppress most of the time. You can tag them like this:
+
+``` ruby
+RSpec.describe Something, :slow => true do
+```
+
+And then store this in `.rspec`:
+
+    --tag ~slow:true
+
+Now when you run `rspec`, that group will be excluded.
+
+## Overriding
+
+Of course, you probably want to run them sometimes, so you can override
+this tag on the command line like this:
+
+    rspec --tag slow:true
+
+## Precedence
+
+Location and description filters have priority over tag filters since
+they express a desire by the user to run specific examples. Thus, you
+could specify a location or description at the command line to run an
+example or example group that would normally be excluded due to a
+`:slow` tag if you were using the above configuration.
+
+## RSpec.configure
+
+You can also store default tags with `RSpec.configure`. We use `tag` on
+the command line (and in options files like `.rspec`), but for historical
+reasons we use the term `filter` in `RSpec.configure`:
+
+``` ruby
+RSpec.configure do |c|
+  c.filter_run_including :foo => :bar
+  c.filter_run_excluding :foo => :bar
+end
+```
+
+These declarations can also be overridden from the command line.
+
+## Silencing filter announcements
+
+By default, RSpec will print a message before your specs run indicating what filters are configured, for instance, it might print "Run options: include {:focus=>true}" if you set `config.filter_run_including :focus => true`.
+
+If you wish to prevent those messages from appearing in your spec output, you can set the `silence_filter_announcements` config setting to `true` like this:
+
+``` ruby
+RSpec.configure do |c|
+  c.filter_run_including :foo => :bar
+  c.silence_filter_announcements = true
+end
+```

data/rspec-core/upstream/Gemfile

@@ -8,27 +8,96 @@ branch = File.read(File.expand_path("../maintenance-branch", __FILE__)).chomp
   if File.exist?(library_path) && !ENV['USE_GIT_REPOS']
     gem lib, :path => library_path
   else
-    gem lib, :git => "git://github.com/rspec/#{lib}.git", :branch => branch
+    gem lib, :git => "https://github.com/rspec/#{lib}.git", :branch => branch
   end
 end
 
-gem 'yard', '~> 0.8.7', :require => false
+if RUBY_VERSION < '1.9.3'
+  gem 'rake', '< 11.0.0' # rake 11 requires Ruby 1.9.3 or later
+elsif RUBY_VERSION < '2.0.0'
+  gem 'rake', '< 12.0.0' # rake 12 requires Ruby 2.0.0 or later
+elsif RUBY_VERSION < '2.2.0'
+  gem 'rake', '< 13.0.0' # rake 13 requires Ruby 2.2.0 or later
+else
+  gem 'rake', '>= 13.0.0'
+end
+
+if ENV['DIFF_LCS_VERSION']
+  gem 'diff-lcs', ENV['DIFF_LCS_VERSION']
+else
+  gem 'diff-lcs', '~> 1.4', '>= 1.4.3'
+end
 
 ### deps for rdoc.info
 group :documentation do
-  gem 'redcarpet',     '2.1.1', :platform => :mri
-  gem 'github-markup', '0.7.2', :platform => :mri
+  gem 'redcarpet', :platform => :mri
+  gem 'github-markup', :platform => :mri
+  gem 'yard', '~> 0.9.24', :require => false
+end
+
+if RUBY_VERSION < '2.0.0'
+  gem 'thor', '< 1.0.0'
+else
+  gem 'thor', '> 1.0.0'
 end
 
-platforms :ruby_18, :jruby do
-  gem 'json'
+if RUBY_VERSION < '2.0.0' || RUBY_ENGINE == 'java'
+  gem 'json', '< 2.0.0'
+else
+  gem 'json', '> 2.3.0'
+end
+
+if RUBY_VERSION < '2.2.0' && !!(RbConfig::CONFIG['host_os'] =~ /cygwin|mswin|mingw|bccwin|wince|emx/)
+  gem 'ffi', '< 1.10'
+elsif RUBY_VERSION < '2.4.0' && !!(RbConfig::CONFIG['host_os'] =~ /cygwin|mswin|mingw|bccwin|wince|emx/)
+  gem 'ffi', '< 1.15'
+elsif RUBY_VERSION < '2.0'
+  gem 'ffi', '< 1.9.19' # ffi dropped Ruby 1.8 support in 1.9.19
+elsif RUBY_VERSION < '2.3.0'
+  gem 'ffi', '~> 1.12.0'
+else
+  gem 'ffi', '~> 1.15.0'
+end
+
+if RUBY_VERSION < '2.3.0' && !!(RbConfig::CONFIG['host_os'] =~ /cygwin|mswin|mingw|bccwin|wince|emx/)
+  gem "childprocess", "< 1.0.0"
+elsif RUBY_VERSION < '2.0.0'
+  gem "childprocess", "< 1.0.0"
+elsif RUBY_VERSION < '2.3.0'
+  gem "childprocess", "< 3.0.0"
+else
+  gem "childprocess", ">= 3.0.0"
 end
 
 platforms :jruby do
-  gem "jruby-openssl"
+  if RUBY_VERSION < '1.9.0'
+    # Pin jruby-openssl on older J Ruby
+    gem "jruby-openssl", "< 0.10.0"
+  else
+    gem "jruby-openssl"
+  end
+end
+
+group :coverage do
+  gem 'simplecov', '~> 0.8'
+end
+
+# No need to run rubocop on earlier versions
+if RUBY_VERSION >= '2.4' && RUBY_ENGINE == 'ruby'
+  gem "rubocop", "~> 1.0", "< 1.12"
+end
+
+gem 'test-unit', '~> 3.0' if RUBY_VERSION.to_f >= 2.2
+
+# Version 5.12 of minitest requires Ruby 2.4
+if RUBY_VERSION < '2.4.0'
+  gem 'minitest', '< 5.12.0'
+end
+
+if RUBY_VERSION < '2.0.0'
+  gem 'cucumber', "<= 1.3.22"
 end
 
-gem 'simplecov', '~> 0.8'
-gem 'rubocop', "~> 0.23.0", :platform => [:ruby_19, :ruby_20, :ruby_21]
+gem 'contracts', '< 0.16' if RUBY_VERSION < '1.9.0'
 
 eval File.read('Gemfile-custom') if File.exist?('Gemfile-custom')

data/rspec-core/upstream/ISSUE_TEMPLATE.md

@@ -0,0 +1,24 @@
+### Subject of the issue
+<!---
+Describe your issue here.
+-->
+
+### Your environment
+* Ruby version:
+* rspec-core version:
+
+### Steps to reproduce
+<!---
+Tell us how to reproduce this issue. Please provide a working demo, you can use
+this [templates](REPORT_TEMPLATE.md) as a base.
+-->
+
+### Expected behavior
+<!---
+Tell us what should happen.
+-->
+
+### Actual behavior
+<!---
+Tell us what happens instead.
+-->

data/rspec-core/upstream/{License.txt → LICENSE.md}

@@ -1,9 +1,10 @@
-(The MIT License)
+The MIT License (MIT)
+=====================
 
-Copyright (c) 2012 Chad Humphries, David Chelimsky, Myron Marston
-Copyright (c) 2009 Chad Humphries, David Chelimsky
-Copyright (c) 2006 David Chelimsky, The RSpec Development Team
-Copyright (c) 2005 Steven Baker
+* Copyright © 2012 Chad Humphries, David Chelimsky, Myron Marston
+* Copyright © 2009 Chad Humphries, David Chelimsky
+* Copyright © 2006 David Chelimsky, The RSpec Development Team
+* Copyright © 2005 Steven Baker
 
 Permission is hereby granted, free of charge, to any person obtaining
 a copy of this software and associated documentation files (the