sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: GDScript inconsistent code behavior, giving error "Invalid operands 'Vector2' and 'Nil' in operator '*'"
Labels: topic:gdscript,needs testing

### Godot version

3.3.3 stable

### System information

Windows 10, GLES3, Nvidia GTX960m

### Issue description

 When I created my movement script, it initially worked. After extending a custom class, the below movement script immediately stopped working.  Giving the error "Invalid operands 'Vector2' and 'Nil' in operator '*'"
```gdscript
extends Area2D


# Declare member variables here. Examples:
# var a = 2
# var b = "text"
var direction = Vector2.ZERO
var bullet = load("res://Bullet.tscn")


var screen_size = Vector2.ZERO
func shoot():
	pass
func bomb():
	pass
func movement(delta):
	#general
	var speed = 150
	if Input.is_action_pressed("right"):
		direction.x += 1
	if Input.is_action_pressed("left"):
		direction.x -= 1
	if Input.is_action_pressed("down"):
		direction.y += 1
	if Input.is_action_pressed("up"):
		direction.y -= 1
	#normalizes diagonals
	if direction.length() > 1:
		direction = direction.normalized()
	#position changes
	position += direction * speed * delta
	position.x = clamp(position.x, 0, screen_size.x)
	position.y = clamp(position.y, 0, screen_size.y)#movement controls
func action():
	if Input.is_action_pressed("shotA"):
		print("shot A")
		shoot()
	if Input.is_action_pressed("shotB"):
		print("shot B")
		shoot()
	if Input.is_action_pressed("bomb"):
		print("bomb")#action controls

# Called when the node enters the scene tree for the first time.
func _ready():
	screen_size = get_viewport_rect().size
	print(screen_size)


# Called every frame. 'delta' is the elapsed time since the previous frame.
func _process(delta):
	#movement
	movement(delta)
	#action
	action()
```

On occasion, simply restarting godot fixes this error. On other occasions, adding a ```print``` call fixes the error. 

### Steps to reproduce

1. Open Godot
2. run game

### Minimal reproduction project

[dupe - Copy.zip](https://github.com/godotengine/godot/files/7233098/dupe.-.Copy.zip)
Repository: PowerToys
Issue: [Image Resizer]: In scan mode of Narrator, focus is going separately on label 'Fits within 854 x 480 pixels' and announces it in 4 parts while requiring it 3 down arrow key presses to navigate.
Labels: Issue-Bug,Area-Accessibility,A11yE+D,A11yUsable

### Microsoft PowerToys version

0.45.0

### Running as admin

- [ ] Yes

### Area(s) with issue?

Image Resizer

### Steps to reproduce

**Test Environment:**
OS: Windows 11 Version Dev (22454.1000)
App version: 0.45.0
App name: Power Toys
Screen Reader: Narrator

**Repro Steps:**

1. Launch 'Power Toys' application.
2. On left side Navigation pane navigate to Image resizer menu item and select it.
3. On Image resizer pane navigate to Small menu item control under 'Image sizes heading' and then press down arrow key to navigate to 'Fits within 854 x 480 pixels' label.
4. Observe the issue with screen reader's announcement.

**Note:**
Same issue is repro on all similar labels on the pane.

**User Impact:**
If user requires multiple down arrow shifts to navigate to a single label and does not announce the complete information in one go, screen reader dependent user will get confused.


https://user-images.githubusercontent.com/87321414/134860194-b7eb5f5a-36ac-4962-be13-6b05c651dfc5.mp4



### ✔️ Expected Behavior

In scan mode of Narrator focus should go to the label in a single go and it should announce the complete information as 'Fits within 854 by 480 pixels' at once without requiring multiple keystrokes.

### ❌ Actual Behavior

In scan mode of Narrator, focus is going separately on label 'Fits within 854 x 480 pixels' and announces it in 4 parts while requiring it 3 down arrow key presses to navigate. It announces 'Fits within' on first down arrow key stroke, and then '854', '480', 'pixels' respectively on each key stroke. Also focus does not announce any info about the by(x) symbol.

### Other Software

_No response_
Repository: pytorch
Issue: `torch.nn.functional.l1_loss` fails gradgradcheck for complex inputs
Labels: module: autograd,module: nn,triaged,module: complex

```python
import torch
from torch.autograd import gradgradcheck
from torch.nn.functional import l1_loss

input = torch.randn((), dtype=torch.complex128, requires_grad=True)
target = torch.randn((), dtype=torch.complex128)

gradgradcheck(l1_loss, inputs=(input, target))
```

```
RuntimeError: Expected isFloatingType(grad.scalar_type()) || (input_is_complex == grad_is_complex) to be true, but got false.  (Could this error message be improved?  If so, please report an enhancement request to PyTorch.)
```

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7 @mruberry @jbschlosser @walterddr @anjali411 @dylanbespalko
Repository: pytorch
Issue: repeat_interleave changes memory format from "channels last" to "contiguous"
Labels: triaged,module: memory format

## 🐛 Bug

When I use torch.repeat_interleave on a tensor that is stored in channels last format, the resulting tensor is not stored in the same format. I am not sure if you consider this a bug or just a lack in documentation, but that caused some problems in my projects.
Since nearly all operations return tensors in the same memory format, I expected this behavious also from this operator.

## To Reproduce

Steps to reproduce the behavior:
```
a = torch.empty([1,2,2,2], device="cuda:0", memory_format=torch.channels_last)
b = torch.repeat_interleave(a, 2, 0)
assert(b.is_contiguous(memory_format=torch.channels_last)) # this fails
```
## Expected behavior

I expected the result to be in same memory format as input tensor.

## Environment

Windows 10
PyTorch 1.9.0

cc @VitalyFedyunin @jamesr66a
Repository: create-react-app
Issue: Allow to Rename Files
Labels: issue: proposal,needs triage

It's common to rename files while working on a project:

- Rename files from .js to .ts (and .jsx to .tsx) when migrating gradually to TypeScript.
- Move a main function.js file to function/index.js when its complexity grows or a proper structure is needed.

However, as soon as you rename a file, you see the following error in development:

```
Failed to compile.

./src/test.js
Error: ENOENT: no such file or directory, open '/Users/my-user/test-project/src/test.js'
```

At this point, the only solution is to restart the development environment which takes time on some projects so it's not ideal.

### Proposed solution

If renaming a file results in the same resolved file for the compiler, it should be handled automatically.
Repository: terminal
Issue: Keybinding editor could be clearer
Labels: Product-Terminal,Issue-Task,Area-SettingsUI

### Windows Terminal version (or Windows build number)

Windows Terminal Preview Version: 1.11.2421.0

### Other Software

_No response_

### Steps to reproduce

- open terminal settings
- in "Actions" add a new command

### Expected Behavior

- new command edit working

### Actual Behavior

new command edit not working

This is an example trying to add the first drop-down option "Break into the debugger". The intended key cord was "alt+shift+b". Notice how "a", "l", "t" are echoed in the entry box, then when trying to add "+" it just show "shift+plus":

https://user-images.githubusercontent.com/3933920/134908242-c3c6dc01-eae0-477c-b28a-4586eda3d9a2.mp4
Repository: flutter
Issue: ResizeImage cannot resize gif 
Labels: framework,a: images,has reproducible steps,P2,found in release: 2.5,found in release: 2.6,team-framework,triaged-framework

CachedNetworkImage has memCacheWidth/memCacheHeight to reduce image memory, I think it implement by ResizeImage when look CachedNetworkImage src. But it's not work in gif, how to solve it?
```
ResizeImage.resizeIfNeeded(
          cacheWidth,
          cacheHeight,
          image,
        ),
```
Repository: node
Issue: Prevent native Error class hi-jacking in FS errors
Labels: errors

### Version

v16.9.0

### Platform

Linux vagrant-docker 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux

### Subsystem

fs

### What steps will reproduce the bug?

In the current state of the `promises` section of the native `fs` module, when an error occurs, the native type `Error` is hi-jacked and a `code` property is being added to the error object.

This can easily be reproduced with the following code:

```javascript
import { promises as FileSystem } from "fs";

try
{
    FileSystem.stat("/a/path/leading/to/nothing");
}
catch (error)
{
    console.log(Object.getPrototypeOf(error); // Will display the native class "Error"
    console.log(Object.getOwnPropertyDescriptors(error); // Will display the added code property that isn't native to Error.
}
```

### How often does it reproduce? Is there a required condition?

No required conditions outside of the use of the `fs` native module.

### What is the expected behavior?

This isn't a bug per-se but is a bad practice. A custom error of type `FileSystemError` should be thrown instead of hi-jacking the Error class to dynamically add a property to the object.
This behavior leads to problematic linting and testing with super-sets such as TypeScript or Eslint. Since `code` is not a native property of `Error` and dynamic property setting is often considered bad practice, it leads to situations where handling those specific issues requires extra effort to circumvent this design.

### What do you see instead?

_No response_

### Additional information

Ideally a custom `FileSystemError` should be created such as (Typescript example for types clarity):

```typescript
class FileSystemError extends Error
{
    public code: string; // Ideally should be an enum listing all the possible values.
}
```
Repository: go
Issue: encoding/json: unclear documentation for how `json.Unmarshal` and `json.Unmarshaler` interact with `null`
Labels: Documentation,NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.17.1 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/pierspowlesland/.cache/go-build"
GOENV="/home/pierspowlesland/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/pierspowlesland/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/pierspowlesland/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.1"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2076678693=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

Ran this code - https://play.golang.org/p/dHiWmj8X7KD

Which shows `json.Unmarshal` overwriting a struct with nil when passed `[]byte("null")`

### What did you expect to see?

I'm not sure exactly.

The go-playground example seems to be operating correctly if looking at the documentation for [json.Unmarshal](https://pkg.go.dev/encoding/json#Unmarshal)

>The JSON null value unmarshals into an interface, map, pointer, or slice by setting that Go value to nil. Because null is often used in JSON to mean “not present,” unmarshaling a JSON null into any other Go type has no effect on the value and produces no error.

But if looking at the documentation for [json.Unmarshaller](https://pkg.go.dev/encoding/json#Unmarshaler), it seems to not be operating correctly since it states that using json.Unmarshal to unmarshal `[]byte("null")` should be a no-op.

>By convention, to approximate the behavior of Unmarshal itself, Unmarshalers implement UnmarshalJSON([]byte("null")) as a no-op.

### What did you see instead?

`json.Unmarshal` overwriting a struct with nil when passed `[]byte("null")`
Repository: rust
Issue: Unsizing coercions apply in an inconvenient order with respect to constructor calls.
Labels: A-diagnostics,T-compiler,C-bug,A-coercions

```rust
use std::pin::Pin;

trait Trait {}

impl Trait for i32 {}

struct Foo<'a>(Pin<&'a mut (dyn Trait + Send)>);

fn main() {
    let mut a = 1;
    let _x = Foo(Pin::new(&mut a));
}
```

```
error[E0277]: `dyn Trait + Send` cannot be unpinned
   --> src/main.rs:11:27
    |
11  |     let _x = Foo(Pin::new(&mut a));
    |                           ^^^^^^ the trait `Unpin` is not implemented for `dyn Trait + Send`
    |
    = note: consider using `Box::pin`
note: required by `Pin::<P>::new`
```

It looks like it's trying to coerce the `i32` to `dyn Trait + Send` before constructing the `Pin` rather than constructing the `Pin<&mut i32>` and then coercing that to `Pin<&mut (dyn Trait + Send)>`. You can fix this by constructing the `Pin` in a separate statement, but ideally the compiler would defer the unsizing coercion:

```rust
use std::pin::Pin;

trait Trait {}

impl Trait for i32 {}

struct Foo<'a>(Pin<&'a mut (dyn Trait + Send)>);

fn main() {
    let mut a = 1;
    let pin = Pin::new(&mut a);
    let _x = Foo(pin);
}
```
Repository: pytorch
Issue: Add at least one config running GPU testing on sm_80+ cards
Labels: module: ci,triaged,enhancement

Some of PyTorch operators have specific codepath enabled only on sm_80+ GPUs which is currently not covered by CI

cc @ezyang @seemethere @malfet @pytorch/pytorch-dev-infra
Repository: deno
Issue: About-to-be-revoked blob URLs in workers and in dynamic import
Labels: bug,web

Issue #11817 dealt with the case where a `Request` constructed from a blob URL which was subsequently revoked was supposed to fetch successfully – because URL records in the spec have a "blob URL entry" field that gets populated with the corresponding blob when the URL is parsed, and that blob is used when fetching.

As I pointed out in https://github.com/denoland/deno/issues/11817#issuecomment-914470217, Deno still has this problem for blob URLs when creating workers and in dynamic imports – in the spec, the URL parsing happens synchronously when `new Worker(blobUrl)` or `import(blobUrl)` is called, and the blob URL entry gets used during fetching.
Repository: pytorch
Issue: Plain Tensor serialization does not save the content of `__dict__`.
Labels: module: serialization,triaged

As discussed in https://github.com/pytorch/pytorch/pull/65584
This was fixed for deepcopy, we need to also fix this in serialization.

cc @mruberry
Repository: PowerToys
Issue: Add Touch Feature to PowerRename to Change File(s) Date and Time
Labels: Idea-Enhancement,Product-PowerRename

### Description of the new feature / enhancement

Would love to see a Touch feature added to PowerRename.
The Touch option would allow the user to change the file's Date Modified to the current (or user defined) date and time

File
- myfile.txt-----8/23/2021 7:21 PM
- myfile2.txt----8/21/2021 7:05 PM
- myfile3.txt----6/18/2005 3:15 PM

Changes To
- myfile.txt-----9/27/2021 8:00 AM
- myfile2.txt----9/27/2021 8:00 AM
- myfile3.txt----9/27/2021 8:00 AM

etc...

### Scenario when this would be used?

It would be added to the PowerRename/Options Dialog.

I see two options below the Make Capitalized option

[  ]  Set Date and Time to Current System Date and Time
[  ]  Custom [mm/dd/yyyy] - [hh:mm] [  ] AM  [  ] PM

### Supporting information

_No response_
Repository: vscode
Issue: Open-source headless vscode
Labels: question-discussion

<!-- ⚠️⚠️ 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. -->
Hi

I would like to run VS Code headlessly. The use case is to run extensions programmatically.


- VS Code server for Remote Development is closed-source and has a prohibitive license
- Using [xvfb](https://code.visualstudio.com/api/working-with-extensions/continuous-integration#azure-pipelines) requires user to have installed it
- I just need an implementation of an [extension host](https://github.com/microsoft/vscode/blob/cc365575fcce480c38469b260f8f33eb89e36771/src/vs/workbench/api/common/extHost.api.impl.ts)

If this isn't in your roadmap, do you have any insights on how to implement such a feature?
Best
Repository: electron
Issue: [Bug]: `window.print()` without printers causes the main process to crash
Labels: platform/linux,component/printing,bug :beetle:,14-x-y,17-x-y,27-x-y

### Preflight Checklist

- [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Electron Version

14.0.1

### What operating system are you using?

Ubuntu

### Operating System Version

5.11.0-37-generic #41-Ubuntu SMP Mon Sep 20 16:39:20 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

### What arch are you using?

x64

### Last Known Working Electron version

13.4.0

### Expected Behavior

Calling `window.print()` should open the print window, even if there are no printers installed in the system.

### Actual Behavior

Calling `window.print()` from the renderer process crashes the main process.

### Testcase Gist URL

https://gist.github.com/85a5466567215173419a17982e79becb

### Additional Information

When the process crashes, the terminal prints:
```Crashing due to FD ownership violation:
#0 0x5616b9f1e143 <unknown>
#1 0x5616b9fc517c <unknown>
#2 0x5616b9fc5141 close
#3 0x7f4c4568817b <unknown>

Failed to get crash dump id.
Report Id: --2021-09-27 12:

Failed to get crash dump id.
Report Id: --2021-09-27 12:
PATH/TO/PROJECT/node_modules/electron/dist/electron exited with signal SIGILL
```

When calling `BrowserWindow.print()`, the console prints:
`[22590:0927/121740.971531:ERROR:print_backend_cups.cc(218)] CUPS: Error getting default printer: No destinations added.`
and the print callback *is* called with `[ false, 'no valid printers available' ]` for args. The main process does not crash, but the print window never opens (I have filed a similar issue back at v10.x: https://github.com/electron/electron/issues/25498)


On v13.4.0, a similar error message is printed, but the process does not crashes (or does, but recovers immediately somehow):

```
Crashing due to FD ownership violation:
#0 0x564e03bc1143
<unknown>
#1 0x564e03c6817c <unknown>
#2 0x564e03c68141 close
#3 0x7f20e79ea17b <unknown>

Electron exited with signal SIGTRAP.
Saving files to temp directory...
Saved files to /tmp/tmp-18241-0f2HhywGTnpu
Electron v13.4.0 started.
```
Also, the print window is correctly displayed, containing only the 'Print to File' option.
Repository: deno
Issue: Importing a revoked blob URL succeeds if it was imported in a different worker before revoking
Labels: bug,web

Different workers/threads have different module graphs, which means importing the same module will result in the same module object within a same thread, but in different module objects across threads:

<details>

```js
// main.js
const module1 = await import("./randomId.js");
console.log("Main thread (#1):", module1.RANDOM_ID);

const module2 = await import("./randomId.js");
console.log("Main thread (#2):", module2.RANDOM_ID);

const worker = new Worker(
    new URL("./worker.js", import.meta.url),
    {type: "module"}
);
```

```js
// worker.js
const module1 = await import("./randomId.js");
console.log("Worker thread (#1):", module1.RANDOM_ID);

const module2 = await import("./randomId.js");
console.log("Worker thread (#2):", module2.RANDOM_ID);
```

```js
// randomId.js
export const RANDOM_ID = crypto.randomUUID();
```

```
Main thread (#1): 23f163b0-e80e-41d1-8363-cb36b83f96be
Main thread (#2): 23f163b0-e80e-41d1-8363-cb36b83f96be
Worker thread (#1): fd2a439a-6db4-4d84-a96c-d8d05ef4d043
Worker thread (#2): fd2a439a-6db4-4d84-a96c-d8d05ef4d043
```
</details>

This means that within a thread/worker, you can import now-revoked blob URLs if they were imported for the first time before being revoked:

```js
const blob = new Blob([`console.log("Hi from blob!");`], {type: "text/javascript"});
const blobUrl = URL.createObjectURL(blob);

await import(blobUrl);

URL.revokeObjectURL(blobUrl);
await import(blobUrl);
```

But it should not be possible to import a revoked blob URL from a worker in which it has never been imported, even if it has been imported in a different thread. Deno will import it anyway, though:

```js
// main.js
const worker = new Worker(
    new URL("./worker.js", import.meta.url),
    {type: "module"}
);

const blob = new Blob([`console.log("Hi from blob!");`], {type: "text/javascript"});
const blobUrl = URL.createObjectURL(blob);

await import(blobUrl);

URL.revokeObjectURL(blobUrl);
worker.postMessage(blobUrl);
```

```js
// worker.js
self.addEventListener("message", async (evt) => {
    console.log("Importing from worker");
    await import(evt.data);  // should reject
});
```

------

This seems to be caused because Deno CLI has a cache of module sources, so that if the same module is imported from different workers, it doesn't result in multiple fetches. But since the cache is keyed by the URL, it doesn't take into consideration whether the blob has since been revoked.

This was found while investigating #12247, and a solution to this issue would have to consider that one as well.