gopikrsmscs/torch-issues huggingface dataset:
Workflows fail silently when the workflow file is invalid
Labels: module: ci, triaged

### 🐛 Describe the bug

Sometimes the failed workflows don't actually show up as failed in the CI on the PR page, such as when there's an invalid  workflow file ([example](https://github.com/pytorch/pytorch/actions/runs/2618689292))

I’d expect the workflow to quickly show a clear error in the UI.

Nikita’s [added a workaround](https://github.com/pytorch/pytorch/pull/81521/files#diff-8dbcc9b8dc59448e6ad908516e60cd84cbcb0c6dd2aca2a51bc0e5b3fc0e120fR1042) to ensure we don’t merge PRs with these silent failures, and it would be great to make sure we surface these failures in the signalbox as well.  

Right now, the CI can still appear to be succeeding (even if merges will get blocked).

### Versions

n/a

cc @seemethere @malfet @pytorch/pytorch-dev-infra
Rename DispatchKey Dense/Sparse/etc to DenseFunctionality/SparseFunctionality, use original name for alias
Labels: module: internals, triaged

### 🚀 The feature, motivation and pitch

This means you could register a kernel as "Sparse" and it would apply to all sparse backends, instead of having to register SparseCPU, SparseCUDA one by one as we do today

### Alternatives

_No response_

### Additional context

_No response_

cc @ezyang @bhosmer @smessmer @ljk53 @bdhirsh
Modernize logging tensor in torch.testing._internal
Labels: module: internals, module: logging, triaged

### 🐛 Describe the bug

I wrote a better version of logging tensor mode at https://github.com/albanD/subclass_zoo/blob/main/logging_mode.py
let's upstream it to PyTorch

Improvements include proper handling of lists of tensors, dtype and size info in the logs, and cleaner code structure. In particular, I want to get rid of LoggingTensor as a construct and have this be mode only.

### Versions

master

cc @ezyang @bhosmer @smessmer @ljk53 @bdhirsh
BatchNorm for complex tensor
Labels: triaged, module: complex, module: primTorch

### 🚀 The feature, motivation and pitch

I am working on a network that takes into consider phase information in speech processing, and would like batchnorm for complex tensor to be possible.

Similar to #47052, #46642

### Additional context

Are there any special points to consider when adding/implementing this feature because of the complex type?

cc @ezyang @anjali411 @dylanbespalko @mruberry @Lezcano @nikitaved @ngimel @albanD
DISABLED test_non_contiguous_tensors_nn_ConvTranspose1d_cuda_complex32 (__main__.TestModuleCUDA)
Labels: module: nn, triaged, module: flaky-tests, module: complex, skipped

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_non_contiguous_tensors_nn_ConvTranspose1d_cuda_complex32&suite=TestModuleCUDA&file=test_modules.py) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/7415127953).

Over the past 3 hours, it has been determined flaky in 2 workflow(s) with 3 red and 2 green.

cc @albanD @mruberry @jbschlosser @walterddr @kshitij12345 @saketh-are @ezyang @anjali411 @dylanbespalko @Lezcano @nikitaved
Support JaggedTensor/KeyedJaggedTensor from TorchRec in TorchDynamo
Labels: triaged, oncall: pt2

Currently if [JaggedTensor](https://github.com/pytorch/torchrec/blob/20f543ee3700f2ebb27be6e80d636bd5dd0d7f3c/torchrec/sparse/jagged_tensor.py#L160)/[KeyedJaggedTensor](https://github.com/pytorch/torchrec/blob/20f543ee3700f2ebb27be6e80d636bd5dd0d7f3c/torchrec/sparse/jagged_tensor.py#L614) is used we will see the following error in TorchDyanmo
```
torchdynamo.exc.Unsupported: call_function UserDefinedObjectVariable(JaggedTensorMeta) [] {'keys': ListVariable(), 'values': TensorVariable(), 'length_per_key': ListVariable()}
``` 

cc @ezyang @soumith @msaroufim @wconstab @ngimel @bdhirsh
Inconsistent naming convention for end of enum in DispatchKey
Labels: triaged, module: dispatch

### 🐛 Describe the bug

Here is a clear contradiction:

```
  EndOfBackendKeys = PrivateUse3Bit,
```

but

```
  EndOfFunctionalityKeys, // End of functionality keys.
```

This means for iterating through backend keys you should <= the ending, but for functionality keys you should < the ending. It is inconsistent.

----

Let's take a step back. There are a few problems with our naming conventions here.

1. It's not clear if end is inclusive or exclusive
2. It's not clear if start is inclusive or exclusive
3. It's not clear if length includes the zero-valued invalid key

We should establish clear definitions for each of these (possibly renaming if the existing names are ambiguous) and then apply this uniformly.

My preference is that:
1. End is exclusive
2. Start is inclusive
3. Length includes zero-valued key

cc @bdhirsh 

### Versions

master
PyTorch Embedding Op with max_norm is not working as expected
Labels: module: cuda, triaged, module: norms and normalization, module: embedding, bug

### 🐛 Describe the bug

The behavior of renorm inside the `max_norm` will renorm the weight to the norm same as `max_norm` when it is specified.

However, under GPU and if the input is multi-dimensional (like dim = 3). Its behavior is not expected and also weight will be renormed to the wrong norm (like less than `max_norm`)

To repo this here is code snippet:
```
import torch

input_size = [36, 15, 48] 
embedding_size = 28
embedding_dim = 5

embedding = torch.nn.Embedding(embedding_size, embedding_dim, max_norm=2.0, norm_type=2.0).cuda()
weight_norm = torch.linalg.norm(embedding.weight, dim=-1).clone()
original_weight_norm = weight_norm.clone()
print("weight_norm", original_weight_norm)
weight_norm[weight_norm > 2.0] = 2.0
print("expected weight_norm", weight_norm)

for i in range(4):
    input = torch.randint(0, embedding_size, tuple(input_size)).cuda()
    torch.nn.functional.embedding(input, embedding.weight, max_norm=2.0, norm_type=2.0)
actual_weight_norm = torch.linalg.norm(embedding.weight, dim=-1)
print("actual weight ", actual_weight_norm)
delta = actual_weight_norm - weight_norm
threshold = 0.01
print(torch.allclose(weight_norm, actual_weight_norm), "norm more than threshold ", threshold, delta[torch.abs(delta) > threshold])
```

One example output is like:
```
weight_norm tensor([2.0776, 2.0551, 2.6955, 1.9832, 1.6644, 1.8127, 2.5646, 2.5205, 1.6097,
        3.0849, 1.6583, 1.6348, 2.7448, 1.6877, 1.7610, 1.9241, 0.8003, 0.7706,
        2.2592, 2.0385, 2.6742, 1.5317, 2.1481, 0.9371, 1.6462, 1.7186, 1.2157,
        2.8872], device='cuda:0', grad_fn=<CloneBackward0>)
expected weight_norm tensor([2.0000, 2.0000, 2.0000, 1.9832, 1.6644, 1.8127, 2.0000, 2.0000, 1.6097,
        2.0000, 1.6583, 1.6348, 2.0000, 1.6877, 1.7610, 1.9241, 0.8003, 0.7706,
        2.0000, 2.0000, 2.0000, 1.5317, 2.0000, 0.9371, 1.6462, 1.7186, 1.2157,
        2.0000], device='cuda:0', grad_fn=<IndexPutBackward0>)
actual weight  tensor([2.0000, 2.0000, 2.0000, 1.9832, 1.6644, 1.8127, 2.0000, 1.5870, 1.6097,
        1.2966, 1.6583, 1.6348, 2.0000, 1.6877, 1.7610, 1.9241, 0.8003, 0.7706,
        1.7705, 2.0000, 1.8975, 1.5317, 2.0000, 0.9371, 1.6462, 1.7186, 1.2157,
        1.8775], device='cuda:0', grad_fn=<LinalgVectorNormBackward0>)
False norm more than threshold  0.01 tensor([-0.4130, -0.7034, -0.2295, -0.1025, -0.1225], device='cuda:0',
       grad_fn=<IndexBackward0>)
```

Sometimes, you need to run it more than once to repo but it is usually within 2-3 runs.

### Versions

Run on the latest night build and Linux and cuda 11.0

cc @ngimel
Dispatcher debug/logging mode
Labels: triaged, module: dispatch

### 🚀 The feature, motivation and pitch

I recently ran into a situation where I was trying to understand why the dispatcher dispatched the way it had, and it (re)occurred to me that having a way of turning on chatty dispatcher mode would be pretty useful. What I'd like to see is a log something like (maybe done more compactly):

```
call aten::add
argument 1 keys: [Dense], [CPUBit]
argument 2 keys: [Python, PythonSnapshotTLS], [MetaBit]
merged keys: [Python, PythonSnapshotTLS, ...], [CPUBit, MetaBit]
include, exclude set: [], [Autograd]
dispatching to: DenseCPU
```

for every operator going through the dispatcher.

Probably this should be done using the profiler. cc @robieta

### Alternatives

_No response_

### Additional context

_No response_
Python operator registration API for subclasses
Labels: feature, triaged, module: dispatch, module: __torch_dispatch__

### 🚀 The feature, motivation and pitch

We have python op registration by @anjali411 but this is only allowed for dispatch keys. A nice extension would be to allow tensor subclasses to be passed in lieu of dispatch key and get the same behavior. This would be an alternative to defining `__torch_dispatch__` but would have better performance in the passthrough case as we could bypass calling into Python in that case.

### Alternatives

_No response_

### Additional context

_No response_

cc @Chillee @ezyang @zou3519 @albanD @samdow
Provide an option to disable CUDA_GCC_VERSIONS
Labels: module: build, triaged

### 🚀 The feature, motivation and pitch

I really understand the motivations of recent additions to CUDA_GCC_VERSIONS that were done in
* https://github.com/pytorch/pytorch/commit/86deecd7be248016d413e9ad6f5527a70c88b454
* https://github.com/pytorch/pytorch/pull/63230

I do think they are a step in the right direction toward improving the situation (xref https://github.com/pytorch/pytorch/issues/55267)

I'm wondering if you could add an option, as an environment variable, for us to ignore it. The motivation is that I believe that it is  possible to patch up the GCC 10 compiler with a small patch to help nvidia compatibility.

https://github.com/conda-forge/ctng-compilers-feedstock/blob/main/recipe/meta.yaml#L22=

### Alternatives

I can patch things out.... However, I would rather have the override done by other packagers that assert they know what they are doing.

You can also patch things out with a sed command
```
sed -i '/ (MINIMUM_GCC_VERSION,/d' ${SP_DIR}/torch/utils/cpp_extension.py
```

### Additional context

The other motivation is that soon enough, the GCC 11 compilers should be compatible with nvidia.

I also believe that 10.4 is compatible with the nvcc

cc @malfet @seemethere
Register refs for CompositeImplicitAutograd ops as decompositions
Labels: triaged, module: primTorch

There are some ops that explicitly don't have decompositions registered because they are CompositeImplicitAutograd

https://github.com/pytorch/pytorch/blob/bf36d8b987b2ef2fd9cb26bae3acc29c03b05072/test/test_ops.py#L1538-L1567

However, it is still possible to observe them in inference mode (or possibly if CompositeImplicitAutograd is overridden by a different kernel)
```python
from torch.testing._internal.logging_tensor import capture_logs_with_logging_tensor_mode

with capture_logs_with_logging_tensor_mode() as logs:
    with torch.inference_mode():
        a = torch.ones(2, 2)
        a.reshape(-1)

print('\n'.join(logs))
# $0 = torch._ops.aten.ones.default([2, 2], dtype=torch.float32, device=device(type='cpu'), pin_memory=False)
# $1 = torch._ops.aten.reshape.default($0, [-1])
```
When registering these ops as decompositions, to appease the test that detects that we have indeed registered it in the table, we may need to specify what op it decomposes into:

https://github.com/pytorch/pytorch/blob/443b13fa232c52bddf20726a6da040d8957a3c49/torch/testing/_internal/common_methods_invocations.py#L744-L745

cc @ezyang @mruberry @ngimel
[packaging] Conda install missing python local version label (+cu123 or +cpu)
Labels: oncall: releng, triaged

### 🐛 Describe the bug

I'm installing pytorch through Conda then using poetry in my projects.
The issue is that when I use the recommended installation method for pytorch (`conda install -y -c pytorch pytorch==1.11.0 cudatoolkit=11.3`), I end up with:
`conda list`: `pytorch 1.11.0 py3.7_cuda11.3_cudnn8.2.0_0 pytorch`.
`pip list`: `torch 1.11.0`.

My issue is that conda installed torch `1.11.0+cu113` but did not include the local version label (`+cu113`), so then when I use pip or poetry, it thinks it needs to replace torch `1.11.0` by `1.11.0+cu113`.

I use this dirty hack to fix the package version of torch:
```bash
mv /[...]/conda/lib/python3.7/site-packages/torch-1.11.0-py3.7.egg-info/ /[...]/conda/lib/python3.7/site-packages/torch-1.11.0+cu113-py3.7.egg-info/
sed -i -E 's/(Version: [^+]+)\n/\1+cu113\n/' /opt/conda/lib/python3.7/site-packages/torch-1.11.0+cu113-py3.7.egg-info/PKG-INFO
```

### Versions

PyTorch version: 1.11.0
Is debug build: False
CUDA used to build PyTorch: 11.3
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.3 LTS (x86_64)
GCC version: Could not collect
Clang version: Could not collect
CMake version: Could not collect
Libc version: glibc-2.17

Python version: 3.7.13 (default, Mar 29 2022, 02:18:16)  [GCC 7.5.0] (64-bit runtime)
RFC: auto-generated plain Tensor argument only sparse primitives
Labels: module: sparse, triaged

### 🐛 Describe the bug

When we say `at::add(sparse_x, sparse_y)`, this is an operator that takes in two sparse tensors and produces a sparse tensor. This requires a backend compiler to have a model of what it means to be a sparse tensor. Sometimes, this is inconvenient for a backend; the backend would rather have the input all be in terms of dense inputs.

We can help by generating sparse prims that are expressed entirely in terms of dense tensors. So for example, the sparse variant of at::add above would be `sparse_prims::add(self_sparse_dim: int, self_dense_dim: int, self_size: int[], self_indices: Tensor, self_values: Tensor, other_sparse_dim: int, other_dense_dim: int, other_size: int[], other_indices: Tensor, other_values: Tensor) -> (int, int, int[], Tensor, Tensor)`. Essentially, each of the substantive fields in the sparse tensor (sparse dim, dense dim, size, indices and values) has been inlined into the function argument. The new function signature is Tensors only and doesn't have any explicit sparse tensors.

Some notes:

* In many situations, a sparse operation isn't supported in full generality. For example, the add signature above suggests that it is ok to mix different amounts of sparse/dense dims in addition. In actuality, they have to be the same (so the second pair of sparse dense dims could be deleted.) This simplification cannot be done mechanically, you have to know about the preconditions for the function. But we could imagine further decomposing these prims by hand into simpler versions, eliminating the need for backends to do this error checking.
* You need separate sparse prim for multiple dispatch; e.g. dense-sparse addition needs yet another prim. sparse-dense addition should decompose into dense-sparse and thus not require another prim.
* AOTDispatch would be responsible for unpacking and repacking the dense tensors into sparse tensors. 
* This trick applies to all TensorImpl subclasses which ultimately backend to dense tensors

We could also *not* do this and force passes and compilers to know how to deal with sparse tensors directly.

cc @nikitaved @pearu @cpuhrsch @amjames, please tag anyone else relevant   
cc @bdhirsh 

### Versions

master
Idiom for PrimTorch refs for Tensor methods
Labels: triaged, module: primTorch

### 🐛 Describe the bug

Right now if you want to write a ref for a Tensor method, there's no precedent for how to do this. Some of these right now are getting dumped directly in torch._refs which is wrong (since torch._refs.foo should only exist if torch.foo exists, but some methods do not exist as functions) and getting remapped with `torch_to_refs_map`

The goal would be to create some sort of synthetic class or module for tensor methods, and then automatically map tensor methods to that class, so that TorchRefsMode works out of the box with a new tensor without having to route through a special case mapping.

### Versions

master

cc @ezyang @mruberry @ngimel
`sparse_coo.to_dense()` produces different results between CPU and CUDA backends for boolean non-coalesced inputs.
Labels: module: sparse, triaged

### 🐛 Describe the bug

As per title. To reproduce, run the following:

```python
In [1]: import torch

In [2]: idx = torch.tensor([[1, 1, 1, 2, 2, 2], [2, 2, 1, 3, 3, 3]], dtype=torch.long)

In [3]: val = torch.tensor([True, False, True, False, False, True])

In [4]: s = torch.sparse_coo_tensor(idx, val, size=(10, 10))

In [5]: torch.all(s.to('cuda').to_dense() == s.to_dense().to('cuda'))
Out[5]: tensor(False, device='cuda:0')

```

The CPU result seems correct, so I assume a parallelization issue.

### Versions

Current master.

cc @nikitaved @pearu @cpuhrsch @amjames
Windows Debug binaries crash on forward: assert fail on IListRefIterator destructor
Labels: oncall: jit

### 🐛 Describe the bug

libtorch 1.12 CUDA 11.6 on windows

I load a saved jit model, run it with the Release binary and it works.

If instead I compile and link with Debug binaries, at the 'forward' call i got an assert fail.

Line 405 of IListRef.h

In the trace i read a lot of box-unbox and a call to 'materialize'.
I believe the crash happens at the end of the forward, bceause some time has passed and the ram has been filled by some Gbs.

### Versions

[pip3] numpy==1.23.1
[pip3] torch==1.12.0+cu116
[pip3] torchaudio==0.12.0+cu116
[pip3] torchvision==0.13.0+cu116
[conda] Could not collect
DISABLED test_profiler (test_jit.TestJit)
Labels: oncall: jit, module: flaky-tests, skipped

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_profiler&suite=test_jit.TestJit&file=test_jit.py) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/7381856543).

Over the past 3 hours, it has been determined flaky in 1 workflow(s) with 1 red and 1 green.
[bug] the output shape from torch::mean and torch::var is different  in libtorch
Labels: module: cpp, triaged

### 🐛 Describe the bug

~~~
#include <torch/torch.h>
#include <ATen/ATen.h>

torch::Tensor x = torch::randn({3,4,5});

at::IntArrayRef dim{{0,2}};

std::cout << x.mean(dim, 1).sizes() << std::endl;
/*
[1, 4, 1]
*/

std::cout << x.var(dim, 1).sizes() << std::endl;
/*
[4]
*/
~~~

the shape of output from mean and var is not compatible.


### Versions

libtorch: 1.11.0+cu113

cc @jbschlosser
Improve interaction of PyTorch downstream libraries and torchdeploy
Labels: triaged, module: deploy

### 🐛 Describe the bug

torchdeploy's Python library model is that each interpreter loads and manages downstream libraries (including those with compiled extension modules) separately, since the extension modules in general need to link against libpython (which is duplicated per interpreter). However, this causes a problem if the downstream libraries do custom operator registration, which hits a shared global state among all interpreters.

### Versions

master

cc @wconstab
[Profiler] Defer thread assignment for python startup events.
Labels: triaged, oncall: profiler

### 🚀 The feature, motivation and pitch

When the python function tracer starts, there are generally frames which are already live in the cPython interpreter. In order to produce a comprehensible trace we treat them as though they just started: https://github.com/pytorch/pytorch/blob/master/torch/csrc/autograd/profiler_python.cpp#L538 However, this will cause a problem when we support multiple python threads because all of these initial events will use the system TID of the thread which started the tracer. In order to treat them properly, we should lazily assign them system TIDs. This can be accomplished by keeping track of which events were start events (just tracking the number of start events is sufficient to reconstruct this information later) and then use the TID of the first call in the actual tracing block to assign the proper TID during post processing.

To take a concrete example:
```
# Initial stacks
Python thread 0: [foo()][bar()][baz()]
Python thread 1: [f0()][f1()]
```
Let's say we start the tracer from system thread 3. The five frames which were active when the tracer started will all be stored in the event buffer for thread 3 and in the current machinery that is the inferred TID. Suppose we see a call on Python thread 0 during profiling which occurs on system thread 2. We can use that information to change the system TID of the `foo`, `bar`, and `baz` frames to system TID 2 during post processing and produce a more accurate trace. (And will separate the stacks on the chrome trace.)

### Alternatives

_No response_

### Additional context

_No response_

cc @ilia-cher @robieta @chaekit @gdankel @bitfort @ngimel @nbcsm @guotuofeng @guyang3532 @gaoteng-git
float' object is not callable when using scheduler.step() with MultiplicativeLR
Labels: module: optimizer, triaged, actionable

### 🐛 Describe the bug

## 🐛 Bug

I have initialized an optimizer and a scheduler like this:
```
def configure_optimizers(self): 
      opt = torch.optim.Adam(self.model.parameters(), lr=cfg.learning_rate)
     sch = torch.optim.lr_scheduler.MultiplicativeLR(opt, lr_lambda = 0.95) #decrease of 5% every epoch        
      return [opt], [sch]`
```

Since I just want to updte the scheduler after each epoch, I did not modify this updating method in the training phase, but this is the error I get after the first epoch:

>    self.update_lr_schedulers("epoch", update_plateau_schedulers=False)
>   File "/home/lsa/anaconda3/envs/randla_36/lib/python3.6/site-packages/pytorch_lightning/loops/epoch/training_epoch_loop.py", line 448, in update_lr_schedulers
>     opt_indices=[opt_idx for opt_idx, _ in active_optimizers],
>   File "/home/lsa/anaconda3/envs/randla_36/lib/python3.6/site-packages/pytorch_lightning/loops/epoch/training_epoch_loop.py", line 509, in _update_learning_rates
>     lr_scheduler["scheduler"].step()
>   File "/home/lsa/anaconda3/envs/randla_36/lib/python3.6/site-packages/torch/optim/lr_scheduler.py", line 152, in step
>     values = self.get_lr()
>   File "/home/lsa/anaconda3/envs/randla_36/lib/python3.6/site-packages/torch/optim/lr_scheduler.py", line 329, in get_lr
>     for lmbda, group in zip(self.lr_lambdas, self.optimizer.param_groups)]
>   File "/home/lsa/anaconda3/envs/randla_36/lib/python3.6/site-packages/torch/optim/lr_scheduler.py", line 329, in <listcomp>
>     for lmbda, group in zip(self.lr_lambdas, self.optimizer.param_groups)]
> TypeError: 'float' object is not callable

### Expected behavior

This error should not be there, in fact, using another scheduler ( in particular this
 ` sch = torch.optim.lr_scheduler.CosineAnnealingLR(opt, T_max=10)` ) I do not get the error and the training proceedes smoothly.
### To Reproduce
```
import torch
from torchvision.models import resnet18
net = resnet18()
optimizer = torch.optim.Adam(net.parameters(), lr=0.01) 
scheduler = torch.optim.lr_scheduler.MultiplicativeLR(optimizer, 0.95) # BUG SCHEDULER 
#scheduler = torch.optim.lr_scheduler.StepLR(optimizer, 3, gamma=0.1) # WORKING ONE
for i in range(10):
    print(i, scheduler.get_lr())
    scheduler.step()

 ```




### Environment

* CUDA:
        - GPU:
                - NVIDIA RTX A6000
        - available:         True
        - version:           11.3
* Packages:
        - numpy:             1.19.2
        - pyTorch_debug:     False
        - pyTorch_version:   1.10.2
        - pytorch-lightning: 1.5.0
        - tqdm:              4.64.0
* System:
        - OS:                Linux
        - architecture:
                - 64bit
                -
        - processor:         x86_64
        - python:            3.6.13
        - version:           #44~20.04.1-Ubuntu SMP Fri Jun 24 13:27:29 UTC 2022

              

cc @vincentqb @jbschlosser @albanD
Support Swift Package Manager (SPM) for iOS
Labels: oncall: mobile

### 🚀 The feature, motivation and pitch

Currently, Pytorch needs to be added to an iOS project via Cocoapods. However, many newer projects have migrated to Swift Package Manager. It would be fantastic if one could add Pytorch mobile via SPM, too.

### Alternatives

Alternatively, I'd also be happy to vendor pytorch into my codebase. We threw out Cocoapods a while ago and don't really want to reintroduce it if possible.

### Additional context

_No response_
Linking pytorch libraries causes sstream behavior to be overridden globally
Labels: module: build, triaged

### 🐛 Describe the bug

Some details here: https://github.com/ros2/geometry2/issues/540

I ran into an issue when integrating ROS2 TF2 libraries with pytorch. Here's a simple C++ file that reproduces the bug:

main.cpp

```C++
#include <sstream>
#include <iostream>

int main(int argc, char * argv[])
{
    long unsigned int num = 0xdeadbeef;
    std::stringstream sstream;
    sstream << "transform_listener_impl_" << std::hex << reinterpret_cast<size_t>(num);
    std::cout << "transform_listener_impl_" << std::hex << reinterpret_cast<size_t>(num) << std::endl;
    std::cout << std::string(sstream.str()) << std::endl;
}
```

CMakeLists.txt

```
cmake_minimum_required(VERSION 3.8)
project(torch_bug)


# Default to C++14
if(NOT CMAKE_CXX_STANDARD)
  set(CMAKE_CXX_STANDARD 14)
endif()

if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang")
  add_compile_options(-Wall -Wextra -Wpedantic)
endif()

find_package(Torch REQUIRED)


add_executable(${PROJECT_NAME} main.cpp)

target_link_libraries(${PROJECT_NAME}
  ${TORCH_LIBRARIES}
)
```


Expected output:
```
transform_listener_impl_deadbeef
transform_listener_impl_deadbeef
```

Actual output:
```
transform_listener_impl_deadbeef
transform_listener_impl_de,adb,eef
```

What could cause this bug? In the case of ROS, it really hates having those commas inserted and throws a run time exception. I wonder what other situations this is problematic in.

I installed libtorch using this binary link: https://download.pytorch.org/libtorch/cu116/libtorch-cxx11-abi-shared-with-deps-1.12.0%2Bcu116.zip


### Versions

Collecting environment information...
PyTorch version: 1.10.0+cu102
Is debug build: False
CUDA used to build PyTorch: 10.2
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.4 LTS (x86_64)
GCC version: (Ubuntu 8.4.0-3ubuntu2) 8.4.0
Clang version: Could not collect
CMake version: version 3.16.3
Libc version: glibc-2.31

Python version: 3.8.10 (default, Mar 15 2022, 12:22:08)  [GCC 9.4.0] (64-bit runtime)
Python platform: Linux-5.4.0-122-generic-x86_64-with-glibc2.29
Is CUDA available: True
CUDA runtime version: 11.7.64
GPU models and configuration: GPU 0: NVIDIA GeForce GTX 1080
Nvidia driver version: 515.48.07
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.4.1
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] mypy==0.902
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.22.4
[pip3] torch==1.10.0
[pip3] torchaudio==0.10.0+cu113
[pip3] torchvision==0.11.1
[pip3] torchviz==0.0.2
[conda] Could not collect

cc @malfet @seemethere
CapabilityBasedPartitioner treats non-compute ops inconsistently
Labels: triaged, module: fx, module: CapabilityBasedPartitioner, module: fx.passes

### 🐛 Describe the bug

Currently, only these two ops are treated as non-compute: `non_compute_ops = {"torch.ops.aten.view", "_operator.getitem"}`. However, there are plenty of  other non-compute ops, e.g. all view operations. It is also unclear why view ops need to get treated specially at all; it seems like this ought to be configurable.

cc @ezyang @SherlockNoMad 

### Versions

master
CapabilityBasedPartitioner doesn't support horizontal (vertical?) fusion
Labels: triaged, module: nvfuser

### 🐛 Describe the bug

steps to reproduce:

```
diff --git a/test/test_fx_passes.py b/test/test_fx_passes.py
index 39fe501f44..9fe5e4002e 100644
--- a/test/test_fx_passes.py
+++ b/test/test_fx_passes.py
@@ -158,6 +158,12 @@ class TestPartitionFunctions:
         out = torch.stack([add_1, add_2, add_3])
         return out
 
+    @staticmethod
+    def forward12(a):
+        add_1 = a + 1
+        add_2 = a + 2
+        return add_1, add_2
+
 # A mock OperatorSupport class, where only operator.add is supported
 class MockOperatorSupport(OperatorSupport):
     def is_node_supported(self, submodules, node: torch.fx.Node) -> bool:
@@ -179,6 +185,7 @@ class TestFXGraphPasses(JitTestCase):
         (TestPartitionFunctions.forward9, [['add_3', 'add_2', 'add_1', 'add']]),
         (TestPartitionFunctions.forward10, [['add_3', 'add_2', 'add', 'add_1']]),
         (TestPartitionFunctions.forward11, [['add_1'], ['add']]),
+        (TestPartitionFunctions.forward12, [['add_1', 'add_2']]),
     ])
     def test_partitioner(self, fn, expected_partition):
         traced = symbolic_trace(fn)
@@ -188,7 +195,7 @@ class TestFXGraphPasses(JitTestCase):
         partitions = partitioner.propose_partitions()
 
         partitions_name = [[node.name for node in partition.nodes] for partition in partitions]
-        assert len(partitions_name) == len(expected_partition)
+        assert len(partitions_name) == len(expected_partition), partitions_name
         for i in range(len(partitions_name)):
             assert set(partitions_name[i]) == set(expected_partition[i])
 
```

I don't know if nvFuser supports horizontal fusion or not, but if the backend supports it (e.g., cuda graphs does) loss of fusion here is bad as you are doubling your memory traffic.

cc @SherlockNoMad @Chillee 

### Versions

master
[onnx] Add support for prim::DictConstruct in pytorch-ONNX converter
Labels: module: onnx, triaged

### 🐛 Describe the bug

Current handling of dict types is very limited in pytorch-ONNX converter is extremely limited.
In tracing mode, all the dict types are flattened such that only the values in the key-value pair are preserved.
In scripting mode, no such flattening occurs, and the conversion just errors out.

### Versions

Python version: 3.8.12 (default, Oct 12 2021, 13:49:34)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.15.0-1014-azure-x86_64-with-glibc2.17
Is CUDA available: N/A
CUDA runtime version: Could not collect
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A

Versions of relevant libraries:
[pip3] mypy==0.950
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.21.6
[pip3] torch==1.13.0a0+gitf1aeea2
[pip3] torchvision==0.13.0a0+8e5844f
[conda] mkl                       2022.0.1           h06a4308_117  
[conda] mkl-include               2022.0.1           h06a4308_117  
[conda] numpy                     1.21.6                   pypi_0    pypi
[conda] torch                     1.13.0a0+git6997ac7          pypi_0    pypi
[conda] torchvision               0.13.0a0+8e5844f           dev_0    <develop>
[onnx] support more combinations of args/kwargs as model inputs for pytorch-onnx converter
Labels: module: onnx, triaged

### 🐛 Describe the bug

Currently for a given model such that:
```
class Model(torch.nn.Module):
          def forward(self, args, *kwargs):
                   ....
```
The pytorch-ONNX converter only support certain combinations of model inputs such as:
```
(self, args, *kwargs)
(self, args)
```
and does not support combinations like:
```
(self, *kwargs)
(self, arg1, arg2, args, kwarg1, kwarg2, *kwargs)
... and many more
```

The fix would require somewhat of a redesign as to how the exporter deals with processing of model inputs.

### Versions

Python version: 3.8.12 (default, Oct 12 2021, 13:49:34)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.15.0-1014-azure-x86_64-with-glibc2.17
Is CUDA available: N/A
CUDA runtime version: Could not collect
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A

Versions of relevant libraries:
[pip3] mypy==0.950
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.21.6
[pip3] torch==1.13.0a0+gitf1aeea2
[pip3] torchvision==0.13.0a0+8e5844f
[conda] mkl                       2022.0.1           h06a4308_117  
[conda] mkl-include               2022.0.1           h06a4308_117  
[conda] numpy                     1.21.6                   pypi_0    pypi
[conda] torch                     1.13.0a0+git6997ac7          pypi_0    pypi
[conda] torchvision               0.13.0a0+8e5844f           dev_0    <develop>
jit gives surprising results with lists of objects
Labels: oncall: jit

### 🐛 Describe the bug

Hello, I have found something weird related to the use of jit on classes, using lists. On my IDE (Spyder) The following code can execute perfectly the first time, but will fail everytime after that. I need to kill the console and open a new one again for it to work a second time.

``` python
import torch
from typing import List


@torch.jit.script
class Mother():
    def __init__(self):
        pass
    
    
@torch.jit.script
def f():
    l : List[Mother] = []
    for i in range(3):
        obj = Mother()
        l.append(obj)


f()
```

On the second time, I get this message:
```
RuntimeError: 

aten::append.t(t[](a!) self, t(c -> *) el) -> (t[](a!)):
Could not match type __torch__.Mother (of Python compilation unit at: 000001DE1823F0C0) to t in argument 'el': Type variable 't' previously matched to type __torch__.___torch_mangle_1.Mother (of Python compilation unit at: 000001DE1823F0C0) is matched to type __torch__.Mother (of Python compilation unit at: 000001DE1823F0C0).
:
  File "untitled0.py", line 22
    for i in range(3):
        obj = Mother()
        l.append(obj)
        ~~~~~~~~ <--- HERE
```

It seems that the name mangling causes a problem, but I am really not an expert on that. I guess it could cause issues in the future, although I have no idea how hard it is to fix it

### Versions

PyTorch version: 1.11.0+cpu
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Microsoft Windows 10 Home
GCC version: (Rev5, Built by MSYS2 project) 10.3.0
Clang version: Could not collect
CMake version: Could not collect
Libc version: N/A

Python version: 3.8.8 (default, Apr 13 2021, 15:08:03) [MSC v.1916 64 bit (AMD64)] (64-bit runtime)
Python platform: Windows-10-10.0.19041-SP0
Is CUDA available: False
CUDA runtime version: No CUDA
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

Versions of relevant libraries:
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.20.1
[pip3] numpydoc==1.1.0
[pip3] torch==1.11.0
[pip3] torchvision==0.12.0
[conda] blas                      1.0                         mkl  
[conda] mkl                       2021.2.0           haa95532_296  
[conda] mkl-service               2.3.0            py38h2bbff1b_1  
[conda] mkl_fft                   1.3.0            py38h277e83a_2  
[conda] mkl_random                1.2.1            py38hf11a4ad_2  
[conda] numpy                     1.20.1           py38h34a8a5c_0  
[conda] numpy-base                1.20.1           py38haf7ebc8_0  
[conda] numpydoc                  1.1.0              pyhd3eb1b0_1  
[conda] torch                     1.11.0                   pypi_0    pypi
[conda] torchvision               0.12.0                   pypi_0    pypi
[JIT] Request Constant Propagation to keep fake_quantize_per_tensor_affine and fake_quantize_per_channel_affine on the graph
Labels: oncall: jit

### 🚀 The feature, motivation and pitch

We are using [torch-blade](https://github.com/alibaba/BladeDISC) to accelerate  torchscript with TensorRT backend. And we are going to support Quantization-aware-training model with torch-blade and compile the subgraph to TensorRT INT8 engine. During the optimization process, we will first export the QAT-model to torchscript with fake quant (`aten::fake_quantize_per_tensor_affine` and `aten::fake_quantize_per_channel_affine`). Then the torchscript will be converted to onnx graph with fake quant (onnx::QuantizeLinear and onnx::DeQuantizedLinear). TensorRT would parse the onnx model and build the int engine.

To simplify the torchscript and make more nodes optimized by trt, we would use some jit passes to optimize the torchscript with fake-quant. However, the `aten::fake_quantize_per_tensor_affine` and `aten::fake_quantize_per_channel_affine` would be folded by `torch._C._jit_pass_constant_propagation`:

Given a graph like:
```
weight -> fake_quant -> aten::convolution
```
After `torch._C._jit_pass_constant_propagation`, the graph would be:
```
weight -> aten::convolution
```

However, the TensorRT recommends that there should be a q-dq onnx node pair in the graph for the weight(see [here](https://docs.nvidia.com/deeplearning/tensorrt/developer-guide/index.html#qdq-placement-recs))

So is that possible to add `aten::fake_quantize_per_tensor_affine` and `aten::fake_quantize_per_channel_affine` to the skip_list of `torch._C._jit_pass_constant_propagation` or provide an interface to customize the skip_list

The aten::dequantize has been added to the skip_list of `torch._C._jit_pass_constant_propagation`. see #63991


### Alternatives

_No response_

### Additional context

_No response_
Missing corner case handling in ATen ctc_loss implementation
Labels: module: loss, module: error checking, triaged

The current ctc_loss implementation seems not to handle the case when input_length=0. In this case, the loss should be 0 if target_length=0 or -infinity otherwise, by definition.

Moreover, if max_input_length=0, the following code snippet might cause an index out-of-range bug.

https://github.com/pytorch/pytorch/blob/62f1ff23fbf9e8f1281c135aadb3af87d2d69e7e/aten/src/ATen/native/LossCTC.cpp#L114-L117
torch.utils.checkpoint optimization opportunity
Labels: module: autograd, triaged, enhancement, has workaround

Currently checkpointing will always rerun the entirety of the forward function in backward, but sometimes that is not needed to recompute all the tensors that are needed for backward.

In the below snippet, suppose we want to avoid saving X2 for backward. With checkpointing, we'd need to checkpoint the function: `W2 @ gelu(X1)`, which would compute both gelu and matmul in backward. However, only the inputs of the last operation are saved for backward, so it is not actually necessary to compute the last matmul. The workaround for that is to use a custom function and do checkpointing manually.
```
X1 = W1 @ X
X2 = gelu(X1)
Y = W2 @ X2
```

Can we have an automated solution for this though? Some possible implementations:
1.  interpose checks (e.g. using python dispatch level) to see if we've already computed all the needed saved tensors, and early stop. We should be careful though: if we use python dispatch, we actually go through a different composite compliant specific path which changes some in-place ops to out-of-place ops. I wonder if torch_function works though.
2.  allow user to pass in a separate function(s) that are used to recompute the tensors. The issue with this is that what is saved is not really public API and subject to change.

Thanks @ngoyal2707 for reporting the issue


cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
torch.randint should accept high=2**63
Labels: triaged, module: random, module: edge cases

### 🐛 Describe the bug

It is not possible to use `torch.randint` to get random values in the range [0, 2^63-1].
That is, the non-negative integers that fit in an int64.

```
>>> torch.randint(2**63, (2,2))
RuntimeError: Overflow when unpacking long
```

This is of course because `2**63` doesn't itself fit into an int64.
However, the specification of `torch.randint` is "high (int): **One above** the highest integer to be drawn from the distribution." So it would make sense to support this "high" value to take advantage of the full range of int64 in the generated tensor.

### Versions

Collecting environment information...
PyTorch version: 1.11.0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.3.1 (x86_64)
GCC version: Could not collect
Clang version: 13.1.6 (clang-1316.0.21.2.3)
CMake version: version 3.21.4
Libc version: N/A

Python version: 3.9.13 (main, Jun 15 2022, 01:24:55)  [Clang 13.1.6 (clang-1316.0.21.2.3)] (64-bit runtime)
Python platform: macOS-12.3.1-x86_64-i386-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
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

Versions of relevant libraries:
[pip3] functorch==0.1.1
[pip3] numpy==1.22.4
[pip3] torch==1.11.0
[pip3] torchmetrics==0.8.2
[pip3] torchvision==0.12.0
[conda] Could not collect

cc @pbelevich
torch.stft does not normalize non-rectangular windows correctly
Labels: triaged, module: complex, module: fft

## Issue description

When normalizing within torch.stft, the function divides by the $\sqrt{framelength}$ or otherwise $\sqrt{nfft}$. This would make sense for a rectangular window, or when the window is `None`. 

When window is not None, or it is not a rectangular window however, it would make sense to normalize with regards to the values within the window, as can be seen in the link below, you normalize with the L2 norm of the window 
https://ccrma.stanford.edu/~jos/sasp/Normalized_STFT_Basis.html

This is especially applicable when using normalizing for audio spectrograms, where the default window is a hann_window. 

I believe that normalization should happen with ```output /= window.pow(2.0).sum().sqrt()``` If window is None like default, then it should fall back to its current normalization. 

## System Info

- PyTorch or Caffe2: PyTorch
- How you installed PyTorch (conda, pip, source): conda
- Build command you used (if compiling from source):
- OS: macOS 12.3.1 (arm64)
- PyTorch version: 1.13.0.dev20220601
- Python version: 3.9.12
- CUDA/cuDNN version: N/A
- GPU models and configuration: N/A
- GCC version (if compiling from source): N/A
- CMake version: N/A
- Versions of any other relevant libraries: N/A


cc @ezyang @anjali411 @dylanbespalko @mruberry @Lezcano @nikitaved @peterbell10
[FSDP] `test_mp_embedding_reduce()` fails with `transformer_auto_wrap_policy()`
Labels: triaged, module: fsdp

`test_mp_embedding_reduce()` fails if we wrap the `TransformerWithSharedParams` with the typical `transformer_auto_wrap_policy()` with `transformer_layer_cls={TransformerEncoderLayer, TransformerDecoderLayer}`.

For now, we only wrap with a single top-level `FullyShardedDataParallel`, but we should investigate whether this failure is due to how the unit test is written or due to a gap in the mixed precision implementation.

cc @zhaojuanmao @mrshenli @rohan-varma @ezyang
Add a check to detect mutation of the inputs during backward
Labels: module: autograd, module: molly-guard, triaged, actionable

Modifying the grad_input during the backward pass is unexpected to the user and can produce silently incorrect gradients. However, currently you're allowed to do something like this:
```
import torch

class Func(torch.autograd.Function):
    @staticmethod
    def forward(ctx, x):
        return x

    @staticmethod
    def vjp(ctx, x):
        x += 1
        return x

a = torch.rand(2, 4, requires_grad=True)

out = Func.apply(a)
grad_out = torch.ones_like(out)
grad_a, = torch.autograd.grad(out, (a,), grad_outputs=grad_out)

print(grad_out) 
```

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
torch.searchsorted error message and documentation is unclear
Labels: module: docs, triaged, module: sorting and selection

### 🐛 Describe the bug

## Case 1
```python
x = torch.randn(2, 3)
y = torch.randn([])
torch.searchsorted(x, y)
# RuntimeError: torch.searchsorted(): input value can be a scalar only when boundaries tensor dimension is 1, but we got boundaries tensor dim(2)
# and input value's dim(0) numel(1)
```
the args to searchsorted are `searchsorted(sorted_sequence, values)` according to the [documentation](https://pytorch.org/docs/stable/generated/torch.searchsorted.html#torch.searchsorted); "boundaries" and "inputs" is ambiguous and we should be consistent

## Case 2

```python
x = torch.randn(2, 3)
y = torch.randn(1)
torch.searchsorted(x, y)
# RuntimeError: torch.searchsorted(): boundaries tensor should be 1 dimension or the first N-1 dimensions of boundaries tensor and input value te
# nsor must match, but we got boundaries tensor [2, 3] and input value tensor [1]
```

What is N? The documentation is a little unclear on this, but it looks like boundaries and inputs must have the same number of dimensions (or the inputs must have rank 0)

## Problem 3

https://pytorch.org/docs/stable/generated/torch.searchsorted.html#torch.searchsorted

From the docs, it is not clear how the input tensors "broadcast". This logic is captured in the chart with rules, but it would be nice to have some english that says that there are actually 2 cases for torch.searchsorted:
- boundaries is 1D, input is anything
- boundaries is ND, input is ND (with both Ns being the same and we require the shapes to be the same except in the last dimension)

We should enumerate the cases and describe what happens in each.


### Versions

1.12, main

cc @svekars @holly1238
Implement shape/size functions for nestedtensor
Labels: triaged, module: nestedtensor

### 🚀 The feature, motivation and pitch

Currently, nt.shape does not work. It just throws an error:

```
>>> import torch
>>> x = torch.nested_tensor([torch.rand(2), torch.rand(3)])
<stdin>:1: UserWarning: The PyTorch API of nested tensors is in prototype stage and will change in the near future. (Triggered internally at /Users/runner/work/pytorch/pytorch/pytorch/aten/src/ATen/NestedTensorImpl.cpp:99.)
>>> x.shape
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: Internal error: NestedTensorImpl doesn't support sizes. Please file an issue on https://github.com/pytorch/nestedtensor
```

The shape function has been implemented, as seen [in this colab](https://colab.research.google.com/github/pytorch/nestedtensor/blob/master/tutorials/notebooks/basic.ipynb#scrollTo=STGxLWXXVg5Z), it just hasn't been migrated to torch.

I do not see any downside to implementing this function, as it is easy it implement (the code is already written; it just needs to be migrated), and it's much better than throwing an error.



### Alternatives

_No response_

### Additional context

My use case:
I am working with graph neural networks, which involve a variable number of agents, each of which can observe a variable number of objects in the environment. if fully functional, nestedtensor would significantly simply the problem, as it would obviate the need to store and manipulate tensors of batch indices.

cc @cpuhrsch