sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: neovim
Issue: :terminal does not render colored text from "dotnet" command 
Labels: bug,terminal

### Neovim version (nvim -v)

0.6.1

### Vim (not Nvim) behaves the same?

no, 8.2

### Operating system/version

macOS 12.2.1

### Terminal name/version

iTerm 3.4.15

### $TERM environment variable

Iterm-256color

### Installation

homebrew

### How to reproduce the issue

!dotnet run Program.cs

### Expected behavior

### The problem is that I don't know why the C# compiles on Nvim Terminal like this:
<img width="1680" alt="Screen Shot 2022-04-07 at 17 06 57" src="https://user-images.githubusercontent.com/83110215/162205789-9d20c61f-9eb5-48f0-9bb3-079c055cbf08.png">

### If I run C# program in `iTerm`, it will work:
<img width="1680" alt="Screen Shot 2022-04-07 at 17 08 23" src="https://user-images.githubusercontent.com/83110215/162206069-8628c39f-1dee-4978-a901-dbf94611b6a7.png">

### Also it runs on `Vim`:
<img width="1680" alt="Screen Shot 2022-04-07 at 17 19 33" src="https://user-images.githubusercontent.com/83110215/162208371-d09a92e4-a53b-4dff-ac2d-a8c38beb79fc.png">

### The version of `Vim`:
<img width="473" alt="Screen Shot 2022-04-07 at 17 22 52" src="https://user-images.githubusercontent.com/83110215/162208856-c874945e-d537-4e6d-88eb-76b6cd94ec85.png">


### And I don't know how to make script into `init.vim`, that automatically goes in the directory of file that I opened and run it in the new tab. I did something similar but it doesn't work correctly:
<img width="1680" alt="Screen Shot 2022-04-07 at 17 14 22" src="https://user-images.githubusercontent.com/83110215/162207121-9b4addda-d8f7-4756-b826-7b565542ce65.png">



### Actual behavior

How to solve it?
Repository: pytorch
Issue: Require PyTorch test suite to be warnings clean
Labels: module: tests,triaged,better-engineering

### 🐛 Describe the bug

We have too many warnings.

One way to avoid rampant over-warnings is to make warnings in the test suite a hard failure. Here's the idea:

1. By default, all warnings turn into errors in the test suite
2. If you explicitly want to test a deprecated API, you have to explicitly use a helper function, e.g., self.deprecated(lambda: deprecated_call()), which then explicitly requires a deprecation warning to be raised
3. If you add a new warning, you're expected to audit all the sites in the test suite which now start failing.

Now, (3) is quite a big lift if you're adding a deprecation warning that affects a lot of code. My first response is: don't do that! (If everyone is using the API, you probably shouldn't deprecate it.) Second, we should have some tooling for automatically updating the test suite lines that are raising warnings (the same way expecttest knows how to edit Python files to add warnings). We'll need this anyway for getting into this universe to start with.

### Versions

master

cc @mruberry
Repository: godot
Issue: Inconsistent color rounding behaviour; causes mismatched colors in screenshots
Labels: bug,topic:core,confirmed

### Godot version

v3.4.4.stable.official.419e713a2

### System information

Windows 10, GLES3

### Issue description

In Variant accessing the r8, g8, b8, a8 members rounds them:

```cpp
} else if (*str == "r8") {
	valid = true;
	return (int)Math::round(v->r * 255.0);
} else if (*str == "g8") {
	valid = true;
	return (int)Math::round(v->g * 255.0);
} else if (*str == "b8") {
	valid = true;
	return (int)Math::round(v->b * 255.0);
} else if (*str == "a8") {
	valid = true;
	return (int)Math::round(v->a * 255.0);
}
```

However in Image::set_pixel the values get floored instead:
```cpp
case FORMAT_RGBA8: {
	ptr[ofs * 4 + 0] = uint8_t(CLAMP(p_color.r * 255.0, 0, 255));
	ptr[ofs * 4 + 1] = uint8_t(CLAMP(p_color.g * 255.0, 0, 255));
	ptr[ofs * 4 + 2] = uint8_t(CLAMP(p_color.b * 255.0, 0, 255));
	ptr[ofs * 4 + 3] = uint8_t(CLAMP(p_color.a * 255.0, 0, 255));

} break;
```

This causes several issues:

- Colors in GradientTexture2D are slightly darker than if directly passed to a shader.
- The colors in screenshots created via ViewportTexture::get_data are slightly darker than displayed on screen if the format needs to be converted (Image::convert uses set_pixel)
- Images manually filled with set_pixel can contain different colors than intended.

The rounding behavior seems to be the ground truth as that is also how color values passed to a shader seem to be output to the screen.

This issue applies to both 4.0 and 3.4.

### Steps to reproduce

```gdscript
func check_img_colors():
	var clr = Color(0.65, 0.65, 0.65)
	var img = Image.new()
	img.create(1, 1, false, Image.FORMAT_RGBA8)
	img.lock()
	img.set_pixel(0, 0, clr)
	assert(clr.r8 == img.get_pixel(0, 0).r8)
	img.unlock()
```
Repository: material-ui
Issue: [Autocomplete] When input equals an option, hitting enter creates an option instead of selecting it
Labels: bug 🐛,component: autocomplete

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Current behavior 😯

As described in the title. I'm not sure whether it's a bug or a feature and I can't find a prop to disable this very confusing behavior. It's creating a problem where tags can get duplicated, which raises an error in the console, which negates the default behavior of restricting the autocomplete to unique tags only.

### Expected behavior 🤔

Change the value with the reason `"selectOption"`.

### Steps to reproduce 🕹

Steps:

1. Go to a free solo multiple autocomplete demo: https://codesandbox.io/s/1yf706?file=/demo.tsx.
2. Type an option name that already exists, **press** ESC, and hit the Return key.
3. Watch `onChange` get triggered with the reason `"createOption"`.


### Context 🔦

A unique multiple autocomplete field.

### Your environment 🌎

<details>
  <summary>`npx @mui/envinfo`</summary>

```
System:
  OS: macOS 12.3.1
Binaries:
  Node: 14.19.0 - ~/.nvm/versions/node/v14.19.0/bin/node
  Yarn: 1.22.17 - ~/.nvm/versions/node/v14.19.0/bin/yarn
  npm: 6.14.16 - ~/.nvm/versions/node/v14.19.0/bin/npm
Browsers:
  Chrome: 100.0.4896.75
  Edge: Not Found
  Firefox: Not Found
  Safari: 15.4
npmPackages:
  @emotion/react: ^11.8.1 => 11.8.1 
  @emotion/styled: ^11.8.1 => 11.8.1 
  @mui/base:  5.0.0-alpha.69 
  @mui/lab: ^5.0.0-alpha.75 => 5.0.0-alpha.75 
  @mui/material: ^5.4.2 => 5.4.2 
  @mui/private-theming:  5.4.2 
  @mui/styled-engine:  5.4.2 
  @mui/system:  5.4.2 
  @mui/types:  7.1.2 
  @mui/utils:  5.4.2 
  @types/react: ^17.0.0 => 17.0.35 
  react: ^17.0.1 => 17.0.2 
  react-dom: ^17.0.1 => 17.0.2 
  typescript: 4.5.4 => 4.5.4
```
</details>
Repository: go
Issue: x/net/http2: TestServer failures with "write: broken pipe" on openbsd 
Labels: OS-OpenBSD,NeedsInvestigation,arch-arm64,arch-mips

```
--- FAIL: TestServer (10.64s)
    server_test.go:349: Error writing initial SETTINGS frame from client to server: write tcp 127.0.0.1:21462->127.0.0.1:34837: write: broken pipe
    server_test.go:267: Framer write log:
        2022-04-07 10:25:48.715770953 Framer 0xc001405500: wrote SETTINGS len=0
FAIL
FAIL	golang.org/x/net/http2	282.655s
```

`greplogs --dashboard -md -l -e 'FAIL: TestServer .*(?:\n    .*)*write: broken pipe'`

[2022-04-06T20:46:47-749bd19-81ae993/openbsd-mips64-jsing](https://build.golang.org/log/b9d9e08993ac187f12a21030731c9d01a9442ddb)
[2022-04-06T03:13:34-749bd19-5bb2628/openbsd-mips64-jsing](https://build.golang.org/log/f9163c3a1e4f4fb1cfba4e3b42cd6447193fa4d9)
[2022-02-08T15:30:12-cd36cc0-ef06a5f/openbsd-mips64-jsing](https://build.golang.org/log/d2dcf6c64d65369665cb64d08308b5e5f4efeaf6)
[2021-09-12T16:46:58-a5e0955-ad97d20/openbsd-arm64-jsing](https://build.golang.org/log/90305ace3af7b02c9e361970d536b66ba7dcbd59)

(attn @4a6f656c; CC @neild)

Since this only appears to affect certain OpenBSD builders, I plan to add a test skip and not follow up further.
Repository: pytorch
Issue: `torch.cuda.is_bf16_supported()` seem to not work properly
Labels: module: cuda,triaged,module: bfloat16

### 🐛 Describe the bug

Hi, I have a laptop with Nvidia T1200 (compute capability 7.5) and CUDA 11.6 and a call to `torch.cuda.is_bf16_supported()` is returning `False` (because of the check whether compute capability is at least 8).

However, it seems to work.

Here is the snippet that is demonstrating the issue

```python
>>> import torch
>>> torch.cuda.is_available()
True
>>> torch.cuda.is_bf16_supported()
False
>>> t = torch.rand(10, device='cuda', dtype=torch.bfloat16)
>>> t
tensor([0.3301, 0.0522, 0.4609, 0.9648, 0.3945, 0.1299, 0.3477, 0.7656, 0.8008,
        0.8203], device='cuda:0', dtype=torch.bfloat16)
>>> m = torch.nn.Sequential(torch.nn.Linear(10, 1, device='cuda', dtype=torch.bfloat16), torch.nn.ReLU())
>>> m(t).backward()
>>> m[0]
Linear(in_features=10, out_features=1, bias=True)
>>> m[0].weight
Parameter containing:
tensor([[ 0.1152, -0.1729, -0.0972, -0.1963, -0.1001, -0.1416, -0.2520,  0.1855,
         -0.0107, -0.2432]], device='cuda:0', dtype=torch.bfloat16,
       requires_grad=True)

```

### Versions

Collecting environment information...
PyTorch version: 1.11.0+cu113
Is debug build: False
CUDA used to build PyTorch: 11.3
ROCM used to build PyTorch: N/A

OS: Arch Linux (x86_64)
GCC version: (GCC) 11.2.0
Clang version: Could not collect
CMake version: version 3.23.0
Libc version: glibc-2.35

Python version: 3.9.11 (main, Apr  7 2022, 15:33:34)  [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-5.17.1-zen1-1-zen-x86_64-with-glibc2.35
Is CUDA available: True
CUDA runtime version: 11.6.112
GPU models and configuration: GPU 0: NVIDIA T1200 Laptop GPU
Nvidia driver version: 510.60.02
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] mypy==0.942
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.22.3
[pip3] torch==1.11.0+cu113
[pip3] torchmetrics==0.7.3
[pip3] torchtext==0.12.0
[pip3] torchvision==0.12.0+cu113
[conda] Could not collect


cc @ngimel
Repository: TypeScript
Issue: Better tsconfig.json generation
Labels: Suggestion,Experience Enhancement,Rescheduled

The current generation of `tsconfig.json` is a manual and undiscoverable process inside VS Code. I suggest the following improvements:

* We should introduce a command "Create `tsconfig.json`", this command should try to autodetect as much as possible from the workspace, and if needed ask the user some questions via QuickPick API. This command would in the end generate `tsconfig.json`, similar to how VS Code tries to help with the creation of `launch.json`
* "Create tsconfig.json" should be contributed to the command palette and in the explorer context menu (if tsconfig.json is not present)
* if we want to market some attributes in `tsconfig.json` we should write them in those files even if they have a default value so users can discover them
* The commands should be contributed to the Explorer Context Menu - if `tsconfig.json` can not be found in the workspace.
* If there is a typescript file open, and there is no `tsconfig.json` in the repository we should offer the user to automatically to create a `tsconfig.json`. I think a notification in this case is acceptable.

Step 2: we can consider to make the Problems welcome view contributable. So we can add a button in the problems view to generate `tsconfig.json` if no errors have been detected in the workspace.

With these improvements I believe we will make it much easier for the users to create a new typescript workspace.
Repository: TypeScript
Issue: Better jsconfig.json generation
Labels: Suggestion,Experience Enhancement,Rescheduled

Similar to https://github.com/microsoft/TypeScript/issues/48597

Once we improve the `tsconfig.json` generation we need to see what from that worked well and apply it for `jsconfig.json` generation.
Repository: create-react-app
Issue: create-react-app error
Labels: needs triage

hi everyone when installing create-react-app i come upon an error 
this is the code

C:\WINDOWS\system32>npx create-react-app my-app
Need to install the following packages:
  create-react-app
Ok to proceed? (y) y
'create-react-app' is not recognized as an internal or external command,
operable program or batch file.

C:\WINDOWS\system32>npm start
npm ERR! code ENOENT
npm ERR! syscall open
npm ERR! path C:\WINDOWS\system32/package.json
npm ERR! errno -4058
npm ERR! enoent ENOENT: no such file or directory, open 'C:\WINDOWS\system32\package.json'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent

npm ERR! A complete log of this run can be found in
npm ERR!     C:\Users\Ela EKİZ\AppData\Local\npm-cache\_logs\2022-04-07T14_55_36_160Z-debug-0.log
Repository: PowerToys
Issue: Open/Edit As Admin Context Option
Labels: Idea-New PowerToy

### Description of the new feature / enhancement

When right clicking a file, have the option to "Edit as Admin"

### Scenario when this would be used?

Text Configuration Files (for my use case, it's adding to the hosts file.)

### Supporting information

This would allow a convenience workflow for admins to open in an editor a specific file as an admin (triggerring the UAC prompt when running the editor) the currently allowed method in Windows appears only to be first to open the editor as an admin, either by context menu, or Ctrl+Shift+Enter and second locating the file in the open dialogue.
Repository: terminal
Issue: Cursor appears in unfocused window when the buffer changes in tmux
Labels: Help Wanted,Issue-Bug,Area-TerminalControl,Product-Terminal,Priority-2

### Windows Terminal version

1.11.3471.0

### Windows build number

10.0.19044.1586

### Other Software

OpenSSH provided by Microsoft

### Steps to reproduce

1. SSH to a server or WSL
2. Open tmux
3. Unfocus the Terminal, the cursor will disappear as expected
4. Wait for something to change in the buffer (could be tmux's statusbar, or do `sleep 5 && echo hi`)



### Expected Behavior

I expect the cursor to not reappear until the terminal regains focus.

### Actual Behavior

The cursor reappears when something changes in the buffer, making it difficult to know if the window is focused or not.

https://user-images.githubusercontent.com/13711380/162254647-d28bd968-dbfe-48e8-b30c-a3bf25949023.mp4
Repository: pytorch
Issue: [quant] PackedLinearWeight::apply_dynamic_impl does not handle ReLUFused template argument
Labels: oncall: quantization,low priority,triaged

### 🐛 Describe the bug

The `ReLUFused` argument is not handled in https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/quantized/cpu/qlinear_dynamic.cpp#L22, but handled in the caller function: https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/quantized/cpu/qlinear_dynamic.cpp#L370, we need to fix the problem by moving this code inside `PackedLinearWeight::apply_dynamic_impl`

### Versions

PyTorch master

cc @jianyuh @raghuramank100 @jamesr66a @vkuzo @jgong5 @Xia-Weiwen @leslie-fang-intel @jerryzh168 @navahgar
Repository: node
Issue: arm64 cross-compile fails on amd64
Labels: build,arm

### Version

16.14.2

### Platform

Linux bx.ee 5.4.0-89-generic #100-Ubuntu SMP Fri Sep 24 14:50:10 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

### Subsystem

_No response_

### What steps will reproduce the bug?

./configure --cross-compiling --dest-cpu arm64 --dest-os linux && make -j8 

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

Every time

### What is the expected behavior?

If cross-compiling is supported, I would expect that supplying the `--cross-compiling` flag would avoid attempting to run cross-compiled executables like `icupkg` on the host architecture which wouldn't rationally be expected to succeed.

### What do you see instead?

```
  LD_LIBRARY_PATH=/home/jgowdy/projects/build-node-pac/node/out/Release/lib.host:/home/jgowdy/projects/build-node-pac/node/out/Release/lib.target:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; cd ../tools/icu; mkdir -p /home/jgowdy/projects/build-node-pac/node/out/Release/obj/gen; "/home/jgowdy/projects/build-node-pac/node/out/Release/icupkg" -tl ../../deps/icu-tmp/icudt70l.dat "/home/jgowdy/projects/build-node-pac/node/out/Release/obj/gen/icudt70l.dat"
/bin/sh: 1: /home/jgowdy/projects/build-node-pac/node/out/Release/icupkg: Exec format error
```


### Additional information

I did see https://github.com/nodejs/node/issues/11931 however this isn't related to Android, just being able to cross-compile arm64 Linux binaries on amd64.
Repository: yt-dlp
Issue: [Feature Request] Wayback Machine capture fallback for Youtube
Labels: PR-needed,site-enhancement

### Checklist

- [X] I'm reporting a feature request
- [X] I've looked through the [README](https://github.com/yt-dlp/yt-dlp#readme)
- [X] I've verified that I'm running yt-dlp version **2022.03.08.1** ([update instructions](https://github.com/yt-dlp/yt-dlp#update)) or later (specify commit)
- [X] I've searched the [bugtracker](https://github.com/yt-dlp/yt-dlp/issues?q=) for similar issues including closed ones. DO NOT post duplicates
- [X] I've read the [guidelines for opening an issue](https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#opening-an-issue)

### Description

this feature request is a option (something like --wayback-fallback) for if the youtube video that the user tries to download is unavailable it will fallback to a wayback machine capture of the video

### Verbose log

_No response_
Repository: flutter
Issue: Generalize gesture details that concerns cartesian positioning in a common interface
Labels: framework,f: gestures,c: proposal,P3,team-framework,triaged-framework

## Use case

When generalizing over gesture details, we have to be specific about which details class we are using. This is not a big problem, but we could use of some generalization to make more abstract code.

For example, I have code similar to this in a production app:

```dart
// Currently, I have not how to guarantee that `DetailsType` is going to be a gesture details object
class GestureDetailsWithAdditionalData<DetailsType, T extends Object> {
  const LayerGestureDetails({
    required this.details,
    required this.data,
  });

  final DetailsType details;
  final T data;
}

ValueChanged<DetailsType> gesturerFor<DetailsType>({
  required ValueChanged<GestureDetailsWithAdditionalData<DetailsType, Object>>? Function(Layer) gestureFunction,
  required Offset Function(T) getLocalPosition,
}) {
  return (DetailsType details) {
    final layer = getLayer(...);
    final localPosition = getLocalPosition(details);
    // Do something with localPosition
    final gesture = gestureFunction(layer);
  };
}

// Usage
gesturerFor<TapDownDetails>(
  gestureFunction: (layer) => layer.onTapUp,
  getLocalPosition: (details) => details.localPosition,
);
```

If they implemented a common abstraction, the code could be simplified and made safer:

```dart
// Now I guarantee that details is something expected
class GestureDetailsWithAdditionalData<DetailsType extends PositionRelatedGestureDetails, T extends Object> {
  const LayerGestureDetails({
    required this.details,
    required this.data,
  });

  final DetailsType details;
  final T data;
}

ValueChanged<DetailsType> gesturerFor<DetailsType>(ValueChanged<GestureDetailsWithAdditionalData<DetailsType, Object>>? Function(Layer) gestureFunction) {
  return (DetailsType details) {
    final layer = getLayer(...);
    // I now can use details.localPosition directly
    final gesture = gestureFunction(layer);
  };
}

// Usage now guarantees that the returned function works on details
gesturerFor<TapDownDetails>(gestureFunction: (layer) => layer.onTapUp);
```

## Proposal

Almost all gesture details related to cartesian positioning have in common a `localPosition` and `globalPosition`.

* `DragDownDetails`
* `DragStartDetails`
* `DragUpdateDetails`
* `ForcePressDetails`
* `LongPressDownDetails`
* `LongPressEndDetails`
* `LongPressMoveUpdateDetails`
* `LongPressStartDetails`
* `SerialTapDownDetails`
* `SerialTapUpDetails`
* `TapDownDetails`
* `TapUpDetails`

It would be nice and, as far as I can tell, a non-breaking change to make a common interface for them:

```dart
abstract class PositionRelatedGestureDetails {
  /// Documentation...
  Offset get localPosition;

  /// Documentation...
  Offset get globalPosition;
}
```

Scale gestures also have similar properties (`focalPoint` and `localFocalPoint`), but I am not sure if they should be included somehow in this generalization.
Repository: rust
Issue: Odd macro diagnostic "no rules expected the token ``" with empty vis fragment capture
Labels: A-diagnostics,A-macros,T-compiler,D-papercut

When capturing an empty token sequence with a `vis` fragment and failing to further match this capture in following macro invocations rustc emits the `no rules expected the token \`\`` message which is confusing given the lack of a token in the error.

Given the following code: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a6a7515732cc426c68cc418b25b4ed92

```rust
macro_rules! makro {
    (()) => {};
    ($vis:vis ,) => {
        makro!(($vis));
    };
}
makro!(,);
```

The current output is:

```
error: no rules expected the token ``
 --> src/lib.rs:4:17
  |
1 | macro_rules! makro {
  | ------------------ when calling this macro
...
4 |         makro!(($vis));
  |                 ^^^^ no rules expected this token in macro call
...
7 | makro!(,);
  | --------- in this macro invocation
  |
  = note: this error originates in the macro `makro` (in Nightly builds, run with -Z macro-backtrace for more info)

error: could not compile `playground` due to previous error
```

The error is obviously legitimate, the fragment captures nothing but still gets turned into an opaque thing even though it is empty, which then fails to match any of the macro arms in the recursive calls.

The diagnostics weren't written with the possibility of an empty non-repetition capture in mind though, so the error message becomes rather weird in this one scenario.

I am not sure how to improve on the message here though.