sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: `hash_map::OccupiedEntry` should provide original key back.
Labels: T-libs-api

My understanding is that when `.entry()` returns `Occupied` the key provided is not used as the key was already in the map. There should then be a way to get the original key back. The current workaround is `.key().clone()` if they key type is clonable.

The following APIs could have an alternate version that provided the original key:

* [std::collections::hash_map::Entry::and_modify](https://doc.rust-lang.org/std/collections/hash_map/enum.Entry.html#method.and_modify)
* [std::collections::hash_map::OccupiedEntry::insert](https://doc.rust-lang.org/std/collections/hash_map/struct.OccupiedEntry.html#method.insert)
* [std::collections::hash_map::OccupiedEntry::into_mut](https://doc.rust-lang.org/std/collections/hash_map/struct.OccupiedEntry.html#method.into_mut)
* [std::collections::hash_map::OccupiedEntry::remove](https://doc.rust-lang.org/std/collections/hash_map/struct.OccupiedEntry.html#method.remove)
* [std::collections::hash_map::OccupiedEntry::remove_entry](https://doc.rust-lang.org/std/collections/hash_map/struct.OccupiedEntry.html#method.remove_entry)

Now it may not make sense to add alternatives to all of these but it should be considered. Alternatives would be infeasible such as adding a key member to `OccupiedEntry` or making `Entry::Occupied(OccupiedEntry, K)`.

The best way to do this isn't clear, but it would be nice to be able to work with non-clonable types and avoid unnecessary clones.
Repository: puppeteer
Issue: requestfailed.failure() is giving null for blocked mixed content errors
Labels: bug,upstream,confirmed,P3

### Steps to reproduce
1) Using puppeteer,  Navigate to a page having any mixed content error. for e.g 
https://books.toscrape.com/catalogue/category/books/add-a-comment_18/index.html 

Please check below snapshot
![image](https://user-images.githubusercontent.com/20857830/112841726-74a3a600-90be-11eb-8571-fafaf918aa33.png)

2)  I have below listener for listening request failed event
```
    page.on('requestfailed', requestfailed => {
      var req=JSON.stringify(requestfailed.failure())   
      console.log('requestfailed occurred: ', req);
    })
```

3) For the above URL, its returning value as null
![image](https://user-images.githubusercontent.com/20857830/112842459-31960280-90bf-11eb-90da-9f53a22cd82a.png)


**Tell us about your environment:**

* Puppeteer version:^5.5.0
* Platform / OS version: Windows 7
* Node.js version:v12.18.4


**What is the expected result?**
The expected result is, the above method requestfailed.failure() should return the error message for the blocked mixed content

**What happens instead?**
 The above method requestfailed.failure() is returning null
Repository: go
Issue: cmd/compile: emitted DWARF location for complex128 param is incorrect
Labels: NeedsInvestigation,compiler/runtime


### What version of Go are you using (`go version`)?

Using tip (linux.amd64)

<pre>
$ go version
go version devel +565e70fcef Mon Mar 29 08:11:13 2021 +0000 linux/amd64

</pre>

### Does this issue reproduce with the latest release?

Yes.

### What operating system and processor architecture are you using (`go env`)?

linux/amd64

### What did you do?

Compile this program:

https://play.golang.org/p/_v676oJ4LLO

and look at the DWARF generated for the function main.tryme

### What did you expect to see?

Correct location expressions for all params

### What did you see instead?

For the parameter "z", here is the parameter DIE:

```
 <2><3c428>: Abbrev Number: 16 (DW_TAG_formal_parameter)
    <3c429>   DW_AT_name        : z
    <3c42b>   DW_AT_variable_parameter: 0
    <3c42c>   DW_AT_decl_line   : 7
    <3c42d>   DW_AT_type        : <0x3e46a>
    <3c431>   DW_AT_location    : 0x5a5a3 (location list)

```
and here is the relevent .debug_loc section:

```
    0005a5a3 ffffffffffffffff 000000000045f340 (base address)
    0005a5b3 000000000045f340 000000000045f399 (DW_OP_fbreg: 24; DW_OP_piece: 8; DW_OP_fbreg: 24; DW_OP_piece: 8)
    0005a5cd <End of list>

```

Note the two pieces are the same (for real and imaginary). If I stop in a debugger and print the value of the param, I get:

```
(gdb) p z
$1 = 2 + 2i
(gdb)

```

which is obviously wrong (should be 1 + 2i).

I looked at older versions of Go (1.15, 1.14, and it appears that they get this wrong as well, although in slightly different ways).
Repository: rust
Issue: Switch table generated when code for all match arms are identical
Labels: A-LLVM,I-slow,T-compiler,I-heavy

The following code will generate a switch table, with all entries in the table pointing to the same label.

```rust
pub enum Enum {
    A,
    B,
    C,
    D,
}

pub fn test(v: Enum) {
    match v {
        Enum::A => println!("A"),
        Enum::B => println!("A"),
        Enum::C => println!("A"),
        Enum::D => println!("A"),
    }
}
```

This generates the following assembly:
<details><summary>Assembly</summary>
<p>

```asm
example::test:
        sub     rsp, 56
        movzx   eax, dil
        lea     rcx, [rip + .LJTI0_0]
        movsxd  rax, dword ptr [rcx + 4*rax]
        add     rax, rcx
        jmp     rax
.LBB0_1:
        lea     rax, [rip + .L__unnamed_1]
        mov     qword ptr [rsp + 8], rax
        mov     qword ptr [rsp + 16], 1
        mov     qword ptr [rsp + 24], 0
        lea     rax, [rip + .L__unnamed_2]
        mov     qword ptr [rsp + 40], rax
        mov     qword ptr [rsp + 48], 0
        lea     rdi, [rsp + 8]
        call    qword ptr [rip + std::io::stdio::_print@GOTPCREL]
        add     rsp, 56
        ret
.LJTI0_0:
        .long   .LBB0_1-.LJTI0_0
        .long   .LBB0_1-.LJTI0_0
        .long   .LBB0_1-.LJTI0_0
        .long   .LBB0_1-.LJTI0_0

.L__unnamed_3:
        .ascii  "A\n"

.L__unnamed_1:
        .quad   .L__unnamed_3
        .asciz  "\002\000\000\000\000\000\000"

.L__unnamed_2:
```

</p>
</details>

I would expect the switch table to be removed entirely. This is first observed when I tried to see what will happen if atomic operation's Ordering parameters are not inlined, e.g. wrap `atomic_usize.swap(0, ordering)` in a non-inlined function.

This behaviour is observed for all Rust versions and clang (but not GCC), so this is likely a LLVM issue.

@rustbot label: +I-slow +I-heavy +A-LLVM
Repository: godot
Issue: The VisualShader editor doesn't close when clearing a VisualShader resource (directly or indirectly)
Labels: bug,topic:editor,topic:shaders

<!-- 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.3 rc6 mono

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
win10 64

**Issue description:**
<!-- What happened, and what was expected. -->
Nodes do not disappear when removing visualshader.
This also happens with animation blend nodes.

![behavior1](https://user-images.githubusercontent.com/19652075/112882148-e4209200-90cc-11eb-9ca2-b9d2a2e5fcb7.gif)

**Steps to reproduce:**
Make any visualshader
remove it from the assignment

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
Repository: pytorch
Issue: Default generated meta functions for inplace operations don't report errors
Labels: triaged

To bring up meta tensors cheap and cheerfully, I'm going to generate no-op kernels for all inplace operations, as they don't affect metadata. This also means the default implementations won't raise errors, which will fail a bunch of tests. This issue tracks those tests. When those kernels are ported to structured, these failures will go away.
Repository: pytorch
Issue: [fx] forward references in annotations do not produce correct source code
Labels: module: bootcamp,triaged,module: fx

The test `test_annotations_with_forward_references` and others like it does not check that the resulting source code has valid types. For example, modifying the source code to use the types in TS compilation will lead to failure:

```

    def test_annotations_with_forward_references(self):
        class A:
            def __call__(self, x: torch.Tensor):
                return torch.add(x, x)

        class M(torch.nn.Module):
            def forward(self, x: 'torch.Tensor', a: 'A') -> 'torch.Tensor':
                return a(x)

        gm = symbolic_trace(M())
        torch.jit.script(gm)  # error
```

This is because in `symbolic_trace` we directly access the `__annotations__` dict ([example](https://github.com/pytorch/pytorch/blob/master/torch/fx/symbolic_trace.py#L271)). When forward references are involved, the annotations dict maps input names to strings instead of types. Our tracing infra just passes these strings through and we end up mapping the type to the string "torch.Tensor" instead of the actual object `torch.Tensor`. 



cc @ezyang @SherlockNoMad
Repository: godot
Issue: Path2D sets a previously drawn curve as the default
Labels: bug,topic:editor,topic:2d

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
3.2.3 and 3.3 RC6


**OS/device including version:**
Windows 10


**Issue description:**
The Path2D curve property seems to set the last curve drawn as a default across scenes. See video of a blank project for a demo.

https://user-images.githubusercontent.com/3285214/112884564-8dfd2000-90c7-11eb-8f10-0dfbd90bf2de.mp4

**Steps to reproduce:**
1. Create a scene with a Path2D as the root.
2. Draw a curve
3. Clear it and use the revert button to default button
Repository: pytorch
Issue: Allow CUDA build without requiring a physical GPU device.
Labels: module: build,module: cuda,triaged,enhancement

## 🚀 Feature
When the driver is sufficient, allow Pytorch and extensions, and all other packages depending on Pytorch extensions to build on a node that do not have a physical GPU device. This impacts numerous of packages depending on Pytorch.

## Motivation

In HPC centre, build-nodes might not have a physical device.

## Pitch

Allow Pytorch to build on build-nodes not having a GPU device but the sufficiant drivers installed.
This used to work : `torch._C._cuda_isDriverSufficient())`

## Additional context
This line : https://github.com/pytorch/pytorch/blob/67d44377e34a4194f9899391097ec52658a44af4/torch/cuda/__init__.py#L52
-> `torch._C._cuda_isDriverSufficient() or torch._C._cuda_getDeviceCount() > 0` ?

The modification happened in this commit : https://github.com/pytorch/pytorch/commit/aab30d4ea25686bcd8502aa280ba75d73559c2e4 

cc @malfet @seemethere @walterddr @ngimel
Repository: pytorch
Issue: Out variants for Convolution ops
Labels: module: convolution,triaged

As part of the PyTorch compiler, I am working on implementing graph level transformations to optimize `aten::cat` and `aten::copy` operations. This involves using the `out=` variants of the ops that are inputs.

Currently, there are no `out=` variants for the convolution ops (as seen [here](https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/native_functions.yaml#L996)). Would it be possible to add `out=` variants for these ops? Specifically, I am looking at `out=` variants at least for `conv2d` and `_convolution` functions.
Repository: storybook
Issue: [BUG] Svelte custom-elements not working
Labels: feature request,has workaround,svelte

**Describe the bug**
If using svelte with custom-element, you have to set `customElement: true` in `main.js`.
This breaks the UI of Storybook, if using svelte CSF configs. (since loader is in this repo, I open issue here).
Svelte CSF configs, do also have .svelte ending, so are picked up by svelte loader, and compiled with  `customElement: true`, which is wrong. They should not. Setting in main.js for svelte compiler should only match acutal components and not `ABC.stories.svelte`

**To Reproduce**
Check repo, no story found, even setup. If you set  `customElement: false` in `main.js`. it works. But then custom-element cannot be shown correctly.
https://github.com/alexanderniebuhr/playground-storybook

**Expected behavior**
svelte component as custom-element, and svelte story as normal svelte. Then I want to have the option to use the component as such: ( this is necessary, so that the code preview of storybook shows 'f-button' correctly, and copy & paste does work )

```svelte
<script>
  import { Meta, Template, Story } from "@storybook/addon-svelte-csf";
  import "./Button.svelte";
</script>

<Meta
  title="Example/Button"

  !!!! IMPORTANT !!!!
  component="f-button"


  argTypes={{
    label: { control: "text" },
    primary: { control: "boolean" },
    backgroundColor: { control: "color" },
    size: {
      control: { type: "select", options: ["small", "medium", "large"] },
    },
    onClick: { action: "onClick" },
  }}
/>

<Template let:args>

   !!!! IMPORTANT !!!!
  <f-button {...args} on:click={args.onClick} />

</Template>

<Story
  name="Primary"
  args={{
    primary: true,
    label: "Button",
  }}
/>
```

**System**
  System:
    OS: Windows 10 10.0.21343
    CPU: (24) x64 AMD Ryzen 9 3900XT 12-Core Processor
  Binaries:
    Node: 15.12.0 - C:\Program Files\nodejs\node.EXE
    npm: 7.6.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Spartan (44.21343.1000.0), Chromium (89.0.774.63)
  npmPackages:
    @storybook/addon-actions: ^6.2.0-rc.11 => 6.2.0-rc.11
    @storybook/addon-essentials: ^6.2.0-rc.11 => 6.2.0-rc.11
    @storybook/addon-links: ^6.2.0-rc.11 => 6.2.0-rc.11
    @storybook/addon-svelte-csf: ^1.0.0 => 1.0.0
    @storybook/svelte: ^6.2.0-rc.11 => 6.2.0-rc.11

**Additional context**
it might be a good way not to build stories.svelte files with svelte options loader, suggested here:
https://github.com/svelte-society/recipes-mvp/issues/41#issue-638005462
Repository: godot
Issue: Directory for log files is not created in HTML5 export
Labels: bug,platform:web,topic:porting

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:** 3.2.3
<!-- Specify commit hash if using non-official build. -->


**OS/device including version:** Linux
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->


**Issue description:** In HTML5 export, the log file is not written if the directory does not exist. In other exports the missing directory silently gets created.
<!-- What happened, and what was expected. -->


**Steps to reproduce:** Configure log files at a directory under user://, e.g. using the default value user://logs/godot.log. Export to HTML5 and open the log file within Godot. You get error 7, File does not exist. It works for user://godot.log, i.e. without a directory. It also works at least under Linux, where the log directory simply gets created if it does not exist.


**Minimal reproduction project:**
[bugreport.zip](https://github.com/godotengine/godot/files/6224413/bugreport.zip)



<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
Repository: pytorch
Issue: [autocast] DataParallel in a single process - possibly outdated docs
Labels: oncall: distributed

## 📚 Documentation

[Here](https://pytorch.org/docs/stable/notes/amp_examples.html#dataparallel-in-a-single-process), the documentation says that a special treatment has to be done for `autocast` under DataParallel and multiple gpus.

We found that this is not so and the special treatment appears not to be needed. That is `with autocast(): model(...)` in the training loop works the same with DP and DDP.

We tested that `torch.is_autocast_enabled()` returns true inside the model under DP and the speed is the same w/ or w/o the special treatment.

Is it possible that the documentation is outdated? or are we missing something subtle here?

Thank you.

@mcarilli 

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @agolynski @SciPioneer @H-Huang @mrzzd @cbalioglu
Repository: TypeScript
Issue: TypeScript refactoring: 'Convert overload list to single line signature' loses argument bindings
Labels: Bug,Domain: Refactorings

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
- VS Code Version: 1.54.3 (2b9aebd5354a3629c3aba0a5f5df49f43d6689f8)
- OS Version: Windows 10 20H2 (OS Build 19042.867)

Steps to Reproduce:

1. Create TypeScript file
2. Write code that supports 'Convert overload list to single line signature' refactoring, for example
```ts
function foo(num: number): void;
function foo(str: string, nums: number[]): void;
function foo(first: number | string, second?: number[]): void {
  console.log(first, second);
}
```
3. Use 'Convert overload list to single line signature'

**Actual result**
Code is refactored to
```ts
function foo(...args: [num: number] | [str: string, nums: number[]]): void {
  console.log(first, second);
}
```
Function body doesn't have `first` and `second` defined.

**Expected result**
Code is refactored to
```ts
function foo(...[first, second]: [num: number] | [str: string, nums: number[]]): void {
  console.log(first, second);
}
```
Code is valid.

<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported direct to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
Repository: pytorch
Issue: FX tracer doesn't support returning a new instance of `object` subclass from module forward
Labels: triaged,module: fx

## To Reproduce

If the data class is inherited from `NamedTuple`, FX-tracing works:
```python
import torch
from torch.fx import symbolic_trace
from typing import NamedTuple


class SparseFeaturesNamedTuple(NamedTuple):
    lengths: torch.Tensor
    values: torch.Tensor


class ModuleReturnsSparseFeaturesNamedTuple(torch.nn.Module):
    def __init__(self):
        super().__init__()
        
    def forward(self, inputs: SparseFeaturesNamedTuple):
        return SparseFeaturesNamedTuple(inputs.lengths, inputs.values)
    

m = ModuleReturnsSparseFeaturesNamedTuple()
tm = symbolic_trace(m)
```

However, if the data class is inherited from `object`, FX-tracing doesn't work:
```python
import torch
from torch.fx import symbolic_trace


class SparseFeaturesObject(object):
    def __init__(
        self,
        lengths: torch.Tensor,
        values: torch.Tensor,
    ):
        self.lengths = lengths
        self.values = values


class ModuleReturnsSparseFeaturesObject(torch.nn.Module):
    def __init__(self):
        super().__init__()

    def forward(self, inputs: SparseFeaturesObject):
        return SparseFeaturesObject(inputs.lengths, inputs.values)


m = ModuleReturnsSparseFeaturesObject()
tm = symbolic_trace(m)

"""Gives error:
Traceback (most recent call last):
  File "test_yf225.py", line 24, in <module>
    tm = symbolic_trace(m)
  File "/data/miniconda3/lib/python3.7/site-packages/torch/fx/symbolic_trace.py", line 621, in symbolic_trace
    graph = tracer.trace(root, concrete_args)
  File "/data/miniconda3/lib/python3.7/site-packages/torch/fx/symbolic_trace.py", line 368, in trace
    self.create_node('output', 'output', (self.create_arg(fn(*args)),), {},
  File "/data/miniconda3/lib/python3.7/site-packages/torch/fx/symbolic_trace.py", line 155, in create_arg
    return super().create_arg(a)
  File "/data/miniconda3/lib/python3.7/site-packages/torch/fx/proxy.py", line 121, in create_arg
    raise NotImplementedError(f"argument of type: {type(a)}")
NotImplementedError: argument of type: <class '__main__.SparseFeaturesObject'>
"""
```

## Expected behavior

Should both cases work the same with FX, or is the 2nd case explicitly not supported?

One nice thing about `object` subclass is that we can have instance methods inside the class that are supported by TorchScript. (The same is not true with `NamedTuple` subclass.)

cc. @jamesr66a @suo 

cc @ezyang @SherlockNoMad
Repository: TypeScript
Issue: Print a warning if using 'ts.factory' in a transformer
Labels: Suggestion,Experience Enhancement

Noted in https://github.com/microsoft/TypeScript/issues/43407#issuecomment-809724790, we should discourage the use of `ts.factory` from within a transformer, as the transformer should instead use the `factory` provided to its `context` argument.