PrimeIntellect/SWE-rebench-V2 huggingface dataset:
Repository: raphlinus/pulldown-cmark (rust)

Issue:
Index out of bounds at `firstpass.rs:1424`
I tried running the existing `parse` fuzzer, and found this crash:

```
thread '<unnamed>' panicked at 'index out of bounds: the len is 14 but the index is 14', /home/mg/src/pulldown-cmark/src/firstpass.rs:1424:13
stack backtrace:
   0: rust_begin_unwind
             at /rustc/6bba061467f7c2cab04b262b95eb67bf89265587/library/std/src/panicking.rs:593:5
   1: core::panicking::panic_fmt
             at /rustc/6bba061467f7c2cab04b262b95eb67bf89265587/library/core/src/panicking.rs:67:14
   2: core::panicking::panic_bounds_check
             at /rustc/6bba061467f7c2cab04b262b95eb67bf89265587/library/core/src/panicking.rs:162:5
   3: core::option::Option<T>::map_or
   4: pulldown_cmark::firstpass::scan_paragraph_interrupt
   5: pulldown_cmark::firstpass::FirstPass::parse_paragraph
   6: pulldown_cmark::firstpass::FirstPass::parse_block
   7: pulldown_cmark::firstpass::FirstPass::run
   8: pulldown_cmark::firstpass::run_first_pass
   9: pulldown_cmark::parse::Parser::new_ext
```

The input is a file with a lot of null bytes: [minimized-from-e9832c8a219680362d96eba6a59a76ace4b3cd40.zip](https://github.com/raphlinus/pulldown-cmark/files/11779703/minimized-from-e9832c8a219680362d96eba6a59a76ace4b3cd40.zip).

```
Output of `std::fmt::Debug`:

	FuzzingInput {
	    markdown: ".\r> ^](\r\u{c}\r\0\0\r.\r[^\0\0\\\0\0\0^^^^^]",
	    tables: false,
	    footnotes: true,
	    strikethrough: false,
	    tasklists: true,
	    smart_punctuation: false,
	    heading_attributes: false,
	}
```


Pull request:
Fix index out of bounds when parsing GFM footnote
The code here was introduced in #654 and the crash was found using

    cargo fuzz run parse

Fixes #666.

Patch:
diff --git a/src/firstpass.rs b/src/firstpass.rs
index 8754a78..091fd4d 100644
--- a/src/firstpass.rs
+++ b/src/firstpass.rs
@@ -1420,9 +1420,10 @@ fn scan_paragraph_interrupt(bytes: &[u8], current_container: bool, gfm_footnote:
         })
         || bytes.starts_with(b"<")
             && (get_html_end_tag(&bytes[1..]).is_some() || starts_html_block_type_6(&bytes[1..]))
-        || (gfm_footnote && bytes.starts_with(b"[^") && scan_link_label_rest(std::str::from_utf8(&bytes[2..]).unwrap(), &|_| None).map_or(false, |(len, _)| {
-            bytes[2 + len] == b':'
-        }))
+        || (gfm_footnote
+            && bytes.starts_with(b"[^")
+            && scan_link_label_rest(std::str::from_utf8(&bytes[2..]).unwrap(), &|_| None)
+                .map_or(false, |(len, _)| bytes.get(2 + len) == Some(&b':')))
 }
 
 /// Assumes `text_bytes` is preceded by `<`.


Test patch:
diff --git a/tests/errors.rs b/tests/errors.rs
index cac3479..b194bcb 100644
--- a/tests/errors.rs
+++ b/tests/errors.rs
@@ -85,6 +85,15 @@ fn test_fuzzer_input_12() {
     parse_all_options("\u{c}-\n\u{c}\n-");
 }
 
+#[test]
+fn test_fuzzer_input_13() {
+    // Does not fail with Options::all():
+    Parser::new_ext(
+        ".\r> ^](\r\u{c}\r\0\0\r.\r[^\0\0\\\0\0\0^^^^^]",
+        Options::ENABLE_FOOTNOTES,
+    );
+}
+
 #[test]
 fn test_wrong_code_block() {
     parse(
Repository: jsonata-js/jsonata (js)

Issue:
numeric precision should be 15 decimal digits, not 13
With the JavaScript implementation on try.jsonata.org I am getting only 13 decimal digits of precision with numeric data ... when I expected 15. I am observing this behavior in Chrome + FireFox + Safari. 

see http://try.jsonata.org/r1SPLIKjz

IEEE 754 double (binary64) gives you 53 bits of significand. This gives one a reliable 15 decimal digits of precision. 

[ If I invoke jsonata-1.1.1.js using the nashorn scripting engine of Java 1.8.0_152 then numeric data is retains its full IEEE value ... unless I explicitly call JSONata $string(). ]

Looks to me like the reason it is being chopped to 13 digits in the JavaScript implementation is with `functionString()`, where one sees the following:

    str = JSON.stringify(arg, function (key, val) {
                return (typeof val !== 'undefined' && val !== null &&
                           val.toPrecision && isNumeric(val)) ? 
                    Number(val.toPrecision(13)) :
                    (val && isFunction(val)) ? '' : val;`

My initial thought was/is that it would be best to leave the numbers alone and let `JSON.stringify()` handle it. Yet, there must have been some negative behavior that led to this code being added. 

Q: What was the issue that caused numbers to be treated this way? 

If there is a good reason for rounding to a specific decimal precision, then the precision should be set to 15, not 13. 




Pull request:
$string should format numbers to 15 s.f.
Change numeric precision from 13 to 15 in function `$string`
resolves #194 

Patch:
diff --git a/jsonata.js b/jsonata.js
index 80bbecc..4505cb6 100644
--- a/jsonata.js
+++ b/jsonata.js
@@ -3074,7 +3074,7 @@ var jsonata = (function() {
             };
         } else
             str = JSON.stringify(arg, function (key, val) {
-                return (typeof val !== 'undefined' && val !== null && val.toPrecision && isNumeric(val)) ? Number(val.toPrecision(13)) :
+                return (typeof val !== 'undefined' && val !== null && val.toPrecision && isNumeric(val)) ? Number(val.toPrecision(15)) :
                     (val && isFunction(val)) ? '' : val;
             });
         return str;


Test patch:
diff --git a/test/test-suite/groups/function-string/case001.json b/test/test-suite/groups/function-string/case001.json
index e831829..5c0ed47 100644
--- a/test/test-suite/groups/function-string/case001.json
+++ b/test/test-suite/groups/function-string/case001.json
@@ -2,5 +2,5 @@
     "expr": "$string(22/7)",
     "dataset": "dataset5",
     "bindings": {},
-    "result": "3.142857142857"
+    "result": "3.14285714285714"
 }
\ No newline at end of file
Repository: mgechev/revive (go)

Issue:
False positive of `return in a defer function has no effect`
**Describe the bug**
Unexpected `return in a defer function has no effect`

**To Reproduce**
1. use the 1.3.9 version
2. use this go code
```go
package main

func verify(a any) func() {
	return func() {
		fn := a.(func() error)
		if err := fn(); err != nil {
			panic(err)
		}
	}

}

func main() {
	defer verify(func() error {
		return nil
	})()
}
```

3. use this config
As of my understanding, it disable the `call-chain` defer check but enable the `return` defer check, which is our case.
```toml
[rule.defer]
  arguments=[["return"]]
```

**Expected behavior**
No `return in a defer function has no effect`

**Desktop (please complete the following information):**
 - OS: macOS
 - Version of Go: 1.22

**Additional context**
This issue is similar to #863, which is also the one first on Google, but this issue is not exactly the same.


Pull request:
fix #1029
Closes #1029 by skipping the analysis of function call arguments


Patch:
diff --git a/rule/defer.go b/rule/defer.go
index adc6478..9a19722 100644
--- a/rule/defer.go
+++ b/rule/defer.go
@@ -111,7 +111,7 @@ func (w lintDeferRule) Visit(node ast.Node) ast.Visitor {
 			// but it is very likely to be a misunderstanding of defer's behavior around arguments.
 			w.newFailure("recover must be called inside a deferred function, this is executing recover immediately", n, 1, "logic", "immediate-recover")
 		}
-
+		return nil // no need to analyze the arguments of the function call
 	case *ast.DeferStmt:
 		if isIdent(n.Call.Fun, "recover") {
 			// defer recover()


Test patch:
diff --git a/testdata/defer.go b/testdata/defer.go
index a035cfe..2cb4f57 100644
--- a/testdata/defer.go
+++ b/testdata/defer.go
@@ -47,3 +47,20 @@ func f() {
 		return nil
 	})
 }
+
+// Issue #1029
+func verify2(a any) func() {
+	return func() {
+		fn := a.(func() error)
+		if err := fn(); err != nil {
+			panic(err)
+		}
+	}
+
+}
+
+func mainf() {
+	defer verify2(func() error { // MATCH /prefer not to defer chains of function calls/
+		return nil
+	})()
+}
Repository: JoshuaKGoldberg/create-typescript-app (ts)

Issue:
🐛 Bug: README.md additional content should ignore older "this package is based on" notices
### Bug Report Checklist

- [x] I have tried restarting my IDE and the issue persists.
- [x] I have pulled the latest `main` branch of the repository.
- [x] I have [searched for related issues](https://github.com/JoshuaKGoldberg/create-typescript-app/issues?q=is%3Aissue) and found none that matched my issue.

### Expected

Older CTA repos used "templated by" notice like:

```md
> 💙 This package is based on [@JoshuaKGoldberg](https://github.com/JoshuaKGoldberg)'s [create-typescript-app](https://github.com/JoshuaKGoldberg/create-typescript-app).
```

This should be omitted when running `npx create-typescript-app` in transition mode

### Actual

https://github.com/JoshuaKGoldberg/should-semantic-release/pull/547/files#r2026952619: it's not.

### Additional Info

🎁 

Pull request:
fix: detect legacy 'based on' notices in README.md
## PR Checklist

- [x] Addresses an existing open issue: fixes #2124
- [x] That issue was marked as [`status: accepting prs`](https://github.com/JoshuaKGoldberg/create-typescript-app/issues?q=is%3Aopen+is%3Aissue+label%3A%22status%3A+accepting+prs%22)
- [x] Steps in [CONTRIBUTING.md](https://github.com/JoshuaKGoldberg/create-typescript-app/blob/main/.github/CONTRIBUTING.md) were taken

## Overview

🎁 

Patch:
diff --git a/src/options/readReadmeAdditional.ts b/src/options/readReadmeAdditional.ts
index b7a485e..a06eb58 100644
--- a/src/options/readReadmeAdditional.ts
+++ b/src/options/readReadmeAdditional.ts
@@ -3,7 +3,7 @@ const indicatorAfterAllContributorsSpellCheck =
 	/<!--\s*spellchecker:\s*enable\s*-->/;
 
 const indicatorBeforeTemplatedBy =
-	/> .* This package was templated with |<!-- You can remove this notice/;
+	/> .* This package (?:is|was) (?:based|build|templated) (?:on|with) |<!-- You can remove this notice/;
 
 export async function readReadmeAdditional(getReadme: () => Promise<string>) {
 	const readme = await getReadme();


Test patch:
diff --git a/src/options/readReadmeAdditional.test.ts b/src/options/readReadmeAdditional.test.ts
index 76bc78b..707c671 100644
--- a/src/options/readReadmeAdditional.test.ts
+++ b/src/options/readReadmeAdditional.test.ts
@@ -72,7 +72,25 @@ After.
 		expect(result).toBe("After.");
 	});
 
-	it("returns all content after contributors when there is a quote template notice", async () => {
+	it("returns all content after contributors when there is a legacy quote template notice", async () => {
+		const getReadme = () =>
+			Promise.resolve(`# My Package
+
+Usage.
+
+<!-- spellchecker:enable -->
+
+After.
+
+> 💙 This package is based on ...
+`);
+
+		const result = await readReadmeAdditional(getReadme);
+
+		expect(result).toBe("After.");
+	});
+
+	it("returns all content after contributors when there is a current quote template notice", async () => {
 		const getReadme = () =>
 			Promise.resolve(`# My Package
Repository: vaskoz/dailycodingproblem-go (go)

Issue:
Day 94
Good morning! Here's your coding interview problem for today.

This problem was asked by Google.

Given a binary tree of integers, find the maximum path sum between two nodes. The path must go through at least one node, and does not need to go through the root.

Pull request:
Day94
Resolves #197. 

Patch:
diff --git a/README.md b/README.md
index 27f2276..38172cc 100644
--- a/README.md
+++ b/README.md
@@ -102,5 +102,6 @@ problems from
 * [Day 90](https://github.com/vaskoz/dailycodingproblem-go/issues/189)
 * [Day 91](https://github.com/vaskoz/dailycodingproblem-go/issues/192)
 * [Day 92](https://github.com/vaskoz/dailycodingproblem-go/issues/194)
+* [Day 94](https://github.com/vaskoz/dailycodingproblem-go/issues/197)
 * [Day 95](https://github.com/vaskoz/dailycodingproblem-go/issues/198)
 * [Day 96](https://github.com/vaskoz/dailycodingproblem-go/issues/200)
diff --git a/day94/problem.go b/day94/problem.go
new file mode 100644
index 0000000..b70eb90
--- /dev/null
+++ b/day94/problem.go
@@ -0,0 +1,41 @@
+package day94
+
+// BinaryTree is a binary tree with an integer value.
+type BinaryTree struct {
+	Value       int
+	Left, Right *BinaryTree
+}
+
+// MaxPathSum returns the maximum path sum in a given
+// binary tree.
+func MaxPathSum(tree *BinaryTree) int {
+	const MinInt = -int(^uint(0)>>1) - 1
+	result := MinInt
+	maxPathSum(tree, &result)
+	return result
+}
+
+func maxPathSum(node *BinaryTree, res *int) int {
+	if node == nil {
+		return 0
+	} else if node.Left == nil && node.Right == nil {
+		return node.Value
+	}
+	leftSum := maxPathSum(node.Left, res)
+	rightSum := maxPathSum(node.Right, res)
+	if node.Left != nil && node.Right != nil {
+		*res = max(*res, leftSum+rightSum+node.Value)
+		return max(leftSum, rightSum) + node.Value
+	}
+	if node.Left == nil {
+		return rightSum + node.Value
+	}
+	return leftSum + node.Value
+}
+
+func max(a, b int) int {
+	if a > b {
+		return a
+	}
+	return b
+}


Test patch:
diff --git a/day94/problem_test.go b/day94/problem_test.go
new file mode 100644
index 0000000..de2caa1
--- /dev/null
+++ b/day94/problem_test.go
@@ -0,0 +1,35 @@
+package day94
+
+import "testing"
+
+var tree = &BinaryTree{
+	-15,
+	&BinaryTree{5,
+		&BinaryTree{-8,
+			&BinaryTree{2, nil, nil},
+			&BinaryTree{6, nil, nil}},
+		&BinaryTree{1, nil, nil}},
+	&BinaryTree{6,
+		&BinaryTree{3, nil, nil},
+		&BinaryTree{9, nil,
+			&BinaryTree{0,
+				&BinaryTree{4, nil, nil},
+				&BinaryTree{-1, &BinaryTree{10, nil, nil}, nil},
+			},
+		},
+	},
+}
+
+func TestMaxPathSum(t *testing.T) {
+	t.Parallel()
+	result := MaxPathSum(tree)
+	if result != 27 {
+		t.Errorf("Expected 27 got %v", result)
+	}
+}
+
+func BenchmarkMaxPathSum(b *testing.B) {
+	for i := 0; i < b.N; i++ {
+		MaxPathSum(tree)
+	}
+}