nebius/SWE-rebench-V2-PRs huggingface dataset:
Repository: goldibex/targaryen
Pull request #8 (2015-02-04 19:37:27)

indexOn can take an array of keys as well as a single key


Patch:
diff --git a/lib/ruleset.js b/lib/ruleset.js
index 452941f..864e01f 100644
--- a/lib/ruleset.js
+++ b/lib/ruleset.js
@@ -73,8 +73,12 @@ function Ruleset(rulesDefinition) {
 
         if (!validRuleKinds.hasOwnProperty(key)) {
           throw ruleError(stack, 'invalid rule type "' + key + '"');
-        } else if (key === '.indexOn' && typeof rulesObject[key] !== 'string') {
-          throw ruleError(stack, 'indexOn expects a string, but got ' + typeof rulesObject[key]);
+        } else if (key === '.indexOn') {
+
+          if (!(Array.isArray(rulesObject[key]) || typeof rulesObject[key] === 'string')) {
+            throw ruleError(stack, 'indexOn expects a string or array, but got ' + typeof rulesObject[key]);
+          }
+
         } else if (typeof rulesObject[key] !== 'boolean' && typeof rulesObject[key] !== 'string') {
           throw ruleError(stack, 'expected string or boolean, but got ' + typeof rulesObject[key]);
         }


Test patch:
diff --git a/test/spec/lib/ruleset.js b/test/spec/lib/ruleset.js
index b3908ba..ffad4ef 100644
--- a/test/spec/lib/ruleset.js
+++ b/test/spec/lib/ruleset.js
@@ -97,6 +97,10 @@ var validRulesets = [{
     '.indexOn': 'wut',
     '.validate': true
   }
+}, {
+  rules: {
+    '.indexOn': ['wut', 'the', 'heck']
+  }
 }, {
   rules: {
   }
Repository: goldibex/targaryen
Pull request #35 (2016-07-08 10:51:13)

Fixed .priority key overwritten when part of an Object
When testing with priorities, I encountered a problem where `.priority` keys were set to `null` when they were part of an Object with other fields. Turns out in the `firebaseify` function, all keys of an object are firebaseified, including the `.priority` key.


Patch:
diff --git a/lib/rule-data-snapshot.js b/lib/rule-data-snapshot.js
index 643b3b2..886cd89 100644
--- a/lib/rule-data-snapshot.js
+++ b/lib/rule-data-snapshot.js
@@ -49,7 +49,9 @@ RuleDataSnapshot.convert = function(data) {
       };
 
       Object.keys(node).forEach(function(key) {
-        newObj[key] = firebaseify(node[key]);
+        if (key != '.priority') {
+          newObj[key] = firebaseify(node[key]);
+        }
       });
 
       return newObj;


Test patch:
diff --git a/test/jasmine/core.js b/test/jasmine/core.js
index 60a1ec4..d00fcce 100644
--- a/test/jasmine/core.js
+++ b/test/jasmine/core.js
@@ -167,4 +167,5 @@ describe('the targaryen Jasmine plugin', function() {
     });
 
   });
+
 });
diff --git a/test/spec/lib/rule-data-snapshot.js b/test/spec/lib/rule-data-snapshot.js
index 1172821..ec559f5 100644
--- a/test/spec/lib/rule-data-snapshot.js
+++ b/test/spec/lib/rule-data-snapshot.js
@@ -70,9 +70,22 @@ describe('RuleDataSnapshot', function() {
           '.priority': null
         }
       });
-
     });
 
+    it('transparently handles objects for which a priority is set in the root', function() {
+      expect(RuleDataSnapshot.convert({ '.priority': 100, foo: { '.value': true, '.priority': 5}, bar: 8 }))
+          .to.deep.equal({
+        '.priority': 100,
+        foo: {
+          '.value': true,
+          '.priority': 5
+        },
+        bar: {
+          '.value': 8,
+          '.priority': null
+        }
+      });
+    });
   });
 
   describe('#val', function() {
Repository: goldibex/targaryen
Pull request #57 (2016-10-21 17:32:59)

Type inference for addition operand
Removes the requirement that addition operand types are statically determinable. 

In the Firebase simulator, I verified behaviour with expressions of the form `'users/'+auth.uid` (always returns a string) and `auth.a+auth.b` (return type determined at runtime - tested with both number and string operands).

dinoboff: [In js](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Arithmetic_Operators):
- If both side are number/boolean, the type is a number.
- Anything else produce a string.

Is it different in firebase? Would it practical to use those two rules?

mhuebert: If we were performing this inference at runtime then yes, but I believe this inference is happening when we create a ruleset? So in the case of `auth.a + auth.b`, both values are unknown; we can't yet know if we want the return value to be a number or a string.
dinoboff: There's no way to infer the type of `auth.a + auth.b`. If the default type was string, your test would pass.

I think we should loosen type checking; maybe we could add "unknown" type and make sure type related error at run type get caught.
mhuebert: I agree that the requirements should be relaxed. A default type of 'string' would cause this test to pass, but would conflict with a scenario in which the two unknown values were numbers.

This PR seems to work for me, but I haven't had time to get really familiar with this section of the codebase so I don't know if it's a good approach.

Patch:
diff --git a/lib/parser/scope.js b/lib/parser/scope.js
index f8d02ce..9e10516 100644
--- a/lib/parser/scope.js
+++ b/lib/parser/scope.js
@@ -229,10 +229,9 @@ Scope.prototype._inferBinaryExpression = function(node) {
       node.inferredType = right;
     } else if (node.right.type === 'CallExpression') {
       node.inferredType = left;
-    } else {
-      throw nodeError(node, '+ needs 2 operands of types number, string, or CallExpression, but got ' +
-        left + ' and ' + right + ' instead.');
-    }
+    } else if (left || right) {
+      node.inferredType = left || right;
+    } 
 
   } else if (binaryArithmeticOperatorTypes[node.operator]) {
 


Test patch:
diff --git a/test/spec/lib/parser/rule.js b/test/spec/lib/parser/rule.js
index a58b32e..a5ffaa2 100644
--- a/test/spec/lib/parser/rule.js
+++ b/test/spec/lib/parser/rule.js
@@ -24,7 +24,9 @@ var validRules = [
   'root.hasChildren([$here])',
   'root.hasChildren([auth.uid])',
   'root.child("users").child(auth.uid).child($here).val().replace("x", $here) === "yyzzy"',
-  'root.child("str").val().matches(/foo/)'
+  'root.child("str").val().matches(/foo/)',
+  'root.child("users/"+auth.uid).exists()',
+  'root.child(auth.x+auth.y).exists()'
 ];
 var invalidRules = [
   'var foo = 8', // invalid syntax (no declarations allowed)
Repository: goldibex/targaryen
Pull request #71 (2016-10-28 18:00:14)

Fix helpers
Path splitter and joiner can now handle empty paths.


Patch:
diff --git a/lib/helpers.js b/lib/helpers.js
index 1a573ce..7d8770d 100644
--- a/lib/helpers.js
+++ b/lib/helpers.js
@@ -4,27 +4,41 @@ exports.trimLeft = function(path) {
   path = path || '';
 
   return path.replace(/^\/+/, '');
-}
+};
 
 exports.trimRight = function(path) {
   path = path || '';
 
   return path.replace(/\/+$/, '');
-}
+};
 
 exports.trim = function(path) {
   return exports.trimLeft(exports.trimRight(path));
-}
+};
 
 exports.pathMerger = function(root, path) {
   root = exports.trim(root);
   path = exports.trimLeft(path);
 
+  if (!root) {
+    return path;
+  }
+
+  if (!path) {
+    return root;
+  }
+
   return root + '/' + path;
-}
+};
 
 exports.pathSplitter = function(path) {
-  return exports.trimLeft(path).split('/');
+  path = exports.trimLeft(path);
+
+  if (!path) {
+    return [];
+  }
+
+  return path.split('/');
 };
 
 exports.makeNewDataSnap = function() {


Test patch:
diff --git a/test/spec/lib/helpers.js b/test/spec/lib/helpers.js
index ae99668..5401e3c 100644
--- a/test/spec/lib/helpers.js
+++ b/test/spec/lib/helpers.js
@@ -9,6 +9,8 @@ describe('helpers', function() {
 
     it('should merge path', function() {
       expect(helpers.pathMerger('foo', 'bar/baz')).to.equal('foo/bar/baz');
+      expect(helpers.pathMerger('foo', '')).to.equal('foo');
+      expect(helpers.pathMerger('', 'bar/baz')).to.equal('bar/baz');
     });
 
     it('should trim root path', function() {
@@ -27,6 +29,11 @@ describe('helpers', function() {
       expect(helpers.pathSplitter('foo/bar/baz')).to.eql(['foo', 'bar', 'baz']);
     });
 
+    it('should no split empty path', function() {
+      expect(helpers.pathSplitter('')).to.eql([]);
+    });
+
+
     it('should trim the beginning of the path', function() {
       expect(helpers.pathSplitter('/foo/bar/baz')).to.eql(['foo', 'bar', 'baz']);
     });