Deep-Software-Analytics/SweSetupBench-lite huggingface dataset:
Repository: mochajs/mocha

Problem statement:
🐛 Bug: Errorhandling fails when node:module registered errors are thrown
### Bug Report Checklist

- [X] I have read and agree to Mocha's [Code of Conduct](https://github.com/mochajs/mocha/blob/master/.github/CODE_OF_CONDUCT.md) and [Contributing Guidelines](https://github.com/mochajs/mocha/blob/master/.github/CONTRIBUTING.md)
- [X] I have searched for [related issues](https://github.com/mochajs/mocha/issues?q=is%3Aissue) and [issues with the `faq` label](https://github.com/mochajs/mocha/issues?utf8=%E2%9C%93&q=is%3Aissue%20label%3Afaq%20), but none matched my issue.
- [X] I have 'smoke tested' the code to be tested by running it outside the real test suite to get a better sense of whether the problem is in the code under test, my usage of Mocha, or Mocha itself.
- [X] I want to provide a PR to resolve this

### Expected

When running a test that throws a null error i expect to get information about what happened and the errorhandler to give useful output.

### Actual

When an null error is thrown when running the tests the output from the mocha script is the program option list and a line:
`✖ ERROR: null`

### Minimal, Reproducible Example

I created a PR for this error - thinking this was only applicable for Typescript errors, but as stated in the PR: all null errors it will cause this to happen.

Nevertheless, the example created for the original PR shows the error:
https://github.com/stalet/mocha-typescript-testproject

### Versions

10.2.0

### Additional Info

This error was reported as part of PR #5074 - but since it's not just applicable for Typescript errors the PR was closed - and I am opening this issue instead.


Hints:

Patch:
diff --git a/lib/cli/run.js b/lib/cli/run.js
--- a/lib/cli/run.js
+++ b/lib/cli/run.js
@@ -369,7 +369,7 @@ exports.handler = async function (argv) {
   try {
     await runMocha(mocha, argv);
   } catch (err) {
-    console.error('\n' + (err.stack || `Error: ${err.message || err}`));
+    console.error('\n Exception during run:', err);
     process.exit(1);
   }
 };


Test patch:
diff --git a/test/integration/reporters.spec.js b/test/integration/reporters.spec.js
--- a/test/integration/reporters.spec.js
+++ b/test/integration/reporters.spec.js
@@ -211,7 +211,7 @@ describe('reporters', function () {
             return;
           }
 
-          var pattern = `^Error: invalid or unsupported TAP version: "${invalidTapVersion}"`;
+          var pattern = `Error: invalid or unsupported TAP version: "${invalidTapVersion}"`;
           expect(res, 'to satisfy', {
             code: 1,
             output: new RegExp(pattern, 'm')
Repository: mochajs/mocha

Problem statement:
Add support for comment lines in Mocha options file
### Prerequisites

- [x] Checked that your issue hasn't already been filed by cross-referencing [issues with the `faq` label](https://github.com/mochajs/mocha/issues?utf8=%E2%9C%93&q=is%3Aissue%20label%3Afaq%20)

Related proposals:
#2587
#2870 
#2963 

### Description

Add support for Beginning-of-Line (BOL) comments to "mocha.opts". As the file has far more in common with shell scripts (as it contains various Mocha cmdline arguments) than JavaScript tests, the comment character would be the hash ('#') character. Inline comments will **not** be supported.

### Rationale

No current support for comment lines exists for "mocha.opts". With other related upcoming proposals for processing this file, the ability to document this file becomes more important than ever. Believe the other proposals got bogged down trying to do too much, arguing over more advanced features rather than providing the basics. As Larry would say, ["Git 'Er Done"](https://www.youtube.com/watch?v=xfbQ81SJn8s).



Hints:

Patch:
diff --git a/bin/options.js b/bin/options.js
--- a/bin/options.js
+++ b/bin/options.js
@@ -32,6 +32,7 @@ function getOptions() {
   try {
     const opts = fs
       .readFileSync(optsPath, 'utf8')
+      .replace(/^#.*$/gm, '')
       .replace(/\\\s/g, '%20')
       .split(/\s/)
       .filter(Boolean)


Test patch:
diff --git a/test/integration/regression.spec.js b/test/integration/regression.spec.js
--- a/test/integration/regression.spec.js
+++ b/test/integration/regression.spec.js
@@ -32,6 +32,7 @@ describe('regressions', function() {
     var processArgv = process.argv.join('');
     var mochaOpts = fs
       .readFileSync(path.join(__dirname, '..', 'mocha.opts'), 'utf-8')
+      .replace(/^#.*$/gm, '')
       .split(/[\s]+/)
       .join('');
     assert.notEqual(
diff --git a/test/mocha.opts b/test/mocha.opts
--- a/test/mocha.opts
+++ b/test/mocha.opts
@@ -1,6 +1,11 @@
+###
+### mocha.opts
+###
+
 --require ./test/setup
 --ui bdd
 --globals okGlobalA,okGlobalB
 --globals okGlobalC
 --globals callback*
 --timeout 200
+
Repository: mochajs/mocha

Problem statement:
3.x: url encoded grep not properly unescaped
HI,

Running `3.0.2`, in browser tests `grep` argument 
won t work properly with an url like `http://localhost:3000/test/?grep=CustomAjaxTable+should+update+header+class+on+sortable+header+click`
It will work if the spaces are not replaced by `+` sign,
`http://localhost:3000/test/?grep=CustomAjaxTable should update header class on sortable header click`

It s a bit of problem, my test need to manage url parameters, it uses the URL / URLSearchParams API (https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams), and it seems like to encode it in such way mocha won t follow up.

I gone through the changelog, look likes it was not fixed since the reported version.
3.x: url encoded grep not properly unescaped
HI,

Running `3.0.2`, in browser tests `grep` argument 
won t work properly with an url like `http://localhost:3000/test/?grep=CustomAjaxTable+should+update+header+class+on+sortable+header+click`
It will work if the spaces are not replaced by `+` sign,
`http://localhost:3000/test/?grep=CustomAjaxTable should update header class on sortable header click`

It s a bit of problem, my test need to manage url parameters, it uses the URL / URLSearchParams API (https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams), and it seems like to encode it in such way mocha won t follow up.

I gone through the changelog, look likes it was not fixed since the reported version.


Hints:

Patch:
diff --git a/lib/utils.js b/lib/utils.js
--- a/lib/utils.js
+++ b/lib/utils.js
@@ -322,7 +322,7 @@ exports.parseQuery = function (qs) {
     var key = pair.slice(0, i);
     var val = pair.slice(++i);
 
-    obj[key] = decodeURIComponent(val);
+    obj[key] = decodeURIComponent(val.replace(/\+/g, '%20'));
     return obj;
   }, {});
 };


Test patch:
diff --git a/test/utils.spec.js b/test/utils.spec.js
--- a/test/utils.spec.js
+++ b/test/utils.spec.js
@@ -95,6 +95,10 @@ describe('utils', function () {
         r3: '^co.*'
       });
     });
+
+    it('should parse "+" as a space', function () {
+      parseQuery('?grep=foo+bar').should.eql({grep: 'foo bar'});
+    });
   });
 
   describe('.stackTraceFilter()', function () {
Repository: mochajs/mocha

Problem statement:
Diff doesn't be displayed when object has Symbol value
When I assert an object that has a `Symbol` value, the test doesn't display diff even if it fails. For example, the following test fails without generating diff.

``` javascript
// test.js
const assert = require('assert');

it('should generate diff', () => {
  const obj = { type: Symbol('foo') };
  assert.deepEqual(obj, { type: null });
});
```

result:

![mocha-symbol-before](https://cloud.githubusercontent.com/assets/12684251/12785091/01ee67a0-cace-11e5-83f9-34577f1872cb.png)

Then I found the `stringify` function in [lib/utils](https://github.com/mochajs/mocha/blob/master/lib/utils.js) throws a following error when the argument object has a `Symbol` value.

```
TypeError: Cannot convert a Symbol value to a string
```

environment:
- mocha: v2.4.5
- node: v4.2.2



Hints:

Patch:
diff --git a/lib/utils.js b/lib/utils.js
--- a/lib/utils.js
+++ b/lib/utils.js
@@ -472,6 +472,7 @@ function jsonStringify(object, spaces, depth) {
         break;
       case 'boolean':
       case 'regexp':
+      case 'symbol':
       case 'number':
         val = val === 0 && (1 / val) === -Infinity // `-0`
           ? '-0'
@@ -597,6 +598,7 @@ exports.canonicalize = function(value, stack) {
     case 'number':
     case 'regexp':
     case 'boolean':
+    case 'symbol':
       canonicalizedObj = value;
       break;
     default:


Test patch:
diff --git a/test/acceptance/utils.js b/test/acceptance/utils.js
--- a/test/acceptance/utils.js
+++ b/test/acceptance/utils.js
@@ -331,6 +331,15 @@ describe('lib/utils', function () {
 
       stringify(a).should.equal('{\n  "foo": 1\n}');
     });
+
+    // In old version node.js, Symbol is not available by default.
+    if (typeof global.Symbol === 'function') {
+      it('should handle Symbol', function () {
+        var symbol = Symbol('value');
+        stringify(symbol).should.equal('Symbol(value)');
+        stringify({symbol: symbol}).should.equal('{\n  "symbol": Symbol(value)\n}')
+      });
+    }
   });
 
   describe('type', function () {
Repository: mochajs/mocha

Problem statement:
-t isn't honored for long running sync operations.
I believe the duration should be checked against `_timeout` [here](https://github.com/visionmedia/mocha/blob/master/lib/runnable.js#L183).  Thoughts?
Something like:

``` javascript
if(that._timeout < duration)err = new Error('took too long!');
```



Hints:

Patch:
diff --git a/lib/runnable.js b/lib/runnable.js
--- a/lib/runnable.js
+++ b/lib/runnable.js
@@ -160,7 +160,6 @@ Runnable.prototype.globals = function(arr){
 
 Runnable.prototype.run = function(fn){
   var self = this
-    , ms = this.timeout()
     , start = new Date
     , ctx = this.ctx
     , finished
@@ -177,11 +176,13 @@ Runnable.prototype.run = function(fn){
 
   // finished
   function done(err) {
+    var ms = self.timeout();
     if (self.timedOut) return;
     if (finished) return multiple(err);
     self.clearTimeout();
     self.duration = new Date - start;
     finished = true;
+    if (!err && self.duration > ms) err = new Error('timeout of ' + ms + 'ms exceeded');
     fn(err);
   }
 


Test patch:
diff --git a/test/acceptance/failing/timeout.js b/test/acceptance/failing/timeout.js
new file mode 100644
--- /dev/null
+++ b/test/acceptance/failing/timeout.js
@@ -0,0 +1,18 @@
+
+describe('timeout', function(){
+  this.timeout(20);
+
+  it('should be honored with sync suites', function(){
+    sleep(30);
+  });
+
+  it('should be honored with async suites', function(done){
+    sleep(30);
+    done();
+  });
+
+  function sleep(ms){
+    var start = Date.now();
+    while(start + ms > Date.now())continue;
+  }
+});
Repository: mochajs/mocha

Problem statement:
Tests succeed on rejected falsey promises
Using Q, one of these two tests fails and the other one succeeds:

```
describe("mocha with promises", function() {
it("should fail on falsey rejected promises", function() {
    return q.reject(false);
});

it("should fail on truthy rejected promises", function() {
    return q.reject(true);
});
});
```

It appears that `q.reject(x)` where `x` is one of the six falsey values does not fail the test, whereas truthy values do.



Hints:

Patch:
diff --git a/lib/runnable.js b/lib/runnable.js
--- a/lib/runnable.js
+++ b/lib/runnable.js
@@ -223,7 +223,13 @@ Runnable.prototype.run = function(fn){
     var result = fn.call(ctx);
     if (result && typeof result.then === 'function') {
       self.resetTimeout();
-      result.then(function(){ done() }, done);
+      result
+        .then(function() {
+          done()
+        },
+        function(reason) {
+          done(reason || new Error('Promise rejected with no or falsy reason'))
+        });
     } else {
       done();
     }


Test patch:
diff --git a/test/runnable.js b/test/runnable.js
--- a/test/runnable.js
+++ b/test/runnable.js
@@ -299,6 +299,28 @@ describe('Runnable(title, fn)', function(){
         })
       })
 
+      describe('when the promise is rejected without a reason', function(){
+        var expectedErr = new Error('Promise rejected with no or falsy reason');
+        var rejectedPromise = {
+          then: function (fulfilled, rejected) {
+            process.nextTick(function () {
+              rejected();
+            });
+          }
+        };
+
+        it('should invoke the callback', function(done){
+          var test = new Runnable('foo', function(){
+            return rejectedPromise;
+          });
+
+          test.run(function(err){
+            err.should.eql(expectedErr);
+            done();
+          });
+        })
+      })
+
       describe('when the promise takes too long to settle', function(){
         var foreverPendingPromise = {
           then: function () { }
Repository: mochajs/mocha

Problem statement:
How is mocha.globals supposed to work?
Sorry for the terrible issue title :grin:.

When testing a jQuery plugin with Mocha, I'was warned about a global variable leak which [seems to be normal](http://bugs.jquery.com/ticket/14156).

So, I decided to get rid of it using `mocha.globals(["jQuery*"])` and it worked as expected... but I also tried without the wildcard like this `mocha.globals(["jQuery"])`, this worked too... and even `mocha.globals(["wth"])` got the job done.

So, maybe there is something a little buggy here, what do you think?



Hints:

Patch:
diff --git a/lib/runner.js b/lib/runner.js
--- a/lib/runner.js
+++ b/lib/runner.js
@@ -168,10 +168,6 @@ Runner.prototype.checkGlobals = function(test){
     ok = ok.concat(test._allowedGlobals || []);
   }
 
-  // check length - 2 ('errno' and 'location' globals)
-  if (isNode && 1 == ok.length - globals.length) return;
-  else if (2 == ok.length - globals.length) return;
-
   if(this.prevGlobalsLength == globals.length) return;
   this.prevGlobalsLength = globals.length;
 


Test patch:
diff --git a/test/runner.js b/test/runner.js
--- a/test/runner.js
+++ b/test/runner.js
@@ -97,6 +97,21 @@ describe('Runner', function(){
       runner.checkGlobals('im a test');
     })
 
+    it('should emit "fail" when a single new disallowed global is introduced after a single extra global is allowed', function(done) {
+      var doneCalled = false;
+      runner.globals('good');
+      global.bad = 1;
+      runner.on('fail', function(test, err) {
+        delete global.bad;
+        done();
+        doneCalled = true;
+      });
+      runner.checkGlobals('test');
+      if (!doneCalled) {
+        done(Error("Expected test failure did not occur."));
+      }
+    });
+
     it ('should not fail when a new common global is introduced', function(){
       // verify that the prop isn't enumerable
       delete global.XMLHttpRequest;
Repository: mochajs/mocha

Problem statement:
Add `specify` as a synonym for `it` in BDD interface
Apparently this is in RSpec, as per <a href="http://codebetter.com/jameskovacs/2012/04/19/ruby-and-rspec-powerful-languages-allow-simpler-frameworks/">a blog post I read</a>. It does seem nice in some cases. Yes/no?



Hints:
doesn't matter much to me, i dont dislike it but having two functions for the same thing could get kinda lame if your team starts mixing them. anyone else? +1, -1?

Yeah I'm happy to let this simmer until someone who really wants it comes along; no strong feelings. I've run into a few cases where it might make sense but do see the potential for lameness.


Patch:
diff --git a/lib/interfaces/bdd.js b/lib/interfaces/bdd.js
--- a/lib/interfaces/bdd.js
+++ b/lib/interfaces/bdd.js
@@ -84,7 +84,7 @@ module.exports = function(suite){
      * acting as a thunk.
      */
 
-    context.it = function(title, fn){
+    context.it = context.specify = function(title, fn){
       suites[0].addTest(new Test(title, fn));
     };
   });


Test patch:
diff --git a/test/acceptance/interfaces/bdd.js b/test/acceptance/interfaces/bdd.js
--- a/test/acceptance/interfaces/bdd.js
+++ b/test/acceptance/interfaces/bdd.js
@@ -22,4 +22,14 @@ describe('Array', function(){
       arr.should.eql([1,2]);
     })
   })
-})
\ No newline at end of file
+})
+
+context('Array', function(){
+  beforeEach(function(){
+    this.arr = [1,2,3];
+  })
+
+  specify('has a length property', function(){
+    this.arr.length.should.equal(3);
+  })
+})