internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: piskvorky/gensim

Issue:
Gensim broken with SciPy 1.13.0
Gensim is broken with [SciPy 1.13.0](https://github.com/scipy/scipy/releases/tag/v1.13.0) which was released today.

This is due to the [removal of scipy.linalg.triu](https://github.com/scipy/scipy/pull/19674)

```
.venv/lib/python3.11/site-packages/gensim/__init__.py:11: in <module>
    from gensim import parsing, corpora, matutils, interfaces, models, similarities, utils  # noqa:F401
.venv/lib/python3.11/site-packages/gensim/corpora/__init__.py:6: in <module>
    from .indexedcorpus import IndexedCorpus  # noqa:F401 must appear before the other classes
.venv/lib/python3.11/site-packages/gensim/corpora/indexedcorpus.py:14: in <module>
    from gensim import interfaces, utils
.venv/lib/python3.11/site-packages/gensim/interfaces.py:19: in <module>
    from gensim import utils, matutils
.venv/lib/python3.11/site-packages/gensim/matutils.py:20: in <module>
    from scipy.linalg import get_blas_funcs, triu
E   ImportError: cannot import name 'triu' from 'scipy.linalg
```



Discussion:

Resolving patch:
diff --git a/gensim/matutils.py b/gensim/matutils.py
--- a/gensim/matutils.py
+++ b/gensim/matutils.py
@@ -17,9 +17,13 @@
 import numpy as np
 import scipy.sparse
 from scipy.stats import entropy
-from scipy.linalg import get_blas_funcs, triu
+from scipy.linalg import get_blas_funcs
 from scipy.linalg.lapack import get_lapack_funcs
 from scipy.special import psi  # gamma function utils
+try:
+    from numpy import triu
+except ImportError:
+    from scipy.linalg import triu
 
 
 logger = logging.getLogger(__name__)


Test patch:
Repository: piskvorky/gensim

Issue:
Support for python3.12
Hello there, is it possible that `gensim` can support python3.12?


Discussion:
Yes, why not. Can you open a PR @SysuJayce?
Are there any more fixes needed. I'm looking for first contribution.
Thank you!

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -372,6 +372,7 @@ def run(self):
         'Programming Language :: Python :: 3.9',
         'Programming Language :: Python :: 3.10',
         'Programming Language :: Python :: 3.11',
+        'Programming Language :: Python :: 3.12',
         'Programming Language :: Python :: 3 :: Only',
         'Topic :: Scientific/Engineering :: Artificial Intelligence',
         'Topic :: Scientific/Engineering :: Information Analysis',


Test patch:
diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
--- a/.github/workflows/tests.yml
+++ b/.github/workflows/tests.yml
@@ -67,11 +67,13 @@ jobs:
           - {python: '3.9', os: ubuntu-20.04}
           - {python: '3.10', os: ubuntu-20.04}
           - {python: '3.11', os: ubuntu-20.04}
+          - {python: '3.12', os: ubuntu-20.04}
 
           - {python: '3.8', os: windows-2019}
           - {python: '3.9', os: windows-2019}
           - {python: '3.10', os: windows-2019}
           - {python: '3.11', os: windows-2019}
+          - {python: '3.12', os: windows-2019}
 
     #
     # Don't run this job unless the linters have succeeded.
Repository: pantsbuild/pants

Issue:
Audit memory usage
Although they're not perfect, allocation profiles from a few different phases during the lifecycle of `./pants list ::` indicate that the majority of both held and emphemeral allocation happens inside of `nodes::Context::get`, which is where `Graph` manipulation occurs.

Thought process:
  1) can we use raw references to a thing in order to avoid needing to own/clone it (without the lifetime management being a pain in the butt)?
  2) if it is impossible/impractical to hold a reference, is it large/copied enough to be worth moving into an `Arc`?
  3) if it needs to be owned, should it be in a Box in order to make the average size of an enum smaller?
  4) if it's ephemeral but occasionally large, should it move into a [thread local](https://doc.rust-lang.org/std/thread/struct.LocalKey.html)?

A summary of `std::mem::size_of` (bytes) for a few relevant types:

    bytes	type
    24	DepSet
    24	Entries
    216	Entry
    16	EntryStateField
    24	Nodes
    16	NodeFuture<NodeResult>
    120	NodeKey
    24	ReadLink
    24	Stat
    24	Scandir
    72	Select
    112	SelectDependencies
    48	SelectLiteral
    88	SelectProjection
    48	Snapshot
    96	Task
    64	NodeResult
    80	Selector
    32	selector::Select
    72	selector::SelectDependencies
    48	selector::SelectProjection
    24	selector::SelectLiteral

Note: this is their _shallow_ size: if they contain a `Box` (and thus also`Arc`/`Vec`/`String`/etc), those are not counted. See [this post](https://blog.mozilla.org/nnethercote/2015/06/03/measuring-data-structure-sizes-firefox-c-vs-servo-rust/) for more info.


Discussion:
A particularly high value item would appear to be to have `NodeKey` (and other things) hold references to `Task`s in the `Tasks` collection... `Task` itself is only 96 bytes, but it has a `Vec<Selector>`, and each `Selector` is (at least) 80 bytes... more in the case of `SelectDependencies`, since it holds a `Vec<TypeId>` and a `Field` (string).

... and ditto all other `Selector` implementations, for that matter.

Resolving patch:
diff --git a/src/python/pants/engine/subsystem/native.py b/src/python/pants/engine/subsystem/native.py
--- a/src/python/pants/engine/subsystem/native.py
+++ b/src/python/pants/engine/subsystem/native.py
@@ -85,8 +85,6 @@
   _Bool  is_throw;
 } RunnableComplete;
 
-typedef uint64_t EntryId;
-
 typedef void ExternContext;
 
 // On the rust side the integration is defined in externs.rs


Test patch:
Repository: pantsbuild/pants

Issue:
`./pants list` with no targets does not render a warning/error
The behaviour of `./pants list` has changed between v1 and v2, and for a while a warning existed to indicate to users of a no-arg `list` that its behaviour would be changing soon.

It looks like that warning must have been removed at some point, because I don't see a warning with either v1 or v2 in the `1.3.x` branch:
```
./pants --enable-v2-engine list | head
./pants --no-enable-v2-engine list | head
```


Discussion:

Resolving patch:
diff --git a/src/python/pants/task/task.py b/src/python/pants/task/task.py
--- a/src/python/pants/task/task.py
+++ b/src/python/pants/task/task.py
@@ -11,6 +11,7 @@
 from hashlib import sha1
 from itertools import repeat
 
+from pants.base.deprecated import deprecated_conditional
 from pants.base.exceptions import TaskError
 from pants.base.worker_pool import Work
 from pants.cache.artifact_cache import UnreadableArtifact, call_insert, call_use_cached_files
@@ -566,11 +567,12 @@ def determine_target_roots(self, goal_name, predicate=None):
     :param string goal_name: The goal name to use for any warning emissions.
     :param callable predicate: The predicate to pass to `context.scan().targets(predicate=X)`.
     """
+    deprecated_conditional(
+        lambda: not self.context.target_roots,
+        '1.5.0.dev0',
+        '`./pants {0}` (with no explicit targets) will soon become an error. Please specify '
+        'one or more explicit target specs (e.g. `./pants {0} ::`).'.format(goal_name))
     if not self.context.target_roots and not self.get_options().enable_v2_engine:
-      self.context.log.warn(
-        'The behavior of `./pants {0}` (no explicit targets) will soon become a no-op. '
-        'To remove this warning, please specify one or more explicit target specs (e.g. '
-        '`./pants {0} ::`).'.format(goal_name))
       # For the v1 path, continue the behavior of e.g. `./pants list` implies `./pants list ::`.
       return self.context.scan().targets(predicate=predicate)
 


Test patch:
Repository: pantsbuild/pants

Issue:
duplicate dependencies allowed with v2 engine
I noticed this when switching the v2 engine off.  We had a few BUILD files that listed dependencies more than once.  This caused failures with the old engine, but the new engine didn't complain.

For example, this is allowed:

```
target(name='test',
  dependencies=[
    ':world',
    ':world'
  ]
)
```

If you pass in `--no-enable-v2-engine`, then this is correctly rejected with the following:

```
Exception message: Addresses in dependencies must be unique. 'nucleus:world' is referenced more than once.
  referenced from nucleus:test
```



Discussion:
In order to avoid regressing in the stable release (and since we're going to need another `1.3.0` rc anyway), I'm targeting this at `1.3.0`.
Will be busy tonight, so unassigning for now. If anyone else wants to tackle it before tomorrow, feel free.

Resolving patch:
diff --git a/src/python/pants/build_graph/mutable_build_graph.py b/src/python/pants/build_graph/mutable_build_graph.py
--- a/src/python/pants/build_graph/mutable_build_graph.py
+++ b/src/python/pants/build_graph/mutable_build_graph.py
@@ -69,7 +69,7 @@ def inject_address_closure(self, address):
       for dep_address in dep_addresses:
         if dep_address in deps_seen:
           raise self.DuplicateAddressError(
-            'Addresses in dependencies must be unique. \'{spec}\' is referenced more than once.'
+            "Addresses in dependencies must be unique. '{spec}' is referenced more than once."
             .format(spec=dep_address.spec))
         deps_seen.add(dep_address)
         self.inject_address_closure(dep_address)
diff --git a/src/python/pants/engine/legacy/graph.py b/src/python/pants/engine/legacy/graph.py
--- a/src/python/pants/engine/legacy/graph.py
+++ b/src/python/pants/engine/legacy/graph.py
@@ -144,9 +144,15 @@ def _index_target(self, target_adaptor):
     target = self._instantiate_target(target_adaptor)
     self._target_by_address[address] = target
 
-    # Link its declared dependencies, which will be indexed independently.
-    self._target_dependencies_by_address[address].update(target_adaptor.dependencies)
     for dependency in target_adaptor.dependencies:
+      if dependency in self._target_dependencies_by_address[address]:
+        raise self.DuplicateAddressError(
+          'Addresses in dependencies must be unique. '
+          "'{spec}' is referenced more than once by target '{target}'."
+          .format(spec=dependency.spec, target=address.spec)
+        )
+      # Link its declared dependencies, which will be indexed independently.
+      self._target_dependencies_by_address[address].add(dependency)
       self._target_dependees_by_address[dependency].add(address)
     return target
 


Test patch:
Repository: pantsbuild/pants

Issue:
Enable implicit_sources by default
The `target-arguments.implicit_sources` option is extremely helpful in encouraging good target hygiene. We should enable it by default, after a period in which we warn if it is disabled.

To avoid being too noisy with the warning, it should be possible to conditionally warn only if implicit sources is False, and implicit sources _would_ be applied for a target... ie: warn in locations where we would apply the option, despite it being disabled. Then, after a release cycle or two, we can invert the default for the option and deprecate it.


Discussion:
Hm, it looks like the first step here is to readd usage of the `target-arguments.implicit_sources` flag in `src/python/pants/engine/legacy/structs.py`, because it is not currently used there and should be (ie, implicit sources are currently enabled by default in the v2 engine, regardless of the setting).
@ity : How's this one looking? Fixing the existing option at least will be a blocker.
Going to try to tackle this before `1.3.0.rc0`.
The bug portion of this issue has now been resolved. Moving to `1.4.0`, as I think we can flip the default in master as soon as the `1.3.0` branch has been cut.
thanks for taking this on @stuhood - I should have just done the pr with the bug portion first. 
Should also try to improve the docs for this quite a bit.

Resolving patch:
diff --git a/src/python/pants/build_graph/target.py b/src/python/pants/build_graph/target.py
--- a/src/python/pants/build_graph/target.py
+++ b/src/python/pants/build_graph/target.py
@@ -164,9 +164,12 @@ def register_options(cls, register):
                help='Map of target name to a list of keyword arguments that should be ignored if a '
                     'target receives them unexpectedly. Typically used to allow usage of arguments '
                     'in BUILD files that are not yet available in the current version of pants.')
-      register('--implicit-sources', advanced=True, type=bool,
+      register('--implicit-sources', advanced=True, default=True, type=bool,
+               removal_version='1.6.0.dev0',
+               removal_hint='Implicit sources are now the default.',
                help='If True, Pants will infer the value of the sources argument for certain '
-                    'target types, if they do not have explicit sources specified.')
+                    'target types, if they do not have explicit sources specified. '
+                    'See http://www.pantsbuild.org/build_files.html#target-definitions')
 
     @classmethod
     def check(cls, target, kwargs):


Test patch:
Repository: pantsbuild/pants

Issue:
`./pants test.pytest --no-fast` shows failure summary in wrong color
seen in our monorepo, it looks like when passing `--no-fast` to `test.pytest` - if a failure is encountered (in this case, tests passed while coverage failed) the output indicates "FAILURE" but shows up in green rather than red which is misleading:

![image](https://user-images.githubusercontent.com/1883523/27161129-25233e84-512e-11e7-8746-6b7e357293e4.png)



Discussion:
For sanity sake - what version of pants is this bug against?
it'd be against master @ 4f83fff
This appears to be a long-standing bug in both old and new pytest tasks.

Resolving patch:
diff --git a/src/python/pants/backend/python/tasks/pytest_run.py b/src/python/pants/backend/python/tasks/pytest_run.py
--- a/src/python/pants/backend/python/tasks/pytest_run.py
+++ b/src/python/pants/backend/python/tasks/pytest_run.py
@@ -138,8 +138,9 @@ def run_tests(self, targets, workunit):
         if not rv.success and self.get_options().fail_fast:
           break
 
-      for target in sorted(results):
-        self.context.log.info('{0:80}.....{1:>10}'.format(target.id, str(results[target])))
+      for target, rv in sorted(results.items()):
+        log = self.context.log.info if rv.success else self.context.log.error
+        log('{0:80}.....{1:>10}'.format(target.id, rv))
 
       failed_targets = [target for target, _rv in results.items() if not _rv.success]
       if failed_targets:
diff --git a/src/python/pants/backend/python/tasks2/pytest_run.py b/src/python/pants/backend/python/tasks2/pytest_run.py
--- a/src/python/pants/backend/python/tasks2/pytest_run.py
+++ b/src/python/pants/backend/python/tasks2/pytest_run.py
@@ -522,9 +522,10 @@ def _run_tests(self, targets):
         break
 
     for partition in sorted(results):
-      rv = str(results[partition])
+      rv = results[partition]
       for target in partition:
-        self.context.log.info('{0:80}.....{1:>10}'.format(target.id, rv))
+        log = self.context.log.info if rv.success else self.context.log.error
+        log('{0:80}.....{1:>10}'.format(target.id, rv))
 
     failed_targets = [target
                       for _rv in results.values() if not _rv.success


Test patch:
Repository: pantsbuild/pants

Issue:
The `-c` form of `--pants-config-files` does not work for options bootstrapping.
I discovered this doing ad-hoc testing for #4587 via `./pants -c=pants.cache.ini test.pytest tests/python/pants_test/cache/:cache_setup`. The local cache was not being turned on. The `-c` short form of `--pants-config-files` was added in #4715 but the [`get_config_file_paths`](https://github.com/pantsbuild/pants/blob/master/src/python/pants/option/options_bootstrapper.py#L28-L55) method was not updated to account for this alternate form. Updating that method raises issues since a mild TODO now becomes much more prominent without a refactoring of the options parsing system to ensure we read the global `-c` and not a local one.


Discussion:

Resolving patch:
diff --git a/src/python/pants/option/global_options.py b/src/python/pants/option/global_options.py
--- a/src/python/pants/option/global_options.py
+++ b/src/python/pants/option/global_options.py
@@ -94,14 +94,14 @@ def register_bootstrap_options(cls, register):
              help='The directory to use for tracking subprocess metadata, if any. This should '
                   'live outside of the dir used by `--pants-workdir` to allow for tracking '
                   'subprocesses that outlive the workdir data (e.g. `./pants server`).')
-    register('-c', '--pants-config-files', advanced=True, type=list,
+    register('--pants-config-files', advanced=True, type=list,
              default=[get_default_pants_config_file()], help='Paths to Pants config files.')
+    # TODO: Deprecate the --pantsrc/--pantsrc-files options?  This would require being able
+    # to set extra config file locations in an initial bootstrap config file.
     register('--config-override', advanced=True, type=list, metavar='<path>',
              removal_version='1.6.0.dev0',
-             removal_hint='Use -c=<second config file path> instead.',
+             removal_hint='Use --pants-config-files=<second config file path> instead.',
              help='A second config file, to override pants.ini.')
-    # TODO: Deprecate the --pantsrc/--pantsrc-files options?  This would require being able
-    # to set extra config file locations in an initial bootstrap config file.
     register('--pantsrc', advanced=True, type=bool, default=True,
              help='Use pantsrc files.')
     register('--pantsrc-files', advanced=True, type=list, metavar='<path>',


Test patch:
Repository: pantsbuild/pants

Issue:
Binaries for 10.13 High Sierra
When I run pants on HIgh Sierra, I get `Exception message: Update --binaries-path-by-id to find binaries for (u'darwin', u'17')`


Discussion:
We'll need to update [`BinaryUtil`](https://github.com/pantsbuild/pants/blob/master/src/python/pants/binaries/binary_util.py#L24-L37) as well as https://github.com/pantsbuild/binaries including a run of `sync-s3.sh`.
As a workaround, you should be able to add an option like:
```
[binaries]
path_by_id: {('darwin', '17'): ('mac', '10.12')}
```
...to `pants.ini` to request that older binaries be used.

Resolving patch:
diff --git a/src/python/pants/binaries/binary_util.py b/src/python/pants/binaries/binary_util.py
--- a/src/python/pants/binaries/binary_util.py
+++ b/src/python/pants/binaries/binary_util.py
@@ -34,6 +34,7 @@
   ('darwin', '14'): ('mac', '10.10'),
   ('darwin', '15'): ('mac', '10.11'),
   ('darwin', '16'): ('mac', '10.12'),
+  ('darwin', '17'): ('mac', '10.13'),
 }
 
 


Test patch:
Repository: pantsbuild/pants

Issue:
`pants server` entries don't reflect the proper cli invocation when executed through pantsd.



Discussion:

Resolving patch:
diff --git a/src/python/pants/bin/daemon_pants_runner.py b/src/python/pants/bin/daemon_pants_runner.py
--- a/src/python/pants/bin/daemon_pants_runner.py
+++ b/src/python/pants/bin/daemon_pants_runner.py
@@ -146,6 +146,9 @@ def post_fork_child(self):
     # terminal window.
     self._exiter.set_except_hook(sys.stderr)
 
+    # Ensure anything referencing sys.argv inherits the Pailgun'd args.
+    sys.argv = self._args
+
     # Set context in the process title.
     set_process_title('pantsd-runner [{}]'.format(' '.join(self._args)))
 


Test patch:
Repository: pantsbuild/pants

Issue:
The 1.3.X branch does not sync native_engine.so binaries to s3
As a result, 1.3.X installs fail to fetch a native engine binary.


Discussion:
There are a few fixes possible here. One would be to add back the bintray urls to the binary urls (so use 2 for the 1.3.X series). The other would be to tweak the 1.3.X release process or `.travis.yml` deploy process to sync these up to s3.
Hmm, shoot. I did a `-t` build after releasing, but probably because I already had the native binary built locally, it didn't need to be fetched.
There is enough divergence between 1.4.x and 1.3.x [1] that I think reinstating the bintray url (as backup) is the way to go.

[1]: 1.3.x deploys a bare binary that is downloaded by pants at runtime and 1.4.x deploys platform-specific wheels with the binary embedded. Correspondingly, both the `.travis.yml` and `./build-support/bin/release.sh` scripts (and friends) diverge enough that keeping status quo here is less risky.

Resolving patch:
diff --git a/src/python/pants/binaries/binary_util.py b/src/python/pants/binaries/binary_util.py
--- a/src/python/pants/binaries/binary_util.py
+++ b/src/python/pants/binaries/binary_util.py
@@ -56,7 +56,14 @@ class Factory(Subsystem):
     @classmethod
     def register_options(cls, register):
       register('--baseurls', type=list, advanced=True,
-               default=['https://s3.amazonaws.com/binaries.pantsbuild.org'],
+               default=['https://binaries.pantsbuild.org',
+                        # NB: The 1.3.x branch uses a native engine packaging scheme and release
+                        # process that differs widely from the mainline. As a result, we include
+                        # the legacy bintray url (where the native engine is deployed to on this
+                        # branch) to allow for deployment and fetching of the native engine without
+                        # major surgery on the deployment and release processes.
+                        # See: https://github.com/pantsbuild/pants/issues/5061
+                        'https://dl.bintray.com/pantsbuild/bin/build-support'],
                help='List of urls from which binary tools are downloaded.  Urls are searched in '
                     'order until the requested path is found.')
       register('--fetch-timeout-secs', type=int, default=30, advanced=True,


Test patch:
Repository: pantsbuild/pants

Issue:
Extract a ResettablePool struct from PosixFS
The pool needs sharing in more places, while preserving the ability to clear the pool before forking and restore it afterward.


Discussion:

Resolving patch:
diff --git a/src/python/pants/bin/daemon_pants_runner.py b/src/python/pants/bin/daemon_pants_runner.py
--- a/src/python/pants/bin/daemon_pants_runner.py
+++ b/src/python/pants/bin/daemon_pants_runner.py
@@ -128,7 +128,12 @@ def run(self):
     self.daemonize(write_pid=False)
 
   def pre_fork(self):
-    """Pre-fork callback executed via ProcessManager.daemonize()."""
+    """Pre-fork callback executed via ProcessManager.daemonize().
+
+    The scheduler has thread pools which need to be re-initialized after a fork: this ensures that
+    when the pantsd-runner forks from pantsd, there is a working pool for any work that happens
+    in that child process.
+    """
     if self._graph_helper:
       self._graph_helper.scheduler.pre_fork()
 


Test patch:
Repository: pantsbuild/pants

Issue:
The `pantsbuild.pants.contrib.jax_ws` package does not auto-register BUILD aliases.
In particular, the `jax_ws_library` target type is not exposed and so users of the plugin need to work around in `pants.ini` with a manual `backend_packages` addition that is normally not needed after specifying the plugin:
```ini
backend_packages: +[
    "pants.contrib.jax_ws",
  ]
```


Discussion:
This fix should probably be backported to 1.3.x so that the 1.3.1 final has a fully automatic jax_ws contrib plugin working.

Resolving patch:
diff --git a/contrib/jax_ws/src/python/pants/contrib/jax_ws/register.py b/contrib/jax_ws/src/python/pants/contrib/jax_ws/register.py
--- a/contrib/jax_ws/src/python/pants/contrib/jax_ws/register.py
+++ b/contrib/jax_ws/src/python/pants/contrib/jax_ws/register.py
@@ -5,8 +5,8 @@
 from __future__ import (absolute_import, division, generators, nested_scopes, print_function,
                         unicode_literals, with_statement)
 
-from pants.goal.task_registrar import TaskRegistrar as task
 from pants.build_graph.build_file_aliases import BuildFileAliases
+from pants.goal.task_registrar import TaskRegistrar as task
 
 from pants.contrib.jax_ws.targets.jax_ws_library import JaxWsLibrary
 from pants.contrib.jax_ws.tasks.jax_ws_gen import JaxWsGen


Test patch: