sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: neovim
Issue: Invalid UTF-8 in `grid_line` ui event
Labels: bug,ui,ui-extensibility

### Neovim version (nvim -v)

0.7.0

### Vim (not Nvim) behaves the same?

Not related to vim

### Operating system/version

PopOs 21.10

### Terminal name/version

gnvim

### $TERM environment variable

xterm-256color

### Installation

Build from source

### How to reproduce the issue

Open [this](https://github.com/neovim/neovim/blob/1f1a65a9e4c602cd80458b213c28eadbdb5b1de1/test/functional/legacy/044_099_regexp_multibyte_magic_spec.lua#L14-L33) file and scroll into those lines (lines 28 and 29 to be exact) in a GUI and neovim will send invalid UTF-8 in a `grid_line` event.


### Expected behavior

Work as documented, e.g. send valid UTF-8.

What this should be in practice is up to debate I suppose. For reference, gedit shows a warning and displays the bytes sequence with red color:

![image](https://user-images.githubusercontent.com/4594126/169686414-4e97a45b-7b8b-470f-b1cc-e321abcbd95d.png)

Another solid option could be to send the "replacement character" (e.g.  U+FFFD �) in place of invalid UTF-8 data.

### Actual behavior

Neovim sends invalid UTF-8 in `grid_line` event.

This is how the TUI renders those invalid lines:

![image](https://user-images.githubusercontent.com/4594126/169685993-ce5e3dfa-4a3d-4da7-ae13-c01e7a6f2608.png)

Wheres the log file with `-u NONE`: [nvim.log](https://github.com/neovim/neovim/files/8749078/nvim.log)
Repository: flutter
Issue: [Proposal] add clickable region in InputDecorator
Labels: c: new feature,framework,f: material design,c: proposal,team-design,triaged-design

 # use case
 
 Achieving this kind of input with a inkWell on the left is pretty damn hard:
 
 
![image](https://user-images.githubusercontent.com/22280985/169688066-ea035357-76bc-4447-b9da-2ed0ed8891b2.png)

This is convoluted to do. You have to measure the height of the input decorator, remove the error height when there is an error, change the height when it's underline or outline border, when there is a label or not and so on. Then you have to wrap the input decorator in a stack, have the clickable region be the correct height and width, but it also has to be aligned correctly, the width also depends on a series of factor from InputDecorator. Then comes the aligments issues with the main textField...

I've tried everything, multiple times nothing is straightforward here.

Simply put to achieve something like that you have to hack your way around InputDecorator, because it's not build to do this kind of things. It makes packages harder to maintain that they need to be. 

# proposed

This is just an idea, I'm sure there are better ways but:

 - add `prefixRegion` & `suffixRegion` to input decorator which would add a inkWell around the prefix / suffix.
 - keep prefix correctly aligned
Repository: vscode
Issue: Duplicate output in devtools when extension writes to process.stdout
Labels: extension-host,under-discussion

<!-- ⚠️⚠️ 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. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes/No

<!-- 🪓 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 directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.67.2
- OS Version: macOS 12.3.1

Steps to Reproduce:

1. Write to `process.stdout` from an extension in development mode.
2. The output is duplicated in the VS Code developer tools.

<img width="1840" alt="image" src="https://user-images.githubusercontent.com/24731903/169689959-d795492c-bd74-4c06-a603-a0643b53ef95.png">

<details><summary><code>extension.ts</code></summary>

```ts
// The module 'vscode' contains the VS Code extensibility API
// Import the module and reference it with the alias vscode in your code below
import * as vscode from 'vscode';

// this method is called when your extension is activated
// your extension is activated the very first time the command is executed
export function activate(context: vscode.ExtensionContext) {

	process.stdout.write("Foo\n");

	// Use the console to output diagnostic information (console.log) and errors (console.error)
	// This line of code will only be executed once when your extension is activated
	console.log('Congratulations, your extension "vscode-stdout-bug" is now active!');

	// The command has been defined in the package.json file
	// Now provide the implementation of the command with registerCommand
	// The commandId parameter must match the command field in package.json
	let disposable = vscode.commands.registerCommand('vscode-stdout-bug.helloWorld', () => {
		// The code you place here will be executed every time your command is executed
		// Display a message box to the user
		vscode.window.showInformationMessage('Hello World from vscode-stdout-bug!');
	});

	context.subscriptions.push(disposable);
}

// this method is called when your extension is deactivated
export function deactivate() {}
```
</details>
Repository: create-react-app
Issue: react-dev-utils: expect to export `guessEditor` in launchEditor.js
Labels: issue: proposal,needs triage

### Is your proposal related to a problem? Yes

<!--
  Provide a clear and concise description of what the problem is.
  For example, "I'm always frustrated when..."
-->

I want to use `guessEditor ` to do something, e.g.:
```ts
const [editor] = guessEditor()
if (editor === 'code') {
 // some logic
}
```

### Describe the solution you'd like

<!--
  Provide a clear and concise description of what you want to happen.
-->
[show code](https://github.com/facebook/create-react-app/blob/main/packages/react-dev-utils/launchEditor.js#L197)
```diff
# https://github.com/facebook/create-react-app/blob/main/packages/react-dev-utils/launchEditor.js#L197

- function guessEditor() {}
+ export function guessEditor() {}
```

### Describe alternatives you've considered

<!--
  Let us know about other solutions you've tried or researched.
-->

Copy the source code to my file

### Additional context

<!--
  Is there anything else you can add about the proposal?
  You might want to link to related issues here, if you haven't already.
-->

nothing
Repository: kubernetes
Issue: Unable to attach or mount volumes: timed out waiting for the condition
Labels: kind/bug,sig/scalability,sig/storage,triage/accepted

### What happened?

PVC mount gets timed out when the number of parallel pod requests with pvc access goes past 400. This caused pod PVC mount retries(several of these in some cases.) and delays the pod startup.

`3m1s        Warning   FailedMount              pod/nginx-deployment-7c54456f-2sk89    Unable to attach or mount volumes: unmounted volumes=[stresstest-pvc kube-api-access-f2nnp], unattached volumes=[stresstest-pvc kube-api-access-f2nnp]: timed out waiting for the condition`


### What did you expect to happen?

PVC should get mounted on the pods without any failedMount messages.

### How can we reproduce it (as minimally and precisely as possible)?

The issue can be easily reproduced on a 10 node cluster with Kubernetes deployment having 800 pod replicas asking to mount the same PVC.

### Anything else we need to know?

This issue is related to an old bug [84169](https://github.com/kubernetes/kubernetes/issues/84169) that was closed saying the issue got fixed with k8s 1.17+ but it seems the issue still persists.

### Kubernetes version

<details>

```console
$ kubectl version
# paste output here
Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.1", GitCommit:"86ec240af8cbd1b60bcc4c03c20da9b98005b92e", GitTreeState:"clean", BuildDate:"2021-12-16T11:41:01Z", GoVersion:"go1.17.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.8", GitCommit:"7061dbbf75f9f82e8ab21f9be7e8ffcaae8e0d44", GitTreeState:"clean", BuildDate:"2022-03-16T14:04:34Z", GoVersion:"go1.16.15", Compiler:"gc", Platform:"linux/amd64"}
```

</details>


### Cloud provider

<details>
onprem installation with kubespray
</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here
Ubuntu 20.04
# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>
Repository: rust
Issue: Clarify that patterns may be used in trait implementations when explaining E0642
Labels: A-diagnostics,T-compiler

I encountered E0642 which disallows patterns in functions without a body, particularly trait methods. It was not immediately clear to me that this meant one could still *implement* a trait method using patterns. Due to the fact that most trait implementations don't stray far from the provided argument names, it took me a moment to remember that the argument names in trait definitions are essentially filler.

I would expect others may have similar confusion with how to handle the error, and it could be avoided if the error explanation reminded the user that this only applies to the *trait definition*, not its implementations.

Currently, ```rustc --explain E0642``` outputs:
```rust
Trait methods currently cannot take patterns as arguments.

Erroneous code example:

trait Foo {
    fn foo((x, y): (i32, i32)); // error: patterns aren't allowed
                                //        in trait methods
}

You can instead use a single name for the argument:

trait Foo {
    fn foo(x_and_y: (i32, i32)); // ok!
}
```
I believe an addition like the following would aid clarity:
```rust
And you can use patterns in its implementations:

impl Foo for Bar {
    fn foo((x, y): (i32, i32)) { /* ... */ } // ok!
}
```
Repository: TypeScript
Issue: Increase default tsc --init target over time
Labels: Suggestion,Awaiting More Feedback

# Suggestion

## 🔍 Search Terms

increase tsc init target es2016 default

## ✅ 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

As of 2022, all releases within the last year of browsers serving >0.1% of worldwide users support at least all of ECMAScript 2019 and nearly all of ECMAScript 2020-2021, while the LTS-supported versions of Node.js support all of ECMAScript 2021. There's very little reason not to have a target at least as high as `"es2019"`.

How about increasing the default `tsc --init` value for `target` in later TypeScript versions over time to match the highest ECMAScript version supported by all LTS Node versions? That'd be `"es2021"` today.

## 📃 Motivating Example

Higher targets by default for consumers running `tsc --init` means they'll be able to use more language features as `String.replaceAll` by default. It's confusing to `tsc --init`, then not be able to use them.

## 💻 Use Cases

Increasing default targets to emit code much cleaner in modern runtimes gives a nicer default output for new TypeScript projects. For beginners to TypeScript in particular, it makes the learning curve a little easier as they won't have to mess with configuration options to be able to use basic features.

This issue is thematically similar to but not the same as #47572 and #47573. Those issue are about changing the default compiler options when no value is specified on the CLI or in a TSConfig file. This issue is about changing the target specified when using `tsc --init`.
Repository: neovim
Issue: 'insertmode' emulation doesn't work with ctrlp
Labels: compatibility,breaking-change

## Problem

When using the config documented at `:help 'insertmode'` to emulate Vim 'insertmode',

```
autocmd VimEnter,CmdlineLeave,WinEnter,WinScrolled,BufEnter * silent! if &modifiable | startinsert | endif
inoremap <esc> <nop>
inoremap <c-l> <esc>
nnoremap <esc> i
```

the [ctrlp](https://github.com/ctrlpvim/ctrlp.vim) plugin has these quirks :

> - In ctrlp's list of currently open files, I can see the formatting, e.g. `<bi>#=</bi>`
> - when switching between a normal file and a readonly buffer(using my mouse through a split, like `:help`) It does stay in normal mode if I've been in normal mode before switching buffers, but It stays in insert mode without any error if I've been there in the previous buffer
> 
> _Originally posted by @M1cha in https://github.com/neovim/neovim/issues/18547#issuecomment-1127224202_

## Expected behavior

The config documented at `:help 'insertmode'` should not break plugins (unless those plugins are also broken with Vim's 'insertmode').
Repository: pytorch
Issue: Adam is 30% slower than SGD on Apple Metal.
Labels: module: performance,module: optimizer,triaged,module: mps

### 🐛 Describe the bug

I am benchmarking the Apple silicon on PyTorch and Adam is 30% slower than SGD.
<img width="1126" alt="image" src="https://user-images.githubusercontent.com/18441985/169709366-b415c24d-7a37-4cce-94ec-6c68e0a7d1dd.png">
You can check my experiments on this wandb workspace: 
https://wandb.ai/capecape/M1_TF_vs_PT?workspace=user-capecape

I am on latest Pytorch 22/05 nightly.

### Versions

Collecting environment information...
PyTorch version: 1.13.0.dev20220522
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.4 (arm64)
GCC version: Could not collect
Clang version: 13.1.6 (clang-1316.0.21.2.5)
CMake version: version 3.23.1
Libc version: N/A

Python version: 3.10.4 | packaged by conda-forge | (main, Mar 24 2022, 17:42:03) [Clang 12.0.1 ] (64-bit runtime)
Python platform: macOS-12.4-arm64-arm-64bit
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
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.22.3
[pip3] torch==1.13.0.dev20220522
[pip3] torchaudio==0.11.0
[pip3] torchvision==0.12.0
[conda] numpy                     1.22.3                   pypi_0    pypi
[conda] torch                     1.13.0.dev20220522          pypi_0    pypi
[conda] torchaudio                0.11.0                   pypi_0    pypi
[conda] torchvision               0.12.0                   pypi_0    pypi

cc @VitalyFedyunin @ngimel @vincentqb @jbschlosser @albanD
Repository: godot
Issue: Unique resources are not unique (AnimationPlayer Animations)
Labels: enhancement,topic:editor,topic:animation

### Godot version

4.0 Alpha 7

### System information

Windows 10 Nvidia GTX 1060 Intel i5 4690k

### Issue description

If you set an animation to be "local to scene", and attempt to edit the animation, changes made will propagate to all other instances of the animation player, REGARDLESS of "local to scene" being ticked.
![Image3](https://user-images.githubusercontent.com/83078010/169718758-3f653edf-5f84-4c5c-b52c-6093622d1ec4.jpg)

![Image4](https://user-images.githubusercontent.com/83078010/169718761-8ebbf5fd-f616-4be1-b982-df302d694656.jpg)
![Image5](https://user-images.githubusercontent.com/83078010/169718765-e58a0487-5872-45b1-9a57-f3826655a4ae.jpg)
![Image6](https://user-images.githubusercontent.com/83078010/169718768-8db3deb0-0d92-45a9-a12b-ec29b8ea8e90.jpg)

Trying to edit keyframes via code in an instance of a scene will cause this change to happen to ALL instances of the same scene.

### Steps to reproduce

1. Create an animation player
2. Set a keyframe value manually
3. Mark the scene as "make local to scene"
4. Instance two copies of this animation player
5. Edit a keyframe value via code in 1 animation player
6. Play the animation
This change in one of the animation players will still propagate to the other one.

### Minimal reproduction project

[UniqueResourcesBug.zip](https://github.com/godotengine/godot/files/8750387/UniqueResourcesBug.zip)
Repository: rust
Issue: Diagnostic regression when rustc cannot specialize (using `min_specialization`)
Labels: A-diagnostics,T-compiler,F-specialization

Note: I’m not sure if anything need to be done since specialization should allow the following code when it will fully be implemented, but currently the quality of the diagnostic is decreased when `min_specialization` is used:

---

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.

If you cannot produce a minimal reproduction case (something that would work in
isolation), please provide the steps or even link to a repository that causes
the problematic output to occur.
-->

Given the following code: [playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=476f816d693378654111678d1a30a757)

```rust
trait Trait {
    fn foo() {}
    fn bar() {}
}
struct Struct<F> {
    f: F,
}

impl<F> Trait for Struct<F>
where F: FnMut() -> ()
{
    fn foo() {}
}

impl<F> Trait for Struct<F>
where F: FnOnce() -> ()
{
    fn bar() {}
}
```

The current output is:

- With `#![feature(min_specialization)]`

```
error: cannot specialize on trait `FnMut`
  --> src/lib.rs:11:1
   |
11 | / impl<F> Trait for Struct<F>
12 | | where F: FnMut() -> ()
13 | | {
14 | |     fn foo() {}
15 | | }
   | |_^
```

- Without (the diagnostic is much better):

```
error[[E0119]](https://doc.rust-lang.org/nightly/error-index.html#E0119): conflicting implementations of trait `Trait` for type `Struct<_>`
  --> src/lib.rs:17:1
   |
11 | / impl<F> Trait for Struct<F>
12 | | where F: FnMut() -> ()
13 | | {
14 | |     fn foo() {}
15 | | }
   | |_- first implementation here
16 | 
17 | / impl<F> Trait for Struct<F>
18 | | where F: FnOnce() -> ()
19 | | {
20 | |     fn bar() {}
21 | | }
   | |_^ conflicting implementation for `Struct<_>`
```
Repository: terminal
Issue: Incorrect Translation for Chinese for short cut name: "rename tab", "change tab color"
Labels: Issue-Bug,Product-Terminal,Area-Localization

### Windows Terminal version

1.13.10983.0

### Windows build number

Microsoft Windows [版本 10.0.19042.1706] 

### Other Software

_No response_

### Steps to reproduce

open windows terminal preview  -> settings -> appearance -> language -> choose Chinese(China)

![图片](https://user-images.githubusercontent.com/234533/169721247-b2f0c0f4-ab55-44c8-af28-986b1d2154f2.png)

then restart terminal preview. 

then go to:  操作(Action) 

the translation is INCORRECT and strange, it maybe translated by non-computer experience users. 

![图片](https://user-images.githubusercontent.com/234533/169721357-f71e2b4d-bbbc-4cf0-8943-a1a3cad78866.png)

as the picture shown above, 

"Tab" called 标签页 in Chinese.  选项卡 is incorrect and deprecated and rarely heard. 




### Expected Behavior

- "rename tab title"  should be translated as: "重命名标签页"    
- "set the tab color" should be transated as: "设置标签页颜色"


### Actual Behavior

- "rename tab title"  currently is translated as: "正在重命名选项卡标题..."    
- "set the tab color" currently is translated as: "设置选项卡颜色..."
Repository: pytorch
Issue: Installation on Jetson target board
Labels: triaged,module: jetson

I'm installing the pytorch on Jetson target board(Nx, AGX, nano...).
Official Pytorch for jetson wheel is only for python3.6, so I use the installation through the source.
However, during the installation, the error occured. 
My environment is : 
- board : Jetson Xavier AGX
- JetPack : 4.4
- Cuda: 10.2
- gcc, g++ : 7
- Cmake : 3.18.2
- 
![image](https://user-images.githubusercontent.com/17849068/169723455-1885b9b6-2f9c-48e4-9b64-09a7f31a9574.png)
![image](https://user-images.githubusercontent.com/17849068/169723466-75ced077-1024-405d-8567-be2b78939dca.png)
How can i solve it..? plz help....

Also , How can i download the lower version of pytorch(ex, 1.8.0) by using this source?

cc @ptrblck @puririshi98
Repository: pytorch
Issue: DISABLED test_init_from_local_shards (__main__.TestShardedTensorFromLocalShards)
Labels: oncall: distributed,module: flaky-tests,skipped

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](http://torch-ci.com/failure/test_init_from_local_shards%2C%20TestShardedTensorFromLocalShards) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/6546960161).

Over the past 3 hours, it has been determined flaky in 2 workflow(s) with 3 red and 5 green.

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @kwen2501 @jjlilley @mrzzd