PrimeIntellect/SWE-rebench-V2 huggingface dataset:
Repository: jira-node/node-jira-client (js)

Issue:
issueLinkType not supported
``GET /rest/api/2/issueLinkType``
https://docs.atlassian.com/software/jira/docs/api/REST/8.5.0/#api/2/issueLinkType-getIssueLinkTypes

Pull request:
Add support for listIssueLinkTypes
Fixes #265

Patch:
diff --git a/src/jira.js b/src/jira.js
index 057b155..f2d9c44 100644
--- a/src/jira.js
+++ b/src/jira.js
@@ -458,6 +458,17 @@ export default class JiraApi {
     }));
   }
 
+  /** List all issue link types jira knows about
+   * [Jira Doc](https://docs.atlassian.com/software/jira/docs/api/REST/8.5.0/#api/2/issueLinkType-getIssueLinkTypes)
+   * @name listIssueLinkTypes
+   * @function
+   */
+  listIssueLinkTypes() {
+    return this.doRequest(this.makeRequestHeader(this.makeUri({
+      pathname: '/issueLinkType',
+    })));
+  }
+
   /** Retrieves the remote links associated with the given issue.
    * @name getRemoteLinks
    * @function


Test patch:
diff --git a/test/jira-tests.js b/test/jira-tests.js
index 4db0398..db37c73 100644
--- a/test/jira-tests.js
+++ b/test/jira-tests.js
@@ -746,6 +746,11 @@ describe('Jira API Tests', () => {
       result.should.eql('http://jira.somehost.com:8080/rest/api/2.0/issuetype');
     });
 
+    it('listIssueLinkTypes hits proper url', async () => {
+      const result = await dummyURLCall('listIssueLinkTypes', []);
+      result.should.eql('http://jira.somehost.com:8080/rest/api/2.0/issueLinkType');
+    });
+
     it('registerWebhook hits proper url', async () => {
       const result = await dummyURLCall('registerWebhook', ['someWebhook']);
       result.should.eql('http://jira.somehost.com:8080/rest/webhooks/1.0/webhook');
Repository: goadesign/goa (go)

Issue:
goa CLI panics when run without any args
```shell
$ goa
goa is the code generation tool for the Goa framework.
Learn more at https://goa.design.

Usage:
  ...help text...

panic: runtime error: index out of range [1] with length 1

goroutine 1 [running]:
main.main()
	/Users/andy/go/pkg/mod/goa.design/goa/v3@v3.18.2/cmd/goa/main.go:25 +0x520

```

Pull request:
Exit after usage() is shown. Fixes #3583
- Fixes panics
- Resolves Deepsource finding about extra block

Patch:
diff --git a/cmd/goa/main.go b/cmd/goa/main.go
index f7f33943..fd520f33 100644
--- a/cmd/goa/main.go
+++ b/cmd/goa/main.go
@@ -17,25 +17,26 @@ func main() {
 		path   string
 		offset int
 	)
-	{
-		if len(os.Args) == 1 {
-			usage()
-		}
+	if len(os.Args) == 1 {
+		usage()
+		return
+	}
 
-		switch os.Args[1] {
-		case "version":
-			fmt.Println("Goa version " + goa.Version())
-			os.Exit(0)
-		case "gen", "example":
-			if len(os.Args) == 2 {
-				usage()
-			}
-			cmd = os.Args[1]
-			path = os.Args[2]
-			offset = 2
-		default:
+	switch os.Args[1] {
+	case "version":
+		fmt.Println("Goa version " + goa.Version())
+		os.Exit(0)
+	case "gen", "example":
+		if len(os.Args) == 2 {
 			usage()
+			return
 		}
+		cmd = os.Args[1]
+		path = os.Args[2]
+		offset = 2
+	default:
+		usage()
+		return
 	}
 
 	var (


Test patch:
diff --git a/cmd/goa/main_test.go b/cmd/goa/main_test.go
index 04fbbf58..f9dad07c 100644
--- a/cmd/goa/main_test.go
+++ b/cmd/goa/main_test.go
@@ -35,9 +35,9 @@ func TestCmdLine(t *testing.T) {
 	}{
 		"gen": {"gen " + testPkg, false, "gen", testPkg, ".", false},
 
-		"invalid":     {"invalid " + testPkg, true, "", "", ".", false},
-		"empty":       {"", true, "", "", ".", false},
-		"invalid gen": {"invalid gen" + testPkg, true, "", "", ".", false},
+		"invalid":     {"invalid " + testPkg, true, "", "", "", false},
+		"empty":       {"", true, "", "", "", false},
+		"invalid gen": {"invalid gen" + testPkg, true, "", "", "", false},
 
 		"output":       {"gen " + testPkg + " -output " + testOutput, false, "gen", testPkg, testOutput, false},
 		"output short": {"gen " + testPkg + " -o " + testOutput, false, "gen", testPkg, testOutput, false},
Repository: piskvorky/smart_open (python)

Issue:
Bug (maybe feature) in HdfsOpenRead
On line 249 I have noticed a minor bug in reading from HDFS

There is used command `hadoop fs -cat` which based on the documentation http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/FileSystemShell.html reads any file mounted to Hadoop (HDFS, FS, HFTP FS, S3 FS, and others)

Correctly to meet what smart_open claims to do there should be used `hdfs dfs -cat`.
http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html#dfs

I can do a PR with fix if this is really a bug.

If this is expected behaviour then I would change the documentation + I would not limit files schema to only HDFS.

Pull request:
Hdfs __iter__ implementation fix
Fixed HDFS read to be able to read both `hdfs://` and `hdfs:///` (both should be equivalent and it depends on hdfs distribution)

Also fixed to use `hdfs dfs -cat` which is recommended.

Closes #24 

Patch:
diff --git a/smart_open/smart_open_lib.py b/smart_open/smart_open_lib.py
index f2a944b..b21704d 100644
--- a/smart_open/smart_open_lib.py
+++ b/smart_open/smart_open_lib.py
@@ -246,7 +246,7 @@ class HdfsOpenRead(object):
         self.parsed_uri = parsed_uri
 
     def __iter__(self):
-        hdfs = subprocess.Popen(["hadoop", "fs", "-cat", self.parsed_uri.uri_path], stdout=subprocess.PIPE)
+        hdfs = subprocess.Popen(["hdfs", "dfs", "-cat", os.path.join("/", self.parsed_uri.uri_path)], stdout=subprocess.PIPE)
         return hdfs.stdout
 
     def read(self, size=None):
@@ -387,7 +387,7 @@ class S3OpenWrite(object):
         if type is not None:
             self._termination_error()
             return False
-        
+
         try:
             self.close()
         except:


Test patch:
diff --git a/smart_open/tests/test_smart_open.py b/smart_open/tests/test_smart_open.py
index 8297027..58eb2c8 100644
--- a/smart_open/tests/test_smart_open.py
+++ b/smart_open/tests/test_smart_open.py
@@ -102,8 +102,12 @@ class SmartOpenReadTest(unittest.TestCase):
         smart_open_object = smart_open.HdfsOpenRead(smart_open.ParseUri("hdfs:///tmp/test.txt"))
         smart_open_object.__iter__()
         # called with the correct params?
-        mock_subprocess.Popen.assert_called_with(["hadoop", "fs", "-cat", "/tmp/test.txt"], stdout=mock_subprocess.PIPE)
+        mock_subprocess.Popen.assert_called_with(["hdfs", "dfs", "-cat", "/tmp/test.txt"], stdout=mock_subprocess.PIPE)
 
+        # second possibility of schema
+        smart_open_object = smart_open.HdfsOpenRead(smart_open.ParseUri("hdfs://tmp/test.txt"))
+        smart_open_object.__iter__()
+        mock_subprocess.Popen.assert_called_with(["hdfs", "dfs", "-cat", "/tmp/test.txt"], stdout=mock_subprocess.PIPE)
 
     @mock.patch('smart_open.smart_open_lib.boto')
     @mock.patch('smart_open.smart_open_lib.s3_iter_lines')
Repository: JuliaData/Tables.jl (julia)

Issue:
`Tables.columntable(NamedTuple[])` errors
It feels like `Tables.columntable()` should simply return `NamedTuple[]` if it is passed an empty collection.  As it stands, it currently errors:

```julia
julia> Tables.columntable(NamedTuple[])
ERROR: ArgumentError: type does not have a definite number of fields
Stacktrace:
 [1] fieldcount(::Any) at ./reflection.jl:725
 [2] buildcolumns at /home/sabae/.julia/packages/Tables/8Ud85/src/fallbacks.jl:206 [inlined]
 [3] columns at /home/sabae/.julia/packages/Tables/8Ud85/src/fallbacks.jl:253 [inlined]
 [4] columntable(::Array{NamedTuple,1}) at /home/sabae/.julia/packages/Tables/8Ud85/src/namedtuples.jl:158
 [5] top-level scope at REPL[2]:1
```

Pull request:
Fixes #228. We recently added support so that when a schema-less input
row table was being converted to column-orientation, but had an eltype,
we produced an appropriately typed NamedTuple with empty Vectors of
corresponding types. The issue reported, however, is when an empty input
has an eltype, but that eltype is abstract. The error results by trying
to call `fieldcount(::AbstractType)`, which fails and doesn't make sense
to do anyway. This is technically a regression because we used to
produce an empty `NamedTuple()` unconditionally, and now we're producing
this error path for the abstract eltype case. The fix proposed is
straightforward: only consider generating a typed NamedTuple output if
the iterator eltype is concretely typed.

Patch:
diff --git a/src/fallbacks.jl b/src/fallbacks.jl
index 5256c56..48c2ab1 100644
--- a/src/fallbacks.jl
+++ b/src/fallbacks.jl
@@ -203,7 +203,7 @@ end
             WT = wrappedtype(eltype(rowitr))
             if WT <: Tuple
                 return allocatecolumns(Schema((Symbol("Column$i") for i = 1:fieldcount(WT)), _fieldtypes(WT)), 0)
-            elseif fieldcount(WT) > 0
+            elseif isconcretetype(WT) && fieldcount(WT) > 0
                 return allocatecolumns(Schema(fieldnames(WT), _fieldtypes(WT)), 0)
             end
         end


Test patch:
diff --git a/test/runtests.jl b/test/runtests.jl
index adfcac1..d57c6f0 100644
--- a/test/runtests.jl
+++ b/test/runtests.jl
@@ -169,6 +169,9 @@ end
     @test eltype(rt).parameters[1] == nms
     @test Tables.columntable(rt) == nt
     @test Tables.buildcolumns(nothing, rt) == nt
+
+    # 228
+    @test Tables.columntable(NamedTuple[]) === NamedTuple()
 end
 
 @testset "Materializer" begin