sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: named tensor doesn't work with deepcopy
Labels: triaged,module: named tensor

### 🐛 Describe the bug

When using a deepcopy on tensor which is named, then it looses names attributes

repro below:
`x = torch.empty(2,2, names=('N', 'C'))
print(x)
tensor([[1.2773e-08, 4.5764e-41],
        [3.0878e-31, 4.5764e-41]], names=('N', 'C'))

import copy

y = copy.deepcopy(x)

print(y)

tensor([[1.2773e-08, 4.5764e-41],
        [3.0878e-31, 4.5764e-41]])`

### Versions

PyTorch version: 1.10.0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.3 LTS (x86_64)
GCC version: (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Clang version: Could not collect
CMake version: version 3.16.3
Libc version: glibc-2.31

Python version: 3.8.10 (default, Nov 26 2021, 20:14:08)  [GCC 9.3.0] (64-bit runtime)
Python platform: Linux-5.4.0-77-generic-x86_64-with-glibc2.29
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

Versions of relevant libraries:
[pip3] numpy==1.20.3
[pip3] pytorch-lightning==1.5.0
[pip3] torch==1.10.0
[pip3] torchmetrics==0.6.2
[pip3] torchvision==0.11.0
[conda] Could not collect

cc @zou3519
Repository: vscode
Issue: Provide quick fix for deprecated settings in json
Labels: feature-request,settings-editor

<img width="628" alt="CleanShot 2022-01-05 at 09 13 47@2x" src="https://user-images.githubusercontent.com/35271042/148259888-8c00b252-c893-48b7-b1f6-0a60b05cdebf.png">

It would be great if in the settings json where settings have been deprecated in favor of others that we provide a "quick fix" in the hover. 

Trying to copy the new setting was extremely painful 😤

https://user-images.githubusercontent.com/35271042/148260276-749293ec-9c9b-461b-8875-1fbaf3733c67.mp4
Repository: flutter
Issue: Ensure the engine can build with any combination of graphics backends supported by each platform
Labels: a: tests,engine,P2,team-engine,triaged-engine

This issue came up [here](https://github.com/flutter/engine/pull/29391#issuecomment-1001820612).

The backends are as follows:
* shell_enable_vulkan (all platforms)
* shell_enable_gl (all platforms)
* shell_enable_software (all platforms)
* shell_enable_metal (macos/ios only)

Try enabling each shell in isolation on each supported platform and ensure the builds succeeds. For any case where it doesn't work, add necessary guards to decouple targets from the backend. For example, if either `shell_enable_gl` or `shell_enable_vulkan` is false, the relevant tests in the `embedder_unittests_gl` target should be disabled.
Repository: rust
Issue: unexpected panic while compiling paru on archlinux ARM aarch64
Labels: I-ICE,T-compiler,C-bug,O-AArch64

while using `makepkg` and rustc 1.57.0 on archlinux ARM on rpi3 (armv8/aarch64), one gets:

```
   Compiling paru v1.9.2 (/home/cassini/asp/paru/src/paru-1.9.2)
thread 'rustc' panicked at 'called `Result::unwrap()` on an `Err` value: "invalid enum variant tag while decoding `ExpnKind`, expected 0..5"', compiler/rustc_metadata/src/rmeta/decoder.rs:265:29
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.57.0 (Arch Linux rust 1:1.57.0-1) running on aarch64-unknown-linux-gnu

note: compiler flags: -C opt-level=3 -C lto=off -C embed-bitcode=no -C codegen-units=1 --crate-type lib

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
#0 [explicit_item_bounds] finding item bounds for `hyper::body::to_bytes::to_bytes::{opaque#0}`
#1 [item_bounds] elaborating item bounds for `hyper::body::to_bytes::to_bytes::{opaque#0}`
end of query stack
error: could not compile `paru`
warning: build failed, waiting for other jobs to finish...
error: build failed
==> ERREUR : Une erreur s’est produite dans build().
    Abandon…
```

I just discovered there is prebuild binary package so I will not try to make it work.
Repository: pytorch
Issue: DISABLED test_gpu_simple (__main__.TensorPipeCudaDistAutogradTest)
Labels: high priority,triage review,oncall: distributed,module: flaky-tests,module: rpc,skipped

Platforms: mac
This test was disabled because it is failing on master ([recent examples](http://torch-ci.com/failure/test_gpu_simple%2C%20TensorPipeCudaDistAutogradTest)).

cc @ezyang @gchanan @zou3519 @bdhirsh @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @jjlilley @mrzzd
Repository: pytorch
Issue: DISABLED test_all_reduce_coalesced_group_min (__main__.TestDistBackendWithSpawn)
Labels: oncall: distributed,skipped

Platforms: mac

This test was disabled because it is failing on master ([recent examples](http://torch-ci.com/failure/test_all_reduce_coalesced_group_min%2C%20TestDistBackendWithSpawn)).

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang
Repository: pytorch
Issue: DISABLED test_barrier_timeout_group (__main__.TestDistBackendWithSpawn)
Labels: oncall: distributed,skipped

Platforms: mac

This test was disabled because it is failing on master ([recent examples](http://torch-ci.com/failure/test_barrier_timeout_group%2C%20TestDistBackendWithSpawn)).

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @kwen2501
Repository: godot
Issue: TextureProgress nine patch stretch doesn't work in clockwise base fill mode (GLES3)
Labels: bug,topic:rendering,topic:2d

### Godot version

Godot Engine v3.4.2.stable.flathub.45eaa2daf

### System information

Linux, Fedora 34, OpenGL ES 3.0 Renderer: Mesa Intel(R) UHD Graphics 620 (KBL GT2)

### Issue description

TextureProgress nine patch stretch option doesn't work correctly. Indeed it works as excepted for `Left To Right`, `Right To Left`, `Top To Bottom`, `Bottom To Top`, `Top To Bottom`, `Billinear (Left And Right)`, `Billinear (Top And Bottom)` **but not for** `Clockwise`, `Counter Clockwise`, `Clockwise and Counter Clockwise`.

In `Left To Right` fill mode:
![image](https://user-images.githubusercontent.com/11078371/148265179-c0912e31-0ea7-4a2c-864e-71979b0d1da0.png)

In `Clockwise` fill mode:
![image](https://user-images.githubusercontent.com/11078371/148265266-3f043dfe-1b8c-4e25-81a0-901d4ccf9640.png)


Note, this issue was already reported: https://github.com/godotengine/godot/issues/33222#issuecomment-1005895440 and should had been fixed by: https://github.com/godotengine/godot/pull/45815.

### Steps to reproduce

Check the attached minimal reproductible project below. Change the fill mode from `Left To Right` to `Clockwise` and see the difference in the scene or when running the project.

### Minimal reproduction project


[godot-bug-report.zip](https://github.com/godotengine/godot/files/7816819/godot-bug-report.zip)
Repository: PowerToys
Issue: [PT Run] [WindowWalker] Result view not updating when two windows have same properties
Labels: Issue-Bug,Product-PowerToys Run,Area-User Interface,Priority-1

### Microsoft PowerToys version

0.51.1

### Running as admin

- [ ] Yes

### Area(s) with issue?

PowerToys Run

### Steps to reproduce

1. Change number if results in settings to three. (Only to not need to open to many windows on reproducing this.)
2. Open for example cmd (named `da`), cmd (named `dab`) and two instances of "My Computer" (Explorer).
3. Navigate with arrow keys down to second explorer window.

### ✔️ Expected Behavior

Second explorer result is shown in the list.

### ❌ Actual Behavior

List doesn't scroll to second explorer result, but it is selected.

![pt-ww-resultview](https://user-images.githubusercontent.com/61519853/148273029-d744a77a-9e8c-44b2-9b9c-55987147041f.gif)

![pt-ww-resultview2](https://user-images.githubusercontent.com/61519853/148272937-3a269a1a-4e94-4a72-a0cd-58425547604c.gif)


### Other Software

_No response_

---

_cc: @franky920920_

_Issue for bug mentioned here: https://github.com/microsoft/PowerToys/issues/13637#issuecomment-1005167413._
Repository: godot
Issue: Strange behavior when using NORMAL in a 2D fragment shader
Labels: topic:rendering,documentation,topic:shaders,topic:2d

### Godot version

3.4.2 stable

### System information

Windows 10, GLES3, NVIDIA GTX 1050 Ti

### Issue description

Assigning to NORMAL from fragment() in a canvas_item shader doesn't seem to produce the expected results.

Here are two Sprites, with a Light2D between them:
![image](https://user-images.githubusercontent.com/49374226/148270533-dde3573d-de48-4b6e-ac06-a24ff6627680.png)

The sprites are identical except the one on the left has a Material with this shader:
```
shader_type canvas_item;
void fragment()
{
	NORMAL = vec3(0.0, 0.0, 1.0);
}
```
vec3(0.0, 0.0, 1.0) is AFAIK the same as the default, flat normal map assigned to sprites, so I expect the two sprites to be lit identically, but the left sprite isn't lit at all. Changing the values of NORMAL will cause it to pick up some light, but a flat NORMAL always produces this behavior for me. In fact, the exact same behavior can be produced by replacing the line above with just `NORMAL;`, so it seems like referencing NORMAL in a fragment shader at all causes some change to the sprite's normals. I couldn't find any documented behavior that explains this.


### Steps to reproduce

The main scene of the minimal reproduction project is set up with two Sprites and a Light2D as detailed above. Observe that the sprite on the left ignores the effect from the Light2D unless the line in its shader's fragment function is commented out.

### Minimal reproduction project

[normal.zip](https://github.com/godotengine/godot/files/7817267/normal.zip)
Repository: pytorch
Issue: Support hooks-based checkpointing API with DDP
Labels: high priority,triage review,oncall: distributed,module: ddp

### 🚀 The feature, motivation and pitch

Recently a version of checkpoint based on saved variable hooks was landed in PR: https://github.com/pytorch/pytorch/pull/69508, although support for this version of checkpointing working with DDP is still pending: https://github.com/pytorch/pytorch/pull/69060.

The main issue is that the reentrant-based checkpointing (traditional version) ran the first forward pass under `torch.no_grad()` and DDP was able to use the `torch.is_grad_enabled` flag to ensure various accounting in its forward pass is done only once.

The hooks-based checkpointing API does not do this, so we need either a way to tell DDP that the forward pass is being recomputed (what https://github.com/pytorch/pytorch/pull/69060 seeks to do) or refactor DDP such that the forward pass is idempotent in all cases (including static graph).

### Alternatives

_No response_

### Additional context

_No response_

cc @ezyang @gchanan @zou3519 @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang
Repository: go
Issue: cmd/compile: SIGSEGV on openbsd-arm64-jsing builder
Labels: OS-OpenBSD,NeedsInvestigation,arch-arm64,compiler/runtime

`greplogs --dashboard -md -l -e '(?ms)\Aopenbsd-arm64-jsing.*go tool compile: signal: segmentation fault' --since=2021-01-01`

[2022-01-02T14:27:43-c886143/openbsd-arm64-jsing](https://build.golang.org/log/4c4cd2bd2fa6fc48b570ae524b53109b549dfb66)

```
--- FAIL: TestImportTypeparamTests (71.90s)
    --- FAIL: TestImportTypeparamTests/issue47713.go (0.21s)
        gcimporter_test.go:52: go tool compile: signal: segmentation fault (core dumped)
        gcimporter_test.go:53: go tool compile issue47713.go failed: exit status 1
FAIL
FAIL	go/internal/gcimporter	80.608s
```

CC @4a6f656c
Repository: go
Issue: x/vulndb: link credits to appropriate user 
Labels: NeedsDecision,vulncheck or vulndb

When the credit in a report is attributed to a username, we should change make the `@username` a link to the correct page. For example, https://github.com/golang/vulndb/blob/1179110444905751f6788f14cb5a2b4c60231232/reports/GO-2020-0032.yaml#L20 should be changed to `https://github.com/christi3k` when running `vulnreport create`.

/cc @golang/vulndb
Repository: vscode
Issue: Cannot open local terminal when remote container is opened as a workspace
Labels: bug,remote,confirmation-pending,terminal-process

<!-- Please search existing issues to avoid creating duplicates, and review our troubleshooting tips: https://code.visualstudio.com/docs/remote/troubleshooting -->
<!-- Please attach logs to help us diagnose your issue. Learn more here: https://code.visualstudio.com/docs/remote/troubleshooting#_reporting-issues -->
<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: https://code.visualstudio.com/insiders/ -->

- VSCode Version: 1.63.2
- Local OS Version: arch
- Remote OS Version: ubuntu 20.04
- Remote Extension/Connection Type: Docker
- Logs:

Steps to Reproduce:

Create a minimal workspace and devcontainer file

workspace.code-workspace
```json
{
	"folders": [
		{
			"path": "."
		}
	],
	"settings": {}
}
```

.devcontainer/devcontainer.json
```json
{
  "image": "ubuntu:20.04"
}
```

Select `Open Workspace in container` command in the command panel, then select `Terminal: Create New Integrated Terminal (local)`.

The terminal fails to open and an error popup shows up:
```
The terminal process failed to launch: Starting directory (cwd) "~/ws/vscode-container-workspace-terminal-bug/workspace.code-workspace" is not a directory.
```

As a workaround, opening the workspace indirectly via `Open Folder in container`, then `Open Workspace From File`, results in working local terminal.

<!-- Check to see if the problem is general, with a specific extension, or only happens when remote -->
Does this issue occur when you try this locally?: No
Does this issue occur when you try this locally and all extensions are disabled?: No

<!-- If your issue only appears in Codespaces, please visit: https://github.com/github/feedback/discussions/categories/codespaces-feedback -->
Repository: pytorch
Issue: Add flag for functional.Jacobian to return output as well
Labels: module: autograd,triaged,enhancement

### 🚀 The feature, motivation and pitch

I am working on implicit differentiation of an expensive function. I would like both its output (with computational graph intact) and the Jacobian of the function with respect to one of its inputs. This can be easily done by running the function twice, but I would prefer to save the computation time.

For example, I want to be able to run:

```
input = torch.randn(5)
param = torch.randn(5).requires_grad_()
def func(input):
    return input**2 + param

output, J = torch.autograd.functional.jacobian(func, input)
```

Such that output.backward() propagates gradients to `param` (whether or not it is connected to input in the computation graph is not important to me).

I have implemented this by a one-line change to the jacobian function to also return the output as well. I don't know if this is a use-case other people have, enough that it would warrant adding a "return_output" flag to the Jacobian function. At a high level, it feels odd to me that there is no built-in way to get an output which is computed as an intermediate step of the Jacobian calculation.

### Alternatives

_No response_

### Additional context

_No response_

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
Repository: terminal
Issue: Theme changes don't work correctly after opening the About box
Labels: Help Wanted,Issue-Bug,Product-Terminal,Priority-3,Area-SettingsUI

### Windows Terminal version

1.12.3472.0

### Windows build number

10.0.19041.1415

### Other Software

_No response_

### Steps to reproduce

1. Start Windows Terminal (don't just use an existing session).
2. Open the Settings UI, and go to the _Appearance_ section.
3. Set the _Theme_ to _Light_, and click _Save_.
4. Without closing the settings, open the _About_ box, and close it again.
5. Now switch the _Theme_ to _Dark_, and click _Save_.


### Expected Behavior

The UI colors should change to the dark theme.

### Actual Behavior

Most of the UI remains using the light theme, but some elements appear to be updated in such a way that they become invisible.

![image](https://user-images.githubusercontent.com/4181424/148288163-7b90c170-ca0b-4d7a-bf30-5e7becd6f76b.png)

This breaks in a similar way when switching from dark to light, and it's also not only the _About_ box that triggers it - I think any popup dialog will do (e.g. the "Do you want to close all tabs?" warning has the same effect).

If you open the _About_ box again, it temporarily "fixes" the problem (i.e. it refreshes the colors correctly), but that only last until you try and change the theme again.
Repository: TypeScript
Issue: Soft Asserts and Contained Crashes
Labels: Suggestion,In Discussion,Infrastructure

Much of the time, assertions are used to check our own assumptions - however, many of those assumptions have recoverable behaviors if they cease to be true.

As a simple example, let's consider document highlights. TypeScript provides document highlights on any of the `switch`, `case` or `break` keywords of a `switch`/`case` statement.

```ts
[|switch|] (foo) {
  [|case|] 0:
    foo()
  [|case|] 1:
    bar();
    break;
}
```

Now imagine that JavaScript ends up getting a `fallthrough` keyword. If I recall correctly, document highlights throws an exception and provides no results if nobody remembers update document highlights for the `fallthrough` keyword (and in fact, this has happened with other features).

Alternatively, document highlights could somehow log that an expectation was violated and find a more general behavior in the meantime like providing highlights for all `fallthrough` keywords in the current file. This would ensure that some results can be returned instead of no results.

Document highlights are subtle though. What about a more impactful feature that you really feel a failure around? For a different example, let's discuss completions.

A failure in auto-completion is *very* noticeable. Obviously using the same idea from above, an assertion failure in the language service shouldn't tank an entire completions request.

Going even further though, we also have a set of *failure conditions* that may be partially recoverable. This occasionally comes up from failures in our auto-import provider. Completions use a scoped program instance to provide auto-import completions. In spirit, a failure in auto-imports shouldn't ruin local completions, but we sure would like to know about when a user isn't getting auto-imports!

From what @andrewbranch has raised, because this entire subsystem of completions is silo'd off, it can be wrapped in a `try`/`catch` and logged in a similar manner.

This class of "soft" assertions and failures can be provided as "hard" errors on the command line, and turned into events for language services. An insiders version of Visual Studio Code could prompt a dialog to file a bug when it encounters these soft assertions, and stable versions of VS/VS Code could surface them through telemetry (similar to what it does for regular crashes today).
Repository: go
Issue: x/build/cmd/gopherbot: comment on bad subrepo issue references
Labels: Builders,NeedsInvestigation,FeatureRequest

Most subrepos track issues on golang/go, and thus require issue references in commit messages in the form `golang/go#nnn`, otherwise the reference will not work properly.

Gopherbot could detect raw `#nnn` issue references on subrepos and leave a comment suggesting changing them.

e.g., on https://golang.org/cl/375754, I put the wrong issue reference and didn't notice until after I submitted the CL.
Repository: rust
Issue: Benchmark entirely unfair locks for parallel rustc
Labels: A-parallel-queries,WG-compiler-parallel

My theory is that the accounting necessary for implementing eventually fair locks in parking lot causes an instruction count increase for parallel rusrc by a couple of percents without improving the wall time. Without this accounting taking a lock should be a matter of a cmpxchg and possibly a futex wait if it was already locked. I don't think it matters as much if a thread is starved for extended periods of time rather than splitting this starving between threads as eventually the thread responsible for the starving will finish it's task and no longer cause any other threads to starve, thus guaranteeing progress. Whether I am right or not will need to be shown using benchmarking. It would also be interesting to see how long a spinlock should happen before falling back to a futex wait, if it should happen at all given that some query locks are probably held for extended periods of time.
Repository: TypeScript
Issue: Infer the types of es class fields
Labels: Bug

# Suggestion

## 🔍 Search Terms

es class fields infer type 

## ✅ Viability Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

For the types of (private) es class fields to be infered just like what happens with regular properties.

## 📃 Motivating Example

Consider the following JavaScript (not TypeScript):
```js
class Foo {
    constructor() {
        this.x = null;
    }

    setX() {
        this.x = 5;
    }

    getX() {
        return this.x;
    }
}
```
([playground](https://www.typescriptlang.org/play?filetype=js#code/MYGwhgzhAEBiD29oG8BQ0PWPAdhALgE4Cuw+8hAFAJQrqYP4AWAlhAHQAe0AvNDsRAgA3PQwBfVGOgQApvgAaNOg0asO3PgFZRDSdIDm8pbTSrMhecUI5ozNl12ZJ4oA))

In this case the type of `this.x` and return type of `getX()` are infered to be `number`. Wouldn't it make sense to do the same with private class fields? For the record, this is still JavaScript, not TypeScript.
```js
class Foo {
    x = null;

    setX() {
        this.x = 5;
//      ^^^^^^----- Type '5' is not assignable to type 'null'.
    }

    getX() {
        return this.x;
    }
}
```
([playground](https://www.typescriptlang.org/play?strictNullChecks=true&noUncheckedIndexedAccess=true&noUnusedLocals=true&noUnusedParameters=true&useUnknownInCatchVariables=true&exactOptionalPropertyTypes=true&noFallthroughCasesInSwitch=true&noImplicitOverride=true&noPropertyAccessFromIndexSignature=true&filetype=js#code/MYGwhgzhAEBiD29oG8BQ0PQB7QLzQDsBXEEAblXUwgFMAXADQAoBKFKzTOgCwEsIAdDnwBWCgHpxnDAD058gLRKl0ACoBPAA41oAchG7o-QvDrRIEXgHMCYAEYgddJHS07dxUroEdoAX0pOK3pmNjRpTAAneiJIgmgefiEKTgC-IA))

## 💻 Use Cases

It's pretty tedious to have to add jsdoc for every private class field. So I think it could be nice if it used the same inference system as regular properties.