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

Issue:
(VS2017) error C2397: conversion from 'long' to 'uint32_t' requires a narrowing conversion on Debug env
## 🐛 Bug
The same issue #14961(windows libtorch1.0 : cpp_export in Visual studio 2015: error C2397: conversion from 'long' to 'uint32_t' requires a narrowing conversion) was closed, but it happens the same on most recent Visual Studio 2017, version 15.9.4.
It only occurs on Debug environment, and runs fine on Release.

## To Reproduce
```
#pragma once
#include "torch/nn.h"
```

Detailed code explanation below

## Environment
 - PyTorch Version (e.g., 1.0): 1.0
 - OS (e.g., Linux): Windows 10 x64
 - How you installed PyTorch (`conda`, `pip`, source): Libtorch
 - CUDA/cuDNN version: 10, 7.3
 - GPU models and configuration: 1050
 - Any other relevant information:

## Additional context


According to MSDN, error C2397 happens when narrowing down occurs on uniform initialization.
So I digged down the code and found the code which causes this error.

```
// c10/util/Exception.h
// Line 49
Error(SourceLocation source_location, const std::string& msg);

// Line 120
#define AT_ERROR(...) \
  throw ::c10::Error({__func__, __FILE__, __LINE__}, ::c10::str(__VA_ARGS__))

// c10/util/StringUtil.h
// Line 69
struct C10_API SourceLocation {
  const char* function;
  const char* file;
  uint32_t line;
};
```

It seems that \_\_LINE\_\_ macro value is treated as long type, so it tries to narrow down to the 'uint32_t line' constructor parameter, which causes this error.


Discussion:

Resolving patch:
diff --git a/caffe2/python/__init__.py b/caffe2/python/__init__.py
--- a/caffe2/python/__init__.py
+++ b/caffe2/python/__init__.py
@@ -1,5 +1,8 @@
 from __future__ import absolute_import, division, print_function, unicode_literals
 from caffe2.proto import caffe2_pb2
+import os
+import sys
+import platform
 # TODO: refactor & remove the following alias
 caffe2_pb2.CPU = caffe2_pb2.PROTO_CPU
 caffe2_pb2.CUDA = caffe2_pb2.PROTO_CUDA
@@ -10,3 +13,22 @@
 caffe2_pb2.HIP = caffe2_pb2.PROTO_HIP
 caffe2_pb2.COMPILE_TIME_MAX_DEVICE_TYPES = caffe2_pb2.PROTO_COMPILE_TIME_MAX_DEVICE_TYPES
 caffe2_pb2.ONLY_FOR_TEST = caffe2_pb2.PROTO_ONLY_FOR_TEST
+
+if platform.system() == 'Windows':
+    # first get nvToolsExt PATH
+    def get_nvToolsExt_path():
+        NVTOOLEXT_HOME = os.getenv('NVTOOLSEXT_PATH', 'C:\\Program Files\\NVIDIA Corporation\\NvToolsExt')
+
+        if os.path.exists(NVTOOLEXT_HOME):
+            return NVTOOLEXT_HOME + '\\bin\\x64\\'
+        else:
+            return ''
+
+    py_dll_path = os.path.join(os.path.dirname(sys.executable), 'Library\\bin')
+    th_root = os.path.join(os.path.dirname(os.path.dirname(os.path.dirname(__file__))), 'torch')
+    th_dll_path = th_root + '\\lib\\'
+
+    dll_paths = [th_dll_path, py_dll_path, get_nvToolsExt_path(), os.environ['PATH']]
+
+    # then add the path to env
+    os.environ['PATH'] = ';'.join(dll_paths)


Test patch:
Repository: pytorch/pytorch

Issue:
Tensor __radd__ type hint issue
## 🐛 Bug

Type checking any code adding a float or integer to a tensor (`__radd__` method) results in a type checking error when using nightly build (but not in release). This is causing type checking failures for downstream applications, particularly in Captum.


## To Reproduce

Run mypy on any code applying radd, such as:
```
import torch
ten = torch.tensor([1.0, 2.0, 3.0])
print(7 + ten)
```
Mypy Error:
`test_file.py:4: error: Unsupported operand types for + ("int" and "Tensor")
`

## Expected behavior
No mypy error should occur, as long as the `__radd__` method is appropriately type hinted.

## Additional context

It seems like the problem is caused by a missing comma in this PR: #34552
In tools/pyi/gen_pyi.pi, there should be a comma after 'floor_divide', right now, without a comma, it is concatenating the string with 'radd' and just generating a type hint for an invalid method 'floor_divider_add'

cc @ezyang


Discussion:
I tried to reproduce on master:
```
mypy -c "import torch; ten = torch.tensor([1.0, 2.0, 3.0]); print(ten + 7)"
Success: no issues found in 1 source file
```
@vivekmig can you please specify exact steps to reproduce?
@pbelevich Whoops, sorry had a typo in the example, should be the reverse, `print(7 + ten)`. Fixed now.
@vivekmig I was able to reproduce, thanks!

Resolving patch:
diff --git a/tools/pyi/gen_pyi.py b/tools/pyi/gen_pyi.py
--- a/tools/pyi/gen_pyi.py
+++ b/tools/pyi/gen_pyi.py
@@ -176,7 +176,7 @@ def arg_to_type_hint(arg):
 
 
 binary_ops = ('add', 'sub', 'mul', 'div', 'pow', 'lshift', 'rshift', 'mod', 'truediv',
-              'matmul', 'floordiv', 'floor_divide'
+              'matmul', 'floordiv', 'floor_divide',
               'radd', 'rsub', 'rmul', 'rtruediv', 'rfloordiv', 'rpow',          # reverse arithmetic
               'and', 'or', 'xor',                   # logic
               'iadd', 'iand', 'idiv', 'ilshift', 'imul',


Test patch:
Repository: pytorch/pytorch

Issue:
`--dry-run` flag doesn't print anything (`tools/linter/clang_tidy.py`)
## Bug

Running `tools/linter/clang_tidy.py` with the `--dry-run` option doesn't print anything.

## To Reproduce

Run the following command
```
python3 tools/linter/clang_tidy.py --paths torch/csrc/fx --dry-run
```
Output:
```
```

Expected Output:
```
clang-tidy -p build -config '{"InheritParentConfig": true, "Checks": " bugprone-*, -bugprone-forward-declaration-namespace, -bugprone-macro-parentheses, -bugprone-lambda-function-name, -bugprone-reserved-identifier, cppcoreguidelines-*, -cppcoreguidelines-avoid-magic-numbers, -cppcoreguidelines-interfaces-global-init, -cppcoreguidelines-macro-usage, -cppcoreguidelines-owning-memory, -cppcoreguidelines-pro-bounds-array-to-pointer-decay, -cppcoreguidelines-pro-bounds-constant-array-index, -cppcoreguidelines-pro-bounds-pointer-arithmetic, -cppcoreguidelines-pro-type-cstyle-cast, -cppcoreguidelines-pro-type-reinterpret-cast, -cppcoreguidelines-pro-type-static-cast-downcast, -cppcoreguidelines-pro-type-union-access, -cppcoreguidelines-pro-type-vararg, -cppcoreguidelines-special-member-functions, -facebook-hte-RelativeInclude, hicpp-exception-baseclass, hicpp-avoid-goto, modernize-*, -modernize-concat-nested-namespaces, -modernize-return-braced-init-list, -modernize-use-auto, -modernize-use-default-member-init, -modernize-use-using, -modernize-use-trailing-return-type, performance-*, -performance-noexcept-move-constructor, -performance-unnecessary-value-param, ", "HeaderFilterRegex": "torch/csrc/.*", "AnalyzeTemporaryDtors": false, "CheckOptions": null}' torch/csrc/fx/fx_init.cpp
```

cc @pytorch/pytorch-dev-infra


Discussion:

Resolving patch:
diff --git a/tools/linter/clang_tidy.py b/tools/linter/clang_tidy.py
--- a/tools/linter/clang_tidy.py
+++ b/tools/linter/clang_tidy.py
@@ -377,6 +377,8 @@ def main() -> None:
                 shutil.copyfile(fname, mapped_fname)
 
     pwd = os.getcwd() + "/"
+    if options.dry_run:
+        print(clang_tidy_output)
     for line in clang_tidy_output.splitlines():
         if line.startswith(pwd):
             print(line[len(pwd):])


Test patch:
Repository: pytorch/pytorch

Issue:
torch.distributed.launch/run - make OMP warning message a log.warning rather than a stdout print
## 🚀 Feature
Make the warning message about the default `OMP_NUM_THREADS` set by `torch.distributed.launch` and `torch.distributed.run` use `logger.warning(msg)` rather than a print statement.

## Motivation
Users can set the `LOGLEVEL` environment variable when using `torch.distributed.launch` and `torch.distributed.run` CLI utils to control the python log level of the launcher program. However regardless of the overriden `LOGLEVEL` the following message prints:

```
$ python -m torch.distributed.run ~/test.py

*****************************************
Setting OMP_NUM_THREADS environment variable for each process to be 1 in default, to avoid your system being overloaded, please further tune the variable for optimal performance in your application as needed.
*****************************************
```

This is because in https://github.com/pytorch/pytorch/blob/master/torch/distributed/run.py#L523-L530 the message
is printed using `print(msg)` rather than `log.warning(msg)`.

## Pitch
Simply change the `print()` to `log.warning()`.

## Alternatives
N/A - simple change.

## Additional context
Came up as part of the discussion https://github.com/pytorch/pytorch/issues/60716#issuecomment-872469733. The OMP message was left untouched for backwards compatibility and in torch<1.9.0 `torch.distributed.launch` used to not support user-overrides for `LOGLEVEL` (in torch-1.9.0 it does). Now that users do have an option to pass a custom LOGLEVEL it makes sense to make the OMP printout a `log.warning` so that users only interested in `LOGLEVEL=ERROR` don't have to see this message every time.



Discussion:
IMPORTANT! - #60925  needs to land before working on this as #60925 fixes a few other issues with the distributed.launch CLI that needs to be present for one to properly test and validate the proposed change.

Resolving patch:
diff --git a/torch/distributed/run.py b/torch/distributed/run.py
--- a/torch/distributed/run.py
+++ b/torch/distributed/run.py
@@ -520,7 +520,7 @@ def config_from_args(args) -> Tuple[LaunchConfig, Union[Callable, str], List[str
     nproc_per_node = determine_local_world_size(args.nproc_per_node)
     if "OMP_NUM_THREADS" not in os.environ and nproc_per_node > 1:
         omp_num_threads = 1
-        print(
+        log.warning(
             f"*****************************************\n"
             f"Setting OMP_NUM_THREADS environment variable for each process to be "
             f"{omp_num_threads} in default, to avoid your system being overloaded, "


Test patch:
Repository: pytorch/pytorch

Issue:
Functional API for FileLister
### 🚀 The feature, motivation and pitch

Similar to https://github.com/pytorch/data/issues/387

This allows for 
```python
IterableWrapper([...]).list_file()
```

### Alternatives

_No response_

### Additional context

_No response_

cc @VitalyFedyunin @ejguan @NivekT


Discussion:

Resolving patch:
diff --git a/torch/utils/data/datapipes/iter/filelister.py b/torch/utils/data/datapipes/iter/filelister.py
--- a/torch/utils/data/datapipes/iter/filelister.py
+++ b/torch/utils/data/datapipes/iter/filelister.py
@@ -1,5 +1,8 @@
 from typing import Iterator, List, Sequence, Union
 
+
+from torch.utils.data.datapipes._decorator import functional_datapipe
+
 from torch.utils.data.datapipes.datapipe import IterDataPipe
 from torch.utils.data.datapipes.iter import IterableWrapper
 from torch.utils.data.datapipes.utils.common import get_file_pathnames_from_root
@@ -7,6 +10,7 @@
 __all__ = ["FileListerIterDataPipe", ]
 
 
+@functional_datapipe("list_files")
 class FileListerIterDataPipe(IterDataPipe[str]):
     r"""
     Given path(s) to the root directory, yields file pathname(s) (path + filename) of files within the root directory.


Test patch:
diff --git a/test/test_datapipe.py b/test/test_datapipe.py
--- a/test/test_datapipe.py
+++ b/test/test_datapipe.py
@@ -300,6 +300,14 @@ def test_listdirfiles_iterable_datapipe(self):
             self.assertTrue(pathname in self.temp_files)
         self.assertEqual(count, 2 * len(self.temp_files))
 
+        # test functional API
+        datapipe = datapipe.list_files()
+        count = 0
+        for pathname in datapipe:
+            count += 1
+            self.assertTrue(pathname in self.temp_files)
+        self.assertEqual(count, 2 * len(self.temp_files))
+
     def test_listdirfilesdeterministic_iterable_datapipe(self):
         temp_dir = self.temp_dir.name
Repository: pytorch/pytorch

Issue:
UnboundLocalError: local variable 'ws' referenced before assignment
https://github.com/pytorch/pytorch/blob/c10908cd41f6fe18a4d61704d7013d46bb05aeaf/torch/utils/data/dataloader.py#L261

`ws` is not defined within the elif statement.

cc @VitalyFedyunin @ejguan @NivekT


Discussion:
cc: @ejguan to take a look
Thank you finding this bug. Sending a patch now.

Resolving patch:
diff --git a/torch/utils/data/dataloader.py b/torch/utils/data/dataloader.py
--- a/torch/utils/data/dataloader.py
+++ b/torch/utils/data/dataloader.py
@@ -256,6 +256,7 @@ def __init__(self, dataset: Dataset[T_co], batch_size: Optional[int] = 1,
                 torch.utils.data.graph_settings.apply_sharding(self.dataset, ws, rank)
         elif isinstance(self.dataset, MapDataPipe):
             self.dataset = _MapDataPipeSerializationWrapper(self.dataset)
+            ws, rank = _get_distributed_settings()
             if num_workers > 0:
                 self.worker_init_fn = functools.partial(
                     _sharding_worker_init_fn, self.worker_init_fn, ws, rank)


Test patch:
Repository: pytorch/pytorch

Issue:
Distributed shared seed in DataLoader should be moved to cuda with NCCL Process Group
### 🐛 Describe the bug

After this https://github.com/pytorch/pytorch/pull/78765 is landed, when running training script in multi-GPUs environment with `DataLoader` + `DataPipe`, there will an Error raised `RuntimeError: Tensors must be CUDA and dense`

See the user reported issue: https://fburl.com/teyw5gen

### Versions

nightly 

cc @SsnL @VitalyFedyunin @ejguan @NivekT @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @kwen2501


Discussion:

Resolving patch:
diff --git a/torch/utils/data/dataloader.py b/torch/utils/data/dataloader.py
--- a/torch/utils/data/dataloader.py
+++ b/torch/utils/data/dataloader.py
@@ -561,21 +561,28 @@ def _create_warning_msg(num_worker_suggest, num_worker_created, cpuset_checked):
 
     def _get_shared_seed(self):
         if isinstance(self.dataset, IterDataPipe):
-            _shared_tensor_seed = torch.empty((), dtype=torch.int64).random_(generator=self.generator)
+            _shared_seed = torch.empty((), dtype=torch.int64).random_(generator=self.generator).item()
             if dist.is_available() and dist.is_initialized():
                 rank = dist.get_rank()
+                ws = dist.get_world_size()
+                store = dist.distributed_c10d._get_default_store()
                 if rank == 0:
-                    ws = dist.get_world_size()
-                    reqs = []
-                    for rank_id in range(1, ws):
-                        req = dist.isend(tensor=_shared_tensor_seed, dst=rank_id, tag=rank_id)
-                        reqs.append(req)
-                    for req in reqs:
-                        req.wait()
+                    store.set("_dl_shared_seed", str(_shared_seed))
+                    # Reset after all distributed processes have received the shared seed
+                    store.add("_dl_shared_seed_recv_cnt", 1)
+                    _shared_seed_recv_cnt = 1
+                    while _shared_seed_recv_cnt != ws:
+                        _shared_seed_recv_cnt = int(store.get("_dl_shared_seed_recv_cnt"))
+                    store.set("_dl_shared_seed", "")
+                    store.add("_dl_shared_seed_recv_cnt", -ws)
+                    assert int(store.get("_dl_shared_seed_recv_cnt")) == 0
                 else:
-                    dist.recv(tensor=_shared_tensor_seed, src=0, tag=rank)
-            _shared_seed = _shared_tensor_seed.item()
-            del _shared_tensor_seed
+                    _shared_seed_str = ""
+                    store.wait(["_dl_shared_seed"], _utils.MP_STATUS_CHECK_INTERVAL)
+                    while len(_shared_seed_str) == 0:
+                        _shared_seed_str = store.get("_dl_shared_seed")
+                    store.add("_dl_shared_seed_recv_cnt", 1)
+                    _shared_seed = int(_shared_seed_str)
             return _shared_seed
         else:
             return None


Test patch:
Repository: pytorch/pytorch

Issue:
Missing packaging dependency in torch 2.1.x
### 🐛 Describe the bug

Hi,
[torch.utils.tensorboard requires "packaging"](https://github.com/pytorch/pytorch/blob/fa1ccc34c4f65756bc50c3e3ab135c88b175b18c/torch/utils/tensorboard/__init__.py#L2C1-L3C1) to be installed but that dependency is [missing on torch 2.1.x](https://github.com/pytorch/pytorch/blob/v2.1.2-rc1/requirements.txt).

Here's some example code:
```python
from torch.utils.tensorboard import SummaryWriter
```

The links above point to a RC version of 2.1.2 but this is also the case for 2.1.1. Would it be possible to make a patch release to add the dependency?

### Versions

Python version: 3.9.16 (main, Dec  7 2022, 10:16:11)  [Clang 14.0.0 (clang-140[0.0.29.202](http://0.0.29.202/)
)] (64-bit runtime)
Python platform: macOS-13.6.1-x86_64-i386-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Intel(R) Core(TM) i5-7287U CPU @ 3.30GHz

Versions of relevant libraries:
[pip3] numpy==1.23.5
[pip3] torch==2.1.1
[pip3] torchvision==0.16.1
[conda] Could not collect


Discussion:
Worth mentioning that the change is already on main so should just be missing a release.
@sachahu1 is this a new dependency (that tensorboard have added) or was it always missing?
Please note, that in main this was already reverted in favor of just vendoring `packaging.Version` class, see https://github.com/pytorch/pytorch/pull/114108

To clarify: this does not sound like a regression i.e. imo does not clarify for cherry-pick, but should be fixed in trunk (if tensorboard is still maintained)
@malfet This looks like it's a torch dependency and is used to check the tensorboard package version. If `packaging` isn't going to be added to the torch dependencies then the code should probably be fixed to remove the missing dependency. 

Does seem like using `packaging.Version` for this use-case might be overkill if it isn't used elsewhere? I think removing the dependency from the code might be the preferred option.

Here's the code I'm referring to:
```python
from packaging.version import Version

if not hasattr(tensorboard, "__version__") or Version(
    tensorboard.__version__
) < Version("1.15"):
    raise ImportError("TensorBoard logging requires TensorBoard version 1.15 or above")

del Version
```
link: [`torch.utils.tensorboard.__init__.py`](https://github.com/pytorch/pytorch/blob/bcfca41a2a8d80ca186e2550e4bca1a52e7873ff/torch/utils/tensorboard/__init__.py#L2-L9)

Resolving patch:
diff --git a/torch/utils/tensorboard/__init__.py b/torch/utils/tensorboard/__init__.py
--- a/torch/utils/tensorboard/__init__.py
+++ b/torch/utils/tensorboard/__init__.py
@@ -1,5 +1,5 @@
 import tensorboard
-from packaging.version import Version
+from torch._vendor.packaging.version import Version
 
 if not hasattr(tensorboard, "__version__") or Version(
     tensorboard.__version__


Test patch:
Repository: pytorch/pytorch

Issue:
Incorrect line in description of torch.frombuffer() method
### 📚 The doc issue

As per the documentation on `frombuffer` method of `torch`:
```
torch.frombuffer(buffer, *, dtype, count=-1, offset=0, requires_grad=False) → [Tensor](https://pytorch.org/docs/stable/tensors.html#torch.Tensor)
```
As per the documentation, either of the following conditions should be true:

```
1. count is a positive non-zero number, and the total number of bytes in the buffer is less than offset plus count times the size (in bytes) of [dtype](https://pytorch.org/docs/stable/tensor_attributes.html#torch.dtype).

2. count is negative, and the length (number of bytes) of the buffer subtracted by the offset is a multiple of the size (in bytes) of [dtype](https://pytorch.org/docs/stable/tensor_attributes.html#torch.dtype).
```

In condition number 1, it seems that it is wrongly written that `total number of bytes in the buffer is less than offset plus count times the size (in bytes) of dtype`. This should be changed to say that `total number of bytes in the buffer is **more** than offset plus count times the size (in bytes) of dtype`, so that when we read the buffer, there is ample data to read taking into account the `(offset + count) * dtype`, and we don't accidentally end up reading memory slots dedicated to something else than the buffer.

### Suggest a potential alternative/fix

_No response_

cc @svekars @carljparker @albanD


Discussion:
Thanks for the report, feel free to send a PR to fix the typo, thanks!
Hi, thanks for your reply. I would love to submit a PR. Please allow me some time though...Thanks
Hello, I see this issue has been inactive and the type is still present in the [documentation](https://pytorch.org/docs/stable/generated/torch.frombuffer.html).
@mg104 Are you still working or this, or can I fix the typo?
Hi @albanD. Since I've got no reply from the issue author, can I go ahead and submit a PR for this?
Sounds good!


Resolving patch:
diff --git a/torch/_torch_docs.py b/torch/_torch_docs.py
--- a/torch/_torch_docs.py
+++ b/torch/_torch_docs.py
@@ -4428,7 +4428,7 @@ def merge_dicts(*dicts):
 Note that either of the following must be true:
 
 1. :attr:`count` is a positive non-zero number, and the total number of bytes
-in the buffer is less than :attr:`offset` plus :attr:`count` times the size
+in the buffer is more than :attr:`offset` plus :attr:`count` times the size
 (in bytes) of :attr:`dtype`.
 
 2. :attr:`count` is negative, and the length (number of bytes) of the buffer


Test patch: