sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: torch.distributed.TCPStore doesn't work with dual IPv4/IPv6 network interface
Labels: oncall: distributed,triaged

## 🐛 Bug

<!-- A clear and concise description of what the bug is. -->

## To Reproduce

Steps to reproduce the behavior:

1. Setup 2 machines with dual IPv4/IPv6 interfaces
2. on first machine runthe following script
```
import torch.distributed as dist
from datetime import timedelta
import socket

port = 12345
ip = "127.0.0.1"
ip = "::"
try:
    server_store = dist.TCPStore(ip, port, 2, True, timedelta(seconds=30))
    print("initialized")
    server_store.set("first_key", "first_value")
    print("stored")
except RuntimeError as e:
    print(e)

```
3. on second machine run the following script
```
import torch.distributed as dist
from datetime import timedelta
import socket

port = 12345
ip = "172.0.0.1"
ip = "xxxx:yyyy:zzzz::"
client_store = dist.TCPStore(ip, port, 2, False, timedelta(seconds=30))
print("initialized")
print(client_store.get("first_key"))
```
4. Observe that this code works for IPv4 (127.0.0.1 on first, ipv4 of first machine on second) but doesn't work when IPv6 address is used on master node. Second/subordinate node uses IPv6 correctly.
5. Proposed fix:
    In https://github.com/pytorch/pytorch/blob/master/torch/lib/c10d/Utils.cpp#L90
    in line ::getaddrinfo nullptr is passed as a first argument, instead masteraddr should probably be passed down from outer callstack. We verified that if we replace nullptr with "::" the code works.

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior

TCPStore should work with both IPv4 and IPv6 addresses the same way.

<!-- A clear and concise description of what you expected to happen. -->

## Environment

Network interface with ipv4 and ipv6 address.

 - PyTorch Version (e.g., 1.0): 1.7.1
 - OS (e.g., Linux): Linux
 - How you installed PyTorch (`conda`, `pip`, source): conda
 - Build command you used (if compiling from source):
 - Python version: 3.7.3
 - CUDA/cuDNN version: 11.2, 8.0
 - GPU models and configuration: V100
 - Any other relevant information:


cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @agolynski @SciPioneer @H-Huang @mrzzd @cbalioglu
Repository: pytorch
Issue: device (+dtype) arguments for torch.stack / torch.cat
Labels: module: performance,module: cuda,triaged,enhancement

They currently have out argument that can be used for this purpose, but device/dtype would be more direct (since torch.cat/torch.stack is a bit akin to factory methods)

Usecase: a sequence of CPU tensors (maybe even coming from NumPy arrays) that need to be moved to a single GPU array. So creating a copy on CPU is wasteful

cc @ngimel @VitalyFedyunin
Repository: vscode
Issue: Git - Adopt `execInstallFolder` for askpass
Labels: debt,git

From https://github.com/microsoft/vscode-remote-release/issues/4308#issuecomment-774119227:

> variables are now resolved in the env var values and `${execInstallFolder}` should point to VS Code's install folder, so you can point directly to you bootloader scripts without needing to install them.

We should use the new `execInstallFolder` variable for the askpass environment, [instead of using `__dirname`](https://github.com/microsoft/vscode/blob/5185d7e6f8a1ca1c5e03f21d62f0a113d234a95d/extensions/git/src/askpass.ts#L75-L88).

@eamodio Let me know if you need more context.

cc @Tyriar
Repository: storybook
Issue: Better integration with Nuxt
Labels: feature request,compatibility with other tools,vue

Currently integration between Nuxt and Storybook works well and Vue community are using it every day. But there are some edge cases that current integration could not provide. The current integration is very tricky:

- It does rename `@storybook/vue` entry point and create custom entry-point [link](https://github.com/nuxt-community/storybook/blob/master/src/webpack.ts#L34)
- It rewrite `render` function in order to wait for Nuxt initialization [link](https://github.com/nuxt-community/storybook/blob/master/storybook/nuxt-entry.js#L125)
- It rewrite `prepareForInline`  to wait for Nuxt initialization [link](https://github.com/nuxt-community/storybook/blob/master/storybook/nuxt-entry.js#L201)

These changes are required because Nuxt initialization is an async task and components should render afterward. Also Nuxt uses Vue [instance options](https://vuejs.org/v2/api/#vm-options) to register and use Vue plugins. 

[Loaders](https://storybook.js.org/docs/react/writing-stories/loaders) does resolve async initialize problem. (At the time I didn't know about the loaders, But for future release, I believe loaders are right choice to initialize Nuxt.)


The missing part to avoid this tricky implementation is custom instance options. Passing context from loaders to Vue instance.  

There are multiple places that `@storybook/vue` creates new Vue instance. Creating an internal and customizable utility to create Vue instance will help us to pass Vue options to these instances.

- https://github.com/storybookjs/storybook/blob/next/addons/docs/src/frameworks/vue/sourceDecorator.ts#L39
- https://github.com/storybookjs/storybook/blob/next/app/vue/src/client/preview/render.ts#L8
- https://github.com/storybookjs/storybook/blob/next/addons/docs/src/frameworks/vue/prepareForInline.ts#L18
Repository: pytorch
Issue: Detect OpenMP Loop and this application may hang warnings
Labels: oncall: jit,module: tests,module: multithreading,days

## 🐛 Bug

The following warnings is seen while executing jit tests with newer versions of PyTorch (v1.5.0 onwards)
`OpenBLAS Warning : Detect OpenMP Loop and this application may hang. Please rebuild the library with USE_OPENMP=1 option.`

 ```
python test_jit.py -v TestTracer.test_trace_save_load_copy
test_trace_save_load_copy (jit.test_tracer.TestTracer) ... OpenBLAS Warning : Detect OpenMP Loop and this application may hang. Please rebuild the library with USE_OPENMP=1 option.
OpenBLAS Warning : Detect OpenMP Loop and this application may hang. Please rebuild the library with USE_OPENMP=1 option.
OpenBLAS Warning : Detect OpenMP Loop and this application may hang. Please rebuild the library with USE_OPENMP=1 option.
OpenBLAS Warning : Detect OpenMP Loop and this application may hang. Please rebuild the library with USE_OPENMP=1 option.
OpenBLAS Warning : Detect OpenMP Loop and this application may hang. Please rebuild the library with USE_OPENMP=1 option.
ok

----------------------------------------------------------------------
Ran 1 test in 0.192s

OK
```


PyTorch is built with USE_OPENMP=1 and using anaconda openblas v0.3.10. 
 
## To Reproduce

Steps to reproduce the behavior:

1. Build PyTorch with USE_OPENMP=1 and BLAS=OpenBLAS and Anaconda openblas v0.3.10
2. Install PyTorch to a conda env. 
3. Execute the test `python test_jit.py -v TestTracer.test_trace_save_load_copy`.

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior
This warning is not seen with PyTorch v1.3.1, v1.4.0 and v1.4.1. So expecting it to behave same in v1.5.0 onwards as well. 

## Environment

Collecting environment information...
```
PyTorch version: 1.7.1
Is debug build: False
CUDA used to build PyTorch: Could not collect
ROCM used to build PyTorch: N/A

OS: Red Hat Enterprise Linux Server 7.8 (Maipo) (x86_64)
GCC version: Could not collect
Clang version: Could not collect
CMake version: version 3.18.2

Python version: 3.6 (64-bit runtime)
Is CUDA available: False
CUDA runtime version: 10.2.89
GPU models and configuration: GPU 0: Tesla P100-PCIE-16GB
Nvidia driver version: 440.33.01
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.19.2
[pip3] torch==1.7.1
[pip3] torchtext==0.8.0a0+0f911ec
[pip3] torchvision==0.8.2
[conda] _pytorch_select           1.0              
[conda] numpy                     1.19.2           
[conda] numpy-base                1.19.2           
[conda] pytorch-base              1.7.1                   
[conda] pytorch-cpu               1.7.1                      
[conda] torchtext                 0.8.1
[conda] torchvision-base          0.8.2    
libopenblas               0.3.10               
```

## Additional context

<!-- Add any other context about the problem here. -->


cc @mruberry @VitalyFedyunin @walterddr @gmagogsfm
Repository: godot
Issue: 2D: TileMap Autotiler Collissions
Labels: bug,topic:editor,topic:2d

This issue seems related to https://github.com/godotengine/godot/issues/24003, but still present (regression error?)

I'm running Godot 3.2.3.stable, on Windows 10.

I have set up a TileMap Autotiler, 3*3 Minimal, but run into an issue at the corners. At first my collisions were set up to use ConvexPolygonShape2Dss (the default), but I ran into the issue of my character not being able to stand in the corner. And if approached from above they would get stuck without getting an (on_floor).

![AutotilerIssue4](https://user-images.githubusercontent.com/50481103/107526075-c13b2c80-6bb7-11eb-9718-5a21b07b04a9.png)

After looking around for issues I found a partial solution in converting the respective tiles collision to ConcavePolygonSHape2Ds. 

![AutotilerIssue3](https://user-images.githubusercontent.com/50481103/107526423-21ca6980-6bb8-11eb-965e-c71eda398944.png)

However, this seems to lead to another issue where the collision are no longer visible in debug mode, and with enough speed items / the player will just fall (partially) through and get stuck.

![AutotilerIssue2](https://user-images.githubusercontent.com/50481103/107526453-2858e100-6bb8-11eb-99b0-b0535245aead.png)
Repository: transformers
Issue: Allow `do_lower_case=True` for any tokenizer
Labels: Feature request

# 🚀 Feature request

Extract the `do_lower_case` option to make it available for any tokenizer. Not just those that initially supported this, like the `BERT` tokenizers.

## Motivation

Sometimes we want to specify `do_lower_case=True` in the `tokenizer_config.json` of a custom tokenizer to activate the lowercasing. The problem is that this obviously works only for tokenizers based on one that originally used this option.

I think we should extract this feature to make it a shared one, that could be used with any tokenizer.

Example of a model that would need this described here: https://github.com/huggingface/transformers/issues/9518

## Special care points

- Make sure the `convert_slow_tokenizer` script also handles this, to activate the option in the resulting fast tokenizer.
- Maybe some other options could have the same treatment?

cc @LysandreJik @sgugger
Repository: godot
Issue: Omitting existing type hints when overriding methods shouldn't be allowed
Labels: bug,topic:gdscript

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
3.2.3

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Linux

**Issue description:**
<!-- What happened, and what was expected. -->
When overriding a method, type hints (for arguments that use typing) may be ommited, which means typing will not be used for that arguments.

It seems more like a bug than a feature, because anyway changing signature when overriding a method is not allowed (there is error "the function signature doesn't match the parent" for that case).

So Godot could prevent this as well with rising the same error "the function signature doesn't match the parent"

**Steps to reproduce:**
This code demonstrates the issue
```gdscript
func _ready():
	print(Y.new().a("string"))

class X:
	func a(arg:int)->int: # type hints are used here
		return 1

class Y:
	extends X

	func a(arg):  # there are no type hints here
		return "hi"
``` 

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
Repository: pytorch
Issue: common_jit.check_against_reference() should check gradients w.r.t. weights
Labels: oncall: jit,module: autograd,triaged,days

## 🚀 Feature
`common_jit.check_against_reference()` should check gradients w.r.t. weights and automatically check gradients w.r.t. inputs if any inputs require them. Then we can remove the need for requesting gradient checking (it will happen automatically).

## Motivation

We should check gradients w.r.t. weights because it will improve the accuracy of the comparison to the reference implementation.
Removing the need to request gradients explicitly simplifies the authoring of tests.

## Pitch

1. Augment `check_against_reference()` to check gradients wrt weights.
2. Check gradients wrt inputs only if inputs require them.
3. Remove `no_grad` parameter.

## Alternatives

We could keep the `no_grad` parameter if we want to keep it as the test author indicating that they expect gradients to be present. In which case, we would make it an error if gradients are expected but not requested. Renaming it to `expect_input_gradients` would make sense.

## Additional context

See https://github.com/pytorch/pytorch/pull/52016.


cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @gmagogsfm
Repository: pytorch
Issue: at::numeric_limits is misleading
Labels: module: cuda,module: rocm,triaged,better-engineering,actionable

`at::numeric_limits` comes with this warning:
https://github.com/pytorch/pytorch/blob/1c34fb48131eb68c894647e9ef8edb4142e323e9/aten/src/ATen/cuda/NumericLimits.cuh#L22-L24

Which is out of date. Following the discussion in https://github.com/pytorch/pytorch/pull/50902#discussion_r564735766 it seems that ROCm can now handle `std:numeric_limits` in device code just fine. However, as of #11091, `at::numeric_limits` has two non-standard functions `lower_bound()` and `upper_bound()` so it can't be removed completely.

cc @ptrblck @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang @ngimel @mruberry
Repository: angular
Issue: Hammer tap event doesn't fire after binding sanitized HTML on iOS
Labels: area: core,P4

<!--🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅

Oh hi there! 😄

To expedite issue processing please search open and closed issues before submitting a new one.
Existing issues often contain information about workarounds, resolution, or progress updates.

🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅-->


# 🐞 bug report

### Affected Package
<!-- Can you pin-point one or more @angular/* packages as the source of the bug? -->
<!-- ✍️edit: --> The issue is caused by package @angular/core and @angular/platform-browser I guess


### Is this a regression?

<!-- Did this behavior use to work in the previous version? -->
<!-- ✍️--> Don't know


### Description

Clickable elements (such as input and anchor tags) on a page seem unresponsive in browsers on iOS devices when all of the following three conditions are met:
1. An html snippet <strong>with a link</strong> is inserted via the [innerHTML] property.
2. That snippet bypasses the html sanitizing by using the bypassSecurityTrustHtml method.
3. There is a HostListener listening to the 'tap' event (for which hammer.js is installed).

When you swipe or scroll the page a bit first, then you can click one element. But after that you have to swipe or scroll again to click the next element.

## 🔬 Minimal Reproduction
<!--
Please create and share minimal reproduction of the issue starting with this template: https://stackblitz.com/fork/angular-ivy
-->
[https://angular-ivy-e3igjz.stackblitz.io](https://angular-ivy-e3igjz.stackblitz.io)

<!--
If StackBlitz is not suitable for reproduction of your issue, please create a minimal GitHub repository with the reproduction of the issue.
A good way to make a minimal reproduction is to create a new app via `ng new repro-app` and add the minimum possible code to show the problem.
Share the link to the repo below along with step-by-step instructions to reproduce the problem, as well as expected and actual behavior.

Issues that don't have enough info and can't be reproduced will be closed.

You can read more about issue submission guidelines here: https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-submitting-an-issue
-->

## 🌍  Your Environment

**Angular Version:**
<!-- run `ng version` and paste output below -->
<!-- ✍️-->11.1

**Anything else relevant?**
<!-- ✍️Is this a browser specific issue? If so, please specify the browser and version. -->
Browsers on iOS 14.x at least. Not tested on lower versions.
<!-- ✍️Do any of these matter: operating system, IDE, package manager, HTTP server, ...? If so, please mention it below. -->
Repository: go
Issue: net: Ambigous error message in dnsclient
Labels: NeedsInvestigation

There is an issue with the [Golang DNS client implementation](https://golang.org/src/net/dnsclient_unix.go):

```
errServerMisbehaving         = errors.New("server misbehaving")
errServerTemporarilyMisbehaving = errors.New("server misbehaving")
```
* Different error scenarios based on 2 variables lead to same ambiguous error message
* "Misbehaving" is an ambiguous word itself: to the possible extent, it should be clear what has actually happened i.e. print out DNS protocol error.
Repository: excalidraw
Issue: Expose action manager to Excalidraw API
Labels: discussion,package:excalidraw

We should expose the action manager via excalidraw ref API so the host can use the actions directly whenever needed,
 
Actions like `zoomToFit`, `zoomToFitAllElements`, `goToCollaborator` and many more would be useful for host to use.

With this host will have a good control over the actions. 
 
 cc @dwelle
Repository: TypeScript
Issue: New error: constructor is required in Object
Labels: Bug

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms
Constructor, Object

<!--
  What search terms did you use when trying to find an existing bug report?
  List them here so people in the future can find this one more easily.
-->

### 🕗 Version & Regression Information

- This changed between versions 4.0.5 and 4.1.3

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior

  The TypeScript Workbench can be used for more complex setups, try
  https://www.typescriptlang.org/dev/bug-workbench/

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
[Playground link with relevant code](https://www.typescriptlang.org/play?ts=4.1.3#code/CYUwxgNghgTiAEYD2A7AzgF3gDwFzwHkAjAK3CwB94BXFUAMwEsURgBuAKFElgWXSwBPfMTJgMnfpnhQRpcvAC88AN7wARFHX4AjABp4AOmPZ4AXzbwA9FfgBRGDCQx4ACikYY1cc-hwAjtSMcMDwzPAYggAOCKLkAJQcHvBEcmJYymrqRNrw+kbGguaWNvAAckhYUCjwII7OHEA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
declare const x: Object | undefined;
declare const y: Object;
const a: Object = { "a": 1, ...x }; // Error (constructor required in type Object)
const b: Object = { "b": 1, ...y }; // Not an error
```

### 🙁 Actual behavior

Error

### 🙂 Expected behavior

No error
Repository: TypeScript
Issue: TSC --watch should survive file renames
Labels: Needs Investigation

I use `tsc --watch` a lot but whenever I rename a file tsc --watch goes stale and doesn't recover from it hence I end up with stale JS without noticing. What you get in the console:

```
[1:13:49 PM] File change detected. Starting incremental compilation...

error TS6053: File '/..../npm/importLinker.ts' not found.

[1:13:50 PM] Found 1 error. Watching for file changes.
```

We should either fix this in TSC or at least make the task detect this and automatically restart.
Repository: react-native
Issue: Collection Name not supported by SectionList 
Labels: Good first issue,Platform: Android,Component: SectionList,Accessibility

## Description
Collection Name not supported by SectionList. No components can be set as any collection role. With support for "List" or "Grid" roles would these would likely work as expected.

This issue is covered in-depth by parent issue #30972, please check there for more details.

## React Native version:
v0.63
Repository: react-native
Issue: Position in Collection not supported by Flatlist
Labels: Good first issue,Platform: Android,Component: FlatList,Accessibility

## Description
Position in Collection not supported by Flatlist. No components can be set as any collection role. With support for "List" or "Grid" roles would these would likely work as expected.

This issue is covered in-depth by parent issue #30977, please check there for more details.

## React Native version:
0.63
Repository: react-native
Issue: Position in Collection not supported by SectionList 
Labels: Good first issue,Platform: Android,Component: SectionList,Accessibility

## Description
Position in Collection not supported by SectionList. No components can be set as any collection role. With support for "List" or "Grid" roles would these would likely work as expected.

This issue is covered in-depth by parent issue #30977, please check there for more details.

## React Native version:
0.63
Repository: react-native
Issue: Position in Collection not supported by VirtualizedList  
Labels: Good first issue,Platform: Android,Component: VirtualizedList,Accessibility

## Description
Position in Collection not supported by VirtualizedList. No components can be set as any collection role. With support for "List" or "Grid" roles would these would likely work as expected.

This issue is covered in-depth by parent issue #30977, please check there for more details.

## React Native version:
0.63
Repository: rust
Issue: Error messages can be ambiguous between types and type parameters
Labels: A-diagnostics,T-compiler,C-bug,A-suggestion-diagnostics,D-confusing,D-newcomer-roadblock,D-terse

Someone I know was learning Rust as a beginner. They defined a function like this:

```rust
fn test<T>(t: T) -> i32 {
    5_i32 + <i32 as From<T>>::from(t)
}
```
This resulted in an error:
```
error[E0277]: the trait bound `i32: From<T>` is not satisfied
 --> src/lib.rs:2:13
  |
2 |     5_i32 + <i32 as From<T>>::from(t)
  |             ^^^^^^^^^^^^^^^^^^^^^^ the trait `From<T>` is not implemented for `i32`
  |
  = note: required by `from`

```
Based on this error, they attempted to add an `i32: From<T>` bound:
```rust
fn test<T, i32: From<T>>(t: T) -> i32 {
    5_i32 + <i32 as From<T>>::from(t)
}
```
This leads to a different, very misleading error:
```
error[E0277]: cannot add `i32` to `i32`
 --> src/lib.rs:2:11
  |
2 |     5_i32 + <i32 as From<T>>::from(t)
  |           ^ no implementation for `i32 + i32`
  |
  = help: the trait `Add<i32>` is not implemented for `i32`
```
`#[warn(non_camel_case_types)]` can give a hint, but I think that the error message should stand on its own. In addition, they appear to have added `#![allow(non_camel_case_types)]` for unrelated reasons.

### Meta
`rustc --version --verbose`: (N/A, on playground)