sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Make Torch FX function `_torchscript_type_to_python_type` public
Labels: oncall: jit,module: fx

### 🚀 The feature, motivation and pitch

Could we make the Torch FX function `from torch.fx.operator_schemas import _torchscript_type_to_python_type` public? 
This allows third party ML pipeline libraries to get arguments of `ScriptModule` objects.


### Alternatives

We would like to get the same Python level argument type that is available with

```
import inspect

arg_specs = inspect.getfullargspec(mod.forward)
```

Which returns a `FullArgSpec` object with an `annotations` field that maps to regular Python classes like `torch.Tensor`.


Unfortunately, for a given TorchScript module `script_module`,  the traditional outputs from the call `script_module.forward.schema` are not simple Python types but instead, return classes from the `torch._C.*` namespace.

This request is so that we can have a supported function that can be used to converted those objects to actual Python types.


### Additional context

The current usage is

```
from torch.fx.operator_schemas import _torchscript_type_to_python_type

_torchscript_type_to_python_type(script_module.forward.schema.arguments[1].type)
```
Repository: rust
Issue: Unobservable vec, and arrays writes always always emit for size >= 3
Labels: A-LLVM,A-codegen,T-compiler

While revealing that dead `Vec<_>` writes always emit, to someone else, I decided to look into this for arrays.

It seems that, for any `[T; N]`, such that T is not a ZST or enum with a single possible value, and 3 <= N, then array writes are always emit. This applies to allowing emitting redundant memcpys, memclrs, memfills, and all related operations.

https://rust.godbolt.org/z/7vrT5xnxq

As for `Vec<T>`, as long as T isn't as described above, then unobservable writes and operations are usually emit.
https://rust.godbolt.org/z/jhM75Mj5E
Repository: pytorch
Issue: Clean up PyTorch's private operators
Labels: module: internals,triaged

### 🚀 The feature, motivation and pitch

There are some PyTorch operators that are private (i.e. prefaced with an underscore) that show up in the dispatcher. These operators are problematic, as 1. their semantics are completely undocumented, 2. it provides confusion to folks (including backends) about whether they should to be supported, and 3. they just look ugly/confusing.

Luckily, there are not that many private operators that show up in practice. Many of them are things like for_each operators, .In the OpInfo tests, we only run into 25 of them.

So, what's the goal here? Well, we don't want folks working with the PyTorch operator set (i.e. transforms or compiler backends) to need to worry about these private operators.

So, there's 3 main ways to handle these.

1. Kill them, and use other operators in their place. For example, @ngimel did this with `aten::_s_where` in https://github.com/pytorch/pytorch/pull/73468. Sometimes operators are split for not particularly great reasons.
2. Promote them to "proper" APIs. For example, `_fft_r2c`, `_fft_c2r`, and `_fft_c2c` are generic FFT APIs that actually cover all of PyTorch's FFT APIs! In this case, we should probably just expose these to users, perhaps as part of PrimTorch.
3. Decompose them. Some other private operators may need to exist for a reason - perhaps they map to an efficient kernel or need to be there for autograd reasons. In these cases, we can provide decompositions so that backends that don't want to deal with them no longer need to.

Removable:
- [ ] _log_softmax (https://github.com/pytorch/pytorch/issues/76433)
- [ ] _softmax (https://github.com/pytorch/pytorch/issues/76433)
- [ ] _log_softmax_backward_data (https://github.com/pytorch/pytorch/issues/76433)
- [ ] _softmax_backward_data (https://github.com/pytorch/pytorch/issues/76433)
- [ ] _unique2 (previous attempt: https://github.com/pytorch/pytorch/pull/18655)


Decomposable:
- [ ] _euclidean_dist
- [ ] _cdist_forward
- [ ] _trilinear

Promotable:
- [ ] _local_scalar_dense
- [ ] _fft_r2c
- [ ] _fft_c2r
- [ ] _fft_c2c
- [ ] _ctc_loss_backward
- [ ] _ctc_loss

Not sure: 
- [ ] _conj
- [ ] _conj_physical
- [ ] _embedding_bag
- [ ] _reshape_alias
- [ ] _unsafe_view
- [ ] _to_copy
- [ ] _linalg_check_errors
- [ ] _linalg_svd
- [ ] _embedding_bag_dense_backward
- [ ] _embedding_bag_per_sample_weights_backward
- [ ] _cdist_backward

cc: @ngimel, @ezyang 

### Alternatives

_No response_

### Additional context

_No response_

cc @ezyang @bhosmer @smessmer @ljk53 @bdhirsh
Repository: vscode
Issue: Are there plans to expose the Resolvers interface?
Labels: feature-request,remote-connection

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

https://github.com/microsoft/vscode/blob/main/src/vscode-dts/vscode.proposed.resolvers.d.ts
Repository: storybook
Issue: CLI: Add webpack5 heuristic to automigration
Labels: feature request,cli

Currently `sb init` detects webpack5 and applies an automigration. We should update `sb automigrate` to include the same heuristic.
Repository: pytorch
Issue: Fix layout of masked output when all sparse dimensions are reduced
Labels: module: sparse,triaged

### 🐛 Describe the bug

[From discussion on #75454](https://github.com/pytorch/pytorch/pull/75454#discussion_r858083103), sparse reduction ops like torch.sparse.sum return a dense result if all sparse dimensions are reduced https://github.com/pytorch/pytorch/blob/a5bc02aeb20c484eb7aab045a8f5609700a75533/aten/src/ATen/native/sparse/SparseTensorMath.cpp#L1297-L1300
but `_masked` operators currently [expect the layout of the output to be the same as the layout of the input](https://github.com/pytorch/pytorch/blob/master/test/test_masked.py#L298-L303) and the current implementation of _masked.sum [reflects this](https://github.com/pytorch/pytorch/blob/master/torch/_masked/__init__.py#L701-L708). 

Creating this issue to track this


### Versions

N/A

cc @nikitaved @pearu @cpuhrsch
Repository: axios
Issue: Not sure if it's a bug！url in instance.create, url not in instance.request,it not work
Labels: state::triage

#### Describe the bug

put url in  axios.create config，and instance.request config not hava url，not work

#### To Reproduce

<https://runkit.com/fsafsfsdfsd/626a182eb041210008b9e157>

```js
var axios = require("axios")

function requestBase(method,url,config){
    const instance = axios.create({
        baseURL: 'https://626a153e737b438c1c41c57d.mockapi.io',
        method,

        url,// [url] put here not work
    });

    //url in axios.create , request config is undefined , there is no url,not work
    instance.request(config).then(response=>{
        console.log('response: ',response.data);
    }).catch(error=>{
        console.log('error: ',error);
    });
}

//not work,put url in axios.create
requestBase('get','/users');

//it work
requestBase('get','','/users');
requestBase('get','',{url:'/users'});
```

#### Environment
 - Axios Version [ 0.27.2 ]

####
Repository: pytorch
Issue: `torch.clamp` does not distribute gradients as element-wise`min/max` do
Labels: module: autograd,triaged,actionable

### 🐛 Describe the bug

Since #59669 was merged, element-wise `max/min` evenly distribute gradients for all values that are equal in self and the other. However, `clamp`, which can be equivalently expressed using `max` and `min`, does not follow the way, resulting in different gradients between `clamp` and `min/max`. I suppose the similar fix with #59669 should be also applied to `clamp` so that it distributes gradients as `min/max` do.

```py
>>> import torch
>>> a = torch.tensor([-2.,-1.,0.,1.,2.], requires_grad=True)
>>> b = torch.full((5,), -1.); b.requires_grad = True
>>> c = torch.full((5,), 1.); c.requires_grad = True
>>> torch.clamp(a, b,c).sum().backward()
>>> a.grad, b.grad, c.grad
(tensor([0., 1., 1., 1., 0.]), tensor([1., 0., 0., 0., 0.]), tensor([0., 0., 0., 0., 1.]))
>>> a.grad, b.grad, c.grad = None, None, None
>>> torch.min(torch.max(a, b), c).sum().backward()
>>> a.grad, b.grad, c.grad
(tensor([0.0000, 0.5000, 1.0000, 0.5000, 0.0000]), tensor([1.0000, 0.5000, 0.0000, 0.0000, 0.0000]), tensor([0.0000, 0.0000, 0.0000, 0.5000, 1.0000]))
```


### Versions

```
Collecting environment information...
PyTorch version: 1.11.0+cpu
Is debug build: False
CUDA used to build PyTorch: Could not collect
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.6 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
CMake version: version 3.10.2
Libc version: glibc-2.27

Python version: 3.10.0 (default, Oct 15 2021, 11:40:42) [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-4.15.0-169-generic-x86_64-with-glibc2.27
Is CUDA available: False
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: True

Versions of relevant libraries:
[pip3] numpy==1.21.2
[pip3] torch==1.11.0+cpu
```

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
Repository: vscode
Issue: Git - Out of workspace diff does not survive a reload
Labels: bug,git

Steps to Reproduce:

1. open any workspace
2. open a file that is not inside the workspace
3. make some changes
4. open the changes view and open the diff of this file
5. reload window

=> 🐛 the editor fails to restore

This is likely because the repository is not being added on startup / not found. Works fine if the file is opened in another editor group not as diff.

![Recording 2022-04-28 at 07 44 41](https://user-images.githubusercontent.com/900690/165684929-88ce18f9-2942-4d55-9b3d-915419fc1d5b.gif)
Repository: terminal
Issue: Add a button to copy a background image into the Terminal's settings directory 
Labels: Help Wanted,Product-Terminal,Issue-Task,Area-SettingsUI

# Description of the new feature/enhancement

when setting the background image, click save and copy the image to the configuration (setting.json) directory of terminal.

![image](https://user-images.githubusercontent.com/57950591/165728494-34fd977e-d7e7-4303-aaa9-1f24de451c07.png)
Repository: vscode
Issue: "Bracket" colorization for indent
Labels: feature-request,bracket-pair-guides

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

Related to #136506.

I am working on a custom language that doesn't use brackets, but indentation like Python. Now it would be cool if I could add support for custom highlighting, somehow like this:
<img width="294" alt="Bildschirmfoto 2022-04-28 um 09 18 18" src="https://user-images.githubusercontent.com/62756994/165698348-f065984e-c32d-40b5-abcc-5328dd9ae185.png">
<img width="292" alt="Bildschirmfoto 2022-04-28 um 09 18 52" src="https://user-images.githubusercontent.com/62756994/165698440-28f7df96-614b-4433-b316-229d9405924c.png">
(I made braces transparent for this screenshot)

It would be optimal if we could make it indent based, but using a language server would also work.
Repository: flutter
Issue: [Proposal][url_launcher][web] Allow `draggable` behaviour of `Link` to be configurable. 
Labels: c: new feature,platform-web,p: url_launcher,package,c: proposal,P3,team-web,triaged-web

The `Link` widget in the `url_launcher` plugin creates <a> tags that are draggable, so browsers let you e.g. drag a link to the desktop to save a shortcut there. This is fine, except in horizontal lists on desktops where you need mouse dragging to scroll the list. The draggable behavior of the Link widget should probably be configurable.

https://user-images.githubusercontent.com/42271865/165713001-6878ef5c-c931-46df-9931-c2c6529c9728.mp4

```
$ flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 2.10.5, on Microsoft Windows [Version 10.0.22000.613], locale en-DK)
[!] Android toolchain - develop for Android devices (Android SDK version 33.0.0-rc2)
    ✗ cmdline-tools component is missing
      Run `path/to/sdkmanager --install "cmdline-tools;latest"`
      See https://developer.android.com/studio/command-line for more details.
    ✗ Android license status unknown.
      Run `flutter doctor --android-licenses` to accept the SDK licenses.
      See https://flutter.dev/docs/get-started/install/windows#android-setup for more details.
[✓] Chrome - develop for the web
[✓] Visual Studio - develop for Windows (Visual Studio Build Tools 2019 16.9.4)
[✓] Android Studio (version 2021.1)
[✓] VS Code (version 1.66.2)
[✓] VS Code, 64-bit edition
[✓] Connected device (4 available)
[✓] HTTP Host Availability

! Doctor found issues in 1 category.
```
Repository: go
Issue: x/crypto/acme: CreateOrderCert should not return whilst order is (still) Ready
Labels: NeedsInvestigation

We use [`CreateOrderCert`](https://github.com/golang/crypto/blob/30dcbda588387d7d277b9a4ab7d7ae9d739b2982/acme/rfc8555.go#L304) function to finalize an ACME order once it's status is `Ready` as per the [ACME spec](https://datatracker.ietf.org/doc/html/rfc8555#:~:text=Once%20all%20of,for%20the%0A%20%20%20certificate.)

`CreateOrderCert` [calls the finalize endpoint of the ACME server](https://github.com/golang/crypto/blob/30dcbda588387d7d277b9a4ab7d7ae9d739b2982/acme/rfc8555.go#L315) and then [calls `WaitOrder`](https://github.com/golang/crypto/blob/30dcbda588387d7d277b9a4ab7d7ae9d739b2982/acme/rfc8555.go#L327) which polls the ACME server till the order is in `Valid`, `Invalid` or `Ready` state ([here](https://github.com/golang/crypto/blob/30dcbda588387d7d277b9a4ab7d7ae9d739b2982/acme/rfc8555.go#L236-L240)).
I think that `CreateOrderCert` should _not_ return when order's state is `Ready` as it is possible that when `WaitOrder` first looks at the order, the ACME server has not set the order status to `Processing` _yet_ so it is still `Ready`.
I think from client's perspective it would make sense if in that case we'd keep polling the ACME server as it is in this case an intermittent state just like `Processing`.

(From looking at the spec it seems like a slow ACME server that sets the order status to `Processing` at some point after returning the finalize call would still be compliant. I haven't looked at LetsEncrypt implementation, but from looking at [Boulder design](https://github.com/letsencrypt/boulder/blob/main/docs/DESIGN.md#order-finalization-acme-v2-only) it seems like they would set the order to `Processing` (and probably already to `Valid`) before returning from finalize call, so this should not be an issue. However I think we have seen an issue with this with another ACME implementation [cert-manager#5062](https://github.com/cert-manager/cert-manager/issues/5062))
Repository: pytorch
Issue: Non target rank receives result of 'reduce' op when backend is 'gloo'
Labels: oncall: distributed

### 🐛 Describe the bug

I run code using two rank.

```
import os
import torch
import torch.distributed as dist
from torch.multiprocessing import Process
os.environ['MASTER_ADDR'] = '127.0.0.1'
os.environ['MASTER_PORT'] = '29500'
backend = 'gloo'
dist.init_process_group(backend)
rank = dist.get_rank()
# simple dist
if rank == 0:
  print("pid is {}, rank is {}".format(os.getpid(), rank))
else:
  print("pid is {}, rank is {}".format(os.getpid(), rank))
if rank == 0:
  input = torch.tensor([[1, 2], [3, 4]], device="cpu")
else:
  input = torch.tensor([[4, 5], [6, 7]], device="cpu")

if rank == 0:
  dist.reduce(input, dst=0, async_op=False)
else:
  dist.reduce(input, dst=0, async_op=False)
print('Pid is ', os.getpid(), ', Rank ', rank, ', output is: ', input)
```

I got result as below:

> Pid is  3479174 , Rank  0 , output is:  tensor([[ 5,  7],
>         [ 9, 11]])
> Pid is  3479067 , Rank  1 , output is:  tensor([[ 4,  5],
>         [ 9, 11]])

It seems that non dst rank also receives part result ([9, 11])  when backend is 'gloo'.  But the document says only dst rank receive final result.  https://pytorch.org/docs/stable/distributed.html .   'nccl' backend has no this problem.
Is this right? 

### Versions

'1.12.0a0+git0aa3c39'

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang
Repository: PowerToys
Issue: [chore] polish dev MD docs formatting
Labels: Idea-Enhancement,Issue-Docs,Needs-Team-Response

### Provide a description of requested docs changes

Low priority.

Writing guidelines state:

- [ ] text in links should not be formatted https://docs.microsoft.com/contribute/code-in-docs#links
- [ ] "Don't apply an inline style [...] to headings or hyperlink text" https://docs.microsoft.com/contribute/text-formatting-guidelines#headings-and-link-text
- [ ] _italics_ should be used for file names and folders https://docs.microsoft.com/contribute/text-formatting-guidelines#italics (we are used to display as `folder\file.ext`)
- [ ] check hyperlinks https://docs.microsoft.com/contribute/how-to-write-links
  - Do not use "click here."

Specific file attention points:

- [ ] A few - like _devdocs/modules/fancyzones.md_ and _powerrename.md_ - are just filled with "To Do"
- [ ] _localization.md_ is heavily outdated
- [ ] folder _planning/_ is heavily outdated
- [ ] _tools.md_ is obsolete?
- [ ] broken links:
  - [ ] _keyboardeventhandlers.md_ has broken links under "Tests for single key remaps and shortcut remaps"
    - https://github.com/microsoft/PowerToys/blob/main/src/modules/keyboardmanager/test/SingleKeyRemappingTests.cpp (2x)
    - https://github.com/microsoft/PowerToys/blob/main/src/modules/keyboardmanager/test/AppSpecificShortcutRemappingTests.cpp
  - [ ] _tools.md_ broken link: href=`tools/monitor_info_report`
- [ ] _specs/SCOOBE.md_ is outdated
- [ ] _/doc/images/settingsv2/settingshotkeycontrol.png_ is outdated

In _akaLinks.md_ file:

**powerToysCannotRemapKeys** https://docs.microsoft.com/windows/powertoys/keyboard-manager#keys-that-cannot-be-remapped
→ page exists, header does not

**powertoys-docs** https://docs.microsoft.com/windows/powertoys/?WT.mc_id=twitter-0000-docsmsft
→ why the "?" part

https://raw.githubusercontent.com/wiki/microsoft/PowerToys/images/overview/KBM_small.png
→ really old

**powerToysRequestFeature** https://github.com/microsoft/PowerToys/issues/new?assignees=&labels=&template=feature_request.md&title=
→ link opens general "new/choose" page

<details><summary>OLD</summary>

  - [x] _modules/launcher/plugins/registry.md_ still mentions "Microsoft.CodeAnalysis.FxCopAnalyzers" `https://github.com/dotnet/roslyn-analyzers`
  - [x] _modules/launcher/project_structure.md_ has broken links: href=`/src/modules/launcher/Wox.Core/Plugin`
</details>
Repository: excalidraw
Issue: The root icon is displayed incorrectly
Labels: bug

`∛` displayed normally
![28-04-2022_142114_vivaldi](https://user-images.githubusercontent.com/52647986/165741287-75664890-887d-4c9b-9cab-e473adb3c4fd.png)
but `√` is not displayed normally
![28-04-2022_142339_vivaldi](https://user-images.githubusercontent.com/52647986/165741712-53ff5efc-ed2f-41cf-8c87-d88b0ad6bf8f.png)
Repository: terminal
Issue: Defterm commandline applications aren't under the WindowsTerminal process tree - maybe they should be?
Labels: Product-Terminal,Issue-Task,Area-DefApp

1. set up defterm
2. run cmd.exe
3. see the following:

![image](https://user-images.githubusercontent.com/18356694/165747143-7a945fba-e634-4b9d-a31a-fd4b41e01f07.png)

There's a `OpenConsole -Embedding` and a `WindowsTerminal -Embedding` that are started, but the `cmd` that is started is not parented to those - it's sitting as a child of explorer, and it still owns the system conhost that did the handoff. 

We may need to somehow reparent the cmd.exe & it's conhost to the OpenConsole, or the WindowsTerminal - at least so they show up sanely in Task Manager.
Repository: tensorflow
Issue: tf.make_tensor_proto() does not respect byte order of numpy input array
Labels: stat:awaiting tensorflower,type:bug,comp:ops,TF 2.8

<details><summary>Click to expand!</summary> 
 
 ### Issue Type

Bug

### Source

binary

### Tensorflow Version

tf 2.8

### Custom Code

No

### OS Platform and Distribution

_No response_

### Mobile device

_No response_

### Python version

_No response_

### Bazel version

_No response_

### GCC/Compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current Behaviour?

```shell
Byte order is not checked when creating a TensorProto with tf.make_tensor_proto() from a numpy.ndarray with non-native byte order. This leads to wrong tensor data.

I would expect that byte order is checked and swapped if necessary before assigning to tensor_proto.tensor_content in [python/framework/tensor_util.py](https://github.com/tensorflow/tensorflow/blob/v2.8.0/tensorflow/python/framework/tensor_util.py#L523)
```


### Standalone code to reproduce the issue

```shell
x = np.ones(shape=(1, 2), dtype=np.float32)
x_bswap = x.astype('>f4') # assuming native byte order is little endian

y = tf.make_ndarray(tf.make_tensor_proto(x))
y_bswap = tf.make_ndarray(tf.make_tensor_proto(x_bswap))

print(y)
print(y_bswap)

assert np.array_equal(x, y)
assert np.array_equal(x, y_bswap)
```


### Relevant log output

```shell
[[1. 1.]]
[[4.6006e-41 4.6006e-41]]
---------------------------------------------------------------------------
AssertionError                            Traceback (most recent call last)
in <cell line: 7>()
      5 print(y_bswap)
      6 assert np.array_equal(x, y)
----> 7 assert np.array_equal(x, y_bswap)

AssertionError:
```
</details>