sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Search decoration "badge" term ambiguous 
Labels: search,polish

Found while verifying https://github.com/microsoft/vscode/issues/157462

![Recording 2022-09-28 at 16 40 11](https://user-images.githubusercontent.com/30305945/192907240-4781fc6e-70d9-48fc-bde8-233d4389a9ca.gif)

Not sure if this is avoidable but figured I'd file an issue anyway.

I also associate the term 'badge' with the number count, and consider the 'added'/'modified'/'deleted' letters which the new search badge setting toggles to be decorations. This initially caused some confusion about what the setting was supposed to do and whether it was working. Could we consider either clarifying the setting description or (if the badge terminology is not the right one) renaming the setting?
Repository: go
Issue: runtime: reuse map string key instead of allocating
Labels: Performance,NeedsInvestigation,compiler/runtime

Consider the following benchmark:
```go
func Benchmark(b *testing.B) {
	m := map[string]int{}
	k := []byte("hello, world")

	b.ReportAllocs()
	for i := 0; i < b.N; i++ {
		m[string(k)] = 1
	}
}
```
This currently prints:
```
Benchmark    	37319388	        29.83 ns/op	      16 B/op	       1 allocs/op
```
I expect this to not allocate since it is reusing the same map entry every time.
The very first `mapassign` will need to allocate the string on heap, but subsequent operations should not need to.
This is related to #45045, which made this optimization harder.

\cc @randall77 @cuonglm
Repository: vscode
Issue: Feature Request: Allow hiding the "Open in Merge Editor" button
Labels: feature-request,merge-editor

<!-- ⚠️⚠️ 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. -->

Currently in the merge view the "Open in Merge Editor" button is always present, please allow us an option to never show this button. While I appreciate all the work on the other merge editor, my preference in the fantastic/simple existing inline and the blue button in the bottom right has the following downsides:
1. I have misclicked it several times (because it's in editor space) going to another (unintended) experience while trying to edit text.
2. It looks like a notification in the area where notifications are and draws attention.

Please allow an opt-out so this button isn't shown.

Related issue this stems from (to show interest): https://github.com/microsoft/vscode/issues/160806#issuecomment-1246696932
Repository: stable-diffusion-webui
Issue: CrossAttentionControl, Dreamfields-3D and Dreambooth implementation  
Labels: enhancement

Hey! I found these different Stable Diffusion library that I would love to see integrated on this repo. 

Curious if anyone else would also enjoy to use them

[Cross Attention Control](https://github.com/bloc97/CrossAttentionControl) by bloc97

`Cross Attention Control allows much finer control of the prompt by modifying the internal attention maps of the diffusion model during inference without the need for the user to input a mask and does so with minimal performance penalities (compared to clip guidance) and no additional training or fine-tuning of the diffusion model.`

[DreamFields 3D](https://github.com/shengyu-meng/dreamfields-3D) by shengyu-meng

`A  toolkit to generate 3D mesh model / video / NeRF instance / multiview images of colourful 3D objects by text and image prompts input`

[DreamBooth ](https://github.com/huggingface/diffusers/tree/main/examples/dreambooth)

`DreamBooth is a method to personalize text2image models like stable diffusion given just a few(3~5) images of a subject. The train_dreambooth.py script shows how to implement the training procedure and adapt it for stable diffusion.`


All of these seem extremely useful, especially Dreambooth training. 

Thanks for considering these!
Repository: pytorch
Issue: JIT model could return 'NaN' gradient after the first execution
Labels: oncall: jit

### 🐛 Describe the bug

JIT model could return 'NaN' gradient after the first execution

```py
import torch

class M(torch.nn.Module):
    def __init__(self):
        super().__init__()

    def forward(self, input):
        input = torch.nn.functional.relu(input)
        input = torch.cos(input)
        return torch.acos(input, )
input_tensor = torch.tensor([-1., -2.], dtype=torch.float32)

device = 'cuda'

m = M().to(device)
input = input_tensor.to(device)
from torch.autograd.functional import jacobian

input1 = input.clone().requires_grad_()
jac1 = jacobian(m, input1)
print(jac1)

jit_m = torch.jit.script(m)
# jit_m = torch.jit.trace(m, input.clone())
input2 = input.clone().requires_grad_()
input_temp = input.clone().requires_grad_()

jit_m(input_temp) # without this, it will output the same gradient

jac2 = jacobian(jit_m, input2)
print(jac2)
```

```
tensor([[0., 0.],
        [0., 0.]], device='cuda:0')
tensor([[nan, nan],
        [nan, nan]], device='cuda:0')
```

### Versions

```
Collecting environment information...
PyTorch version: 1.13.0.dev20220923+cu116
Is debug build: False
CUDA used to build PyTorch: 11.6
ROCM used to build PyTorch: N/A

OS: Ubuntu 22.04.1 LTS (x86_64)
GCC version: (Ubuntu 11.2.0-19ubuntu1) 11.2.0
Clang version: Could not collect
CMake version: Could not collect
Libc version: glibc-2.35

Python version: 3.9.13 (main, Aug 25 2022, 23:26:10)  [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-5.19.5-051905-generic-x86_64-with-glibc2.35
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: GPU 0: NVIDIA GeForce RTX 3060
Nvidia driver version: 515.65.01
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.23.3
[pip3] torch==1.13.0.dev20220923+cu116
[pip3] torchaudio==0.13.0.dev20220923+cu116
[pip3] torchvision==0.14.0.dev20220923+cu116
[conda] numpy                     1.23.3                   pypi_0    pypi
[conda] torch                     1.13.0.dev20220923+cu116          pypi_0    pypi
[conda] torchaudio                0.13.0.dev20220923+cu116          pypi_0    pypi
[conda] torchvision               0.14.0.dev20220923+cu116          pypi_0    pypi

```
Repository: pytorch
Issue: DISABLED test_aot_autograd_exhaustive_as_strided_scatter_cpu_float32 (__main__.TestEagerFusionOpInfoCPU)
Labels: triaged,module: flaky-tests,skipped,module: functorch

### 🐛 Describe the bug

Platforms: mac, macos

It looks like another side effect of https://github.com/pytorch/pytorch/pull/85794 and https://github.com/pytorch/pytorch/pull/85820 is that test_aot_autograd_exhaustive_as_strided_scatter_cpu_float32 (main.TestEagerFusionOpInfoCPU) is now flaky.  Here are some example:

* https://hud.pytorch.org/pytorch/pytorch/commit/0b93afb112d48bb6d89a1e183a90b403560e84e4
* https://hud.pytorch.org/pytorch/pytorch/commit/29c78266c046c7f83e7d84fc764af47e62ae9542 
* https://hud.pytorch.org/pytorch/pytorch/commit/5deeb09d4e3001adfd3d04139b4a330915069ea7

There is also an occurrence in Windows, but I won't disable the test there yet untill i see more of them there:

* https://hud.pytorch.org/pytorch/pytorch/commit/29c78266c046c7f83e7d84fc764af47e62ae9542 

### Versions

Functorch on Mac

cc @zou3519 @Chillee @samdow @soumith
Repository: PowerToys
Issue: Fancy Zones Defined By Percentage
Labels: Needs-Triage

### Description of the new feature / enhancement

When editing a layout in Fancy Zone provide the ability to define zones by percentage.  This would provide the ability to use the same layout on multiple monitors with different pixel heights and widths.

### Scenario when this would be used?

When editing a layout for multiple monitors.

### Supporting information

_No response_
Repository: material-ui
Issue: [RFC] When to start adopting new CSS features, browser support
Labels: discussion,breaking change,RFC

### What's the problem? 🤔

CSS is one of the core logic that powers Material UI and Joy UI and it is evolving over time. New CSS features, e.g. [flexbox gap](https://caniuse.com/?search=flexbox%20gap), can reduce the complexity of the code and [solve existing issues](https://github.com/mui/material-ui/issues/33754). However, we've never talked about when to start using them.

This RFC aims to create a discussion to bring clarity to the community.


### What are the requirements? ❓

1. The support percentage (Global) from [caniuse](https://caniuse.com).
2. The specific issue that the new feature will solve.
3. A proof of concept

### Proposed solution ⌛️

**Final solution**: TBD

---

I think the adoption can be split into 2 phases (if possible) by using [caniuse](https://caniuse.com/) as an indicator:

1. At `90%`, create an opt-in version (could be a new prop, or a new component):
   - **prop** example, `<Stack useFlexGap>` will switch the implementation from `margin` to `gap` which can be enabled from the theme default props to affect all instances of the `Stack`.
   - **component** example, `<Unstable_CssGrid >` that implements CSS Grid feature as an alternative to the existing `Grid`.
2. At `94%` (~1-2yrs from 90%), make the API stable based on the feature.
   - In the case of the `Stack`, the `gap` can be the default implementation because it covers every use case of the `margin`
   - For components, e.g. `CssGrid`, make it a stable version but remains `Grid` component because they might be used in different scenarios.

### Resources and benchmarks 🔗

_No response_
Repository: deno
Issue: lsp: add benchmarks to detected tests
Labels: feat,lsp

Currently benchmark tests are not detected via the testing API and offered to the client, but could/should be.
Repository: flutter
Issue: [Proposal] Support CameraController with iso, shutter speed control
Labels: c: new feature,p: camera,package,c: proposal,team-ecosystem,P3,triaged-ecosystem

## Proposal
I would like for this plugin to be able to manually control camera's iso, shutter speed. As far as I know, these features can only be control using expose offset, but I would like to control them directly. Any plans to support these features? 


Relevant issue:
https://github.com/flutter/flutter/issues/98313#issue-1133624633
Repository: PowerToys
Issue: New Tool: Mouse control with keyboard shortcuts
Labels: Idea-New PowerToy,Needs-Triage

### Description of the new feature / enhancement

So I found [this tool called warpd ](https://github.com/rvaiya/warpd/)that works on Linux and Mac but not Windows (weirdly enough) and I thought it could make a great PowerTool. 
**It's a program to let you leave your hands on the keyboard at all times and control the mouse with the keyboard.**

The way it works is that a shortcut invokes an overlay that lets you place the cursor in a certain place on your screen very quickly. It has a couple of methods of doing this, and there are details on the linked GitHub but I'll link the example gifs here: 
### Hint Mode:
![Capture2](https://user-images.githubusercontent.com/3929975/192943877-7dcd059c-b5cf-47fb-a1f2-47868be36155.gif)
### Grid Mode:
![Capture](https://user-images.githubusercontent.com/3929975/192943837-82a458fd-fd80-451a-884b-e6ede480e02e.gif)
### Normal Mode:
![Capture3](https://user-images.githubusercontent.com/3929975/192943847-cc2cf238-1ba0-4f46-81c1-90817f93089b.gif)

Normal mode doesn't seem very useful, but the other 2 can be VERY fast and decently precise. I could even see users coming up with designs for other overlays and interaction methods. There could also be quite a few settings you could tweak to make this a PowerTool that works quite well for the user

### Scenario when this would be used?

Anytime you're coding or anytime you're doing something that requires mostly typing but has intermittent use of the mouse required. It would help not to have to switch between the mouse and keyboard all the time.

### Supporting information

Heard about it in this video and which provides (a tiny) bit more context: https://www.youtube.com/shorts/fNcsrTpGh34
Repository: rust
Issue: Missing 'unused assignment' warning with += operator on String
Labels: A-diagnostics,T-compiler

Given the following code ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=543403ea716f65d3de19fe8502014a81)):

```rust
fn main() {
    let mut s = "A".to_string();
    s += "B";
}
```

The current output shows no warnings.

Ideally the output should look like:

```
warning: modified value of `s` is never read
 --> src/main.rs:3:5
  |
3 |     s += "B";
  |     ^
  |
  = note: `#[warn(unused_assignments)]` on by default
```

Switching to `s = s + "B"`, or changing the variable to `u32`, makes the desired warning appear. And indeed there are types for which `+=` might be used for external side effects alone. But `String` does not really "do" anything, so `s` should be considered unused after `s += "B"`.

Perhaps I want something like `#[must_use_self]` on `String::add_assign`: similar to `#[must_use]` except that it applies to `self` after the call, rather than to the method's return value.

Somewhat related to #63054.
Repository: angular
Issue: Add an error message when ngSwitchDefault is surrounded by ngIf 
Labels: area: common,hotlist: error messages,P4

### Which @angular/* package(s) are the source of the bug?

common

### Is this a regression?

No

### Description

In situations where *ngIf is wrapping *ngSwitchCase and *ngSwitchDefault, when *ngIf condition changes *ngSwitchDefault seems to be responding to the change only once, whereas *ngSwitchCase works as expected and is hiding/showing elements any number of times. 

### Please provide a link to a minimal reproduction of the bug

https://stackblitz.com/edit/angular-ivy-gr6cbt?file=src%2Fapp%2Fapp.component.html

### Please provide the exception or error you saw

```true
N/A
```


### Please provide the environment you discovered this bug in (run `ng version`)

```true
Angular CLI: 14.0.7
Node: 14.20.0
Package Manager: npm 6.14.17 
OS: darwin x64

Angular: 14.2.3
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1402.3
@angular-devkit/build-angular   14.2.3
@angular-devkit/core            14.2.3
@angular-devkit/schematics      14.0.7
@angular/cli                    14.0.7
@schematics/angular             14.0.7
rxjs                            7.5.7
typescript                      4.7.4
```


### Anything else?

_No response_
Repository: godot
Issue: Screen freezes on Android when calling AudioEffectSpectrumAnalyzerInstance.get_magnitude_for_frequency_range
Labels: bug,platform:android,needs testing,topic:audio

### Godot version

v3.5.stable.official [991bb6ac7]

### System information

Android 4.4.2, Nvidia TD580D-A1 quad-core Tegra K1 processor, GLES3

### Issue description

The issue is that the screen freezes (no screen updates, input stops working) at seemingly random times when I call AudioEffectSpectrumAnalyzerInstance.get_magnitude_for_frequency_range in the _process function. I've only seen this happen on my only Android device (an old Google Project Tango tablet). The same code works fine on macOS and all of my iOS devices.

I expected the screen to not freeze.

### Steps to reproduce

1. Export an Android APK for the attached sample project.
2. Install the APK on an android device (I've only tested 1 device as I only own 1, but I'll try to test more).
3. Run the game and wait for anywhere from 10 seconds to a couple of minutes and notice the screen freezes while the audio continues to run. If you comment out line 20 in Main.gd (the one calling get_magnitude_for_frequency_range) game will run fine for as long as you let it (I ran it for 15 minutes without crashing).

### Minimal reproduction project

[TestSpectrumAnalyzer.zip](https://github.com/godotengine/godot/files/9671483/TestSpectrumAnalyzer.zip)
Repository: flutter
Issue: TextOverflow.ellipsis is not  in the middle with Chinese text
Labels: c: regression,framework,engine,a: internationalization,a: typography,has reproducible steps,P2,found in release: 3.3,found in release: 3.5,team-engine,triaged-engine

flutter doctor

```
➜  ~ flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.3.3, on macOS 12.6 21G115 darwin-arm, locale zh-Hans-CN)
[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
[✓] Xcode - develop for iOS and macOS (Xcode 14.0.1)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2021.3)
[✓] IntelliJ IDEA Ultimate Edition (version 2022.2)
[✓] VS Code (version 1.71.0)
[✓] Connected device (3 available)
[✓] HTTP Host Availability

• No issues found!
```

use Android Studio

When I use ellipsis, the Chinese dot appears in the middle, and the version 2.5.3 of the flutter is at the bottom

flutter 3

<img width="132" alt="image" src="https://user-images.githubusercontent.com/113668013/192950926-c9be5478-d919-4991-8666-c1b43b21ba6e.png">

flutter 2.5.3

<img width="230" alt="image" src="https://user-images.githubusercontent.com/113668013/192951738-6130c025-a393-4f2f-8536-5f3241d9554e.png">


I found that English was normal, but there was a problem with Chinese

I hope it's all at the bottom
Repository: angular
Issue: NgModel fails to register to NgForm when in a child component
Labels: area: forms,P3

### Which @angular/* package(s) are the source of the bug?

forms

### Is this a regression?

No

### Description

When you use ngModel in a child component, it fails to register itself to a NgForm that is held by a parent component.

This causes validation fail or success in the NgModel to bubble up to the NGForm, leaving the NgForm in a different state as the contents inside of it.

### Please provide a link to a minimal reproduction of the bug

[StackBlitz](https://stackblitz.com/edit/ngformregistrationissue?file=src%2Fapp%2Fapp.component.ts,src%2Fapp%2Fapp.component.html,src%2Fstyles.css,src%2Fapp%2Fchild2%2Fchild2.component.ts,src%2Fapp%2Fchild1%2Fchild1.component.html,src%2Fapp%2Fchild2%2Fchild2.component.html,src%2Findex.html)

### Anything else?

The problem seems to come from using `@Host` when injecting `ControlContainer` into ngModel.
You can see it in [this line](https://github.com/angular/angular/blob/14.2.4/packages/forms/src/directives/ng_model.ts#L208). The `@Host` will limit it to the component it is in, instead of "bubbling up" to where the form is.

Also `[ngModelGroup]` seems to have the same issue. At least it is using `@Host()` in similar way [code line](https://github.com/angular/angular/blob/14.2.4/packages/forms/src/directives/ng_model_group.ts#L61)
Repository: vscode
Issue: Don't use actions-anti-pattern for filter box rendering
Labels: debt,workbench-views

continues https://github.com/microsoft/vscode/issues/162004#issuecomment-1261139593

There seems to be a anti-pattern that noop actions are registered to views for the sole reason of rendering a custom UI for a single place. This is bad because

* actions are global and discoverable, e.g users can register keybinding to them or extensions can invoke them
* action have certain semantics and new features, like hiding, don't make sense
* this seems like a lot of complexity and overhead to just render something into the panel title


As tactical fix for #162004 I have marked some actions as fake action. This is debt and needs to be replaced with a proper solution. I suggest to either

* fix the actions to do something, e.g make them work independent of the one special rendering
* don't use an action but let your view override [renderHeader](https://github.com/microsoft/vscode/blob/2c801254ebf547baaee771b99aa76d202f999622/src/vs/workbench/browser/parts/views/viewPane.ts#L287) and add custome UI, e.g a filter box


---

- [ ] src/vs/workbench/contrib/debug/browser/repl.ts @roblourens @connor4312 
- [x] src/vs/workbench/contrib/testing/browser/testingExplorerFilter.ts @connor4312 
- [x] src/vs/workbench/contrib/terminal/browser/terminalView.ts @Tyriar 
- [x] src/vs/workbench/contrib/comments/browser/commentsViewActions.ts @alexr00 
- [x] src/vs/workbench/contrib/markers/browser/markers.contribution.ts @sandy081 
- [x] src/vs/workbench/contrib/output/browser/output.contribution.ts @sandy081
Repository: godot
Issue: PopupMenu generated by OptionButton is not inheriting parent's material when use_parent_material is true
Labels: bug,topic:gui

### Godot version

v3.5.1.stable.official [6fed1ffa3]

### System information

Windows 10

### Issue description

When using an OptionButton node, the internal PopupMenu node generated at runtime does not inherit the material from its parent when the popup's `use_parent_material` value is set to true.
As far as I can tell, this is not intended behaviour, as the generated PopupMenu is a direct child node of the OptionButton, and this does not occur with manually created PopupMenu nodes.

### Steps to reproduce

1. Create an OptionButton node.
2. Add a CanvasMaterial to the OptionButton.
3. Add a script to the OptionButton with the following line in the _ready() function:
`get_popup().use_parent_material = true`
4. Run the scene. The materials on the OptionButton and PopupMenu do not match, despite the value being set, as seen in the Remote scene tree.
![image](https://user-images.githubusercontent.com/114646913/192966772-6488c93a-4164-4ed4-bf5c-441856025bd3.png)
![image](https://user-images.githubusercontent.com/114646913/192967002-2300cf95-f213-4b96-9c40-732a6450bd17.png)


### Minimal reproduction project

[OptionButton Material Bug.zip](https://github.com/godotengine/godot/files/9672203/OptionButton.Material.Bug.zip)
Repository: rust
Issue: rustdoc: Named constants in array sizes shouldn't be evaluated
Labels: T-rustdoc,C-bug

## Current rustdoc behavior

Given the following code:

```rust
pub struct SomeStruct { _p: () }

#[cfg(target_os = "linux")]
const TARGET_STORAGE_SIZE: usize = 128;
#[cfg(not(target_os = "linux"))]
const TARGET_STORAGE_SIZE: usize = 256;

impl SomeStruct {
    /// How much storage to allocate for a call to
    /// [`some_method`](Self::some_method).
    pub const STORAGE_SIZE: usize = TARGET_STORAGE_SIZE;

    /// The user is expected to call this with an array of size
    /// `SomeStruct::STORAGE_SIZE`, whatever that happens to be.
    pub fn some_method(
        &self,
        storage: &mut [u8; SomeStruct::STORAGE_SIZE],
    ) {}
}
```

The user would be expected to call it like this:

```rust
let mut storage = [0u8; SomeStruct::STORAGE_SIZE];
some_struct.some_method(&mut storage);
```

Unfortunately, the rustdoc output is confusing because it evaluates the constant when formatting the function signature:

![rustdoc-1](https://user-images.githubusercontent.com/646128/192970362-c2096f54-0ccb-46e8-931f-5d654d880a29.png)

If a user were to copy-paste from the rustdoc'd function signature when writing the call site, they would write code like this, which would fail to compile on some platforms:

```rust
let mut storage = [0u8; 128];
some_struct.some_method(&mut storage);
```

## Proposed new behavior

A better way to format this function signature would be to use the constant's name, if the constant is public:

![rustdoc-2](https://user-images.githubusercontent.com/646128/192972310-a83ed291-12de-4d95-b443-e008103b3fcd.png)

An even niftier formatting would let the constant become a link:

![rustdoc-3](https://user-images.githubusercontent.com/646128/192973296-11afd973-dd5b-4e38-9e43-99ef69c7aecf.png)

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"fmease"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->