sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: terminal
Issue: [Settings> Add new profile]: Confirmation message is not announced by Screen Reader when user create a new profile and duplicate the profile.
Labels: Issue-Bug,Area-Accessibility,Product-Terminal,In-PR,Priority-3,HCL-E+D,A11yWCAG,HCL-WindowsTerminal,A11yCO,A11ySev3

### Windows Terminal version

1.12.3472.0

### Windows build number

10.0.22504.1010

### Other Software

Test Environment:
OS: Windows 11 Version Dev (OS Build 22504.1010)
App: Windows Terminal Preview
Screen Reader: Narrator

### Steps to reproduce

**Repro Steps:**
1. Open Windows Terminal.
2. Open Settings page using 'Ctr+,'.
3. Open Narrator using 'Win + Ctrl + Enter' keys.
4. Activate 'Add a new profile' tab, then activate 'New Empty profile' and 'Duplicate' button.
5. Observe the issue.

**User Experience:**
Screen Reader users UX will not be good if there will not be able to know whether the action is performed successfully or not.

**Guideline Reference:**
EN 301 549 V3.2.1: 11.5.2.15 Change notification

**Attachments:**
[Confirmation message is not announced by Screen Reader when user create a new profile and Duplicate the profile..zip](https://github.com/microsoft/terminal/files/7778772/Confirmation.message.is.not.announced.by.Screen.Reader.when.user.create.a.new.profile.and.Duplicate.the.profile.zip)

### Expected Behavior

Confirmation message should be announced by Screen Reader when user create a new profile and duplicate the profile.
i.e. When New profile created successfully, Screen Reader should 'profile name created successfully' and When user duplicated a profile Screen Reader should announce 'profile name created successfully'.


### Actual Behavior

Confirmation message is not announced by Screen Reader when user create a new profile and duplicate the profile.

**Observation:** Issue repro with NVDA and JAWS Screen Reader.
Repository: terminal
Issue: [Settings> Add New Profile]: 'Discard changes' control performing 'Delete profile' functionality inside newly created profile.
Labels: Issue-Bug,Area-Accessibility,Product-Terminal,HCL-E+D,A11yUsable,HCL-WindowsTerminal,A11yCO

### Windows Terminal version

1.12.3472.0

### Windows build number

10.0.22504.1010

### Other Software

**Test Environment:**
OS: Windows 11 Version Dev (OS Build 22504.1010)
App: Windows Terminal Preview
Screen Reader: Narrator

### Steps to reproduce

**Repro Steps:**
Open Windows Terminal.
Open Settings page using 'Ctr+,'.
Activate 'Add a new profile' tab, then activate 'New Empty profile' or 'Duplicate' button.
Then activate 'Discard Changes' button inside newly created profile.
Observe the issue.

**User Experience:**
All users UX will not be good if inappropriate functionality is performed on activating a control.

**Attachments:**
[Profile get deleted When user activate 'Discard changes' control in newly created profile and Keyboard focus jumps to 'Discard Changes' inside Startup page..zip](https://github.com/microsoft/terminal/files/7778817/Profile.get.deleted.When.user.activate.Discard.changes.control.in.newly.created.profile.and.Keyboard.focus.jumps.to.Discard.Changes.inside.Startup.page.zip)


### Expected Behavior

 'Discard changes' control should not perform 'Delete profile' functionality inside newly created profile.

### Actual Behavior

 'Discard changes' control performing 'Delete profile' functionality inside newly created profile. Profile get deleted When user activate 'Discard changes' control in newly created profile and Keyboard focus jumps to 'Discard Changes' inside Startup page..
Repository: rust
Issue: Swapping operations are insufficiently deduplicated
Labels: A-LLVM,T-compiler,C-bug,I-heavy

I put this code in Godbolt.
```rust
pub fn swap1(x: &mut u32, y: &mut u32) {
    *y ^= *x;
    *x ^= *y;
    *y ^= *x;
}

pub fn swap2(x: &mut u32, y: &mut u32) {
    core::mem::swap(x, y)
}

pub fn swap3(x: &mut u32, y: &mut u32) {
    (*x, *y) = (*y, *x);
}

pub fn swap4(x: &mut u32, y: &mut u32) {
    *x ^= *y;
    *y ^= *x;
    *x ^= *y;
}

pub fn swap5(x: &mut u32, y: &mut u32) {
    core::mem::swap(y, x)
}

pub fn swap6(x: &mut u32, y: &mut u32) {
    (*y, *x) = (*x, *y);
}
```
I was surprised to find that every one of these functions is represented individually in the output, even with `-C opt-level=s`. This is most egregious with `swap1`/`swap2`/`swap3` and `swap4`/`swap5`/`swap6` where the exact same instructions are output, but those in turn differ only trivially and could possibly be unified as well.
Repository: terminal
Issue: [Terminal> Status]: In Scan mode, Screen Reader focus is going on whole information dialog and announcing, 'No next text' or 'No previous text'.
Labels: Issue-Bug,Area-Accessibility,Product-Terminal,Priority-3,HCL-E+D,A11yWCAG,HCL-WindowsTerminal,A11yCO,A11ySev3

### Windows Terminal version

1.12.3472.0

### Windows build number

10.0.22504.1010

### Other Software

**Test Environment:**
OS: Windows 11 Version Dev (OS Build 22504.1010)
App: Windows Terminal Preview
Screen Reader: Narrator

### Steps to reproduce

**Repro Steps:**
1. Open Windows Terminal.
2. Open Command Palette using 'Ctrl + Shift + p'.
3. Press 'Backspace' key and then type 'dir' and hit Enter.
4. Open Narrator using 'Win + Ctrl + Enter' keys. Turn on Scan on mode using 'Caps lock + Space' keys.
5. Navigate to 'Don't Show again' dialog using 'up/down' arrow keys and observe the issue.

**User Experience:**
Screen Reader users UX will not be good if Screen Reader announce incorrect info while navigating in scan mode.

**Guideline Reference:**
https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships

**Attachments:**
[In Scan mode, Screen Reader focus is going on whole information dialog and announcing 'No next text' or 'No previous text'..zip](https://github.com/microsoft/terminal/files/7778957/In.Scan.mode.Screen.Reader.focus.is.going.on.whole.information.dialog.and.announcing.No.next.text.or.No.previous.text.zip)


### Expected Behavior

In Scan mode, Screen Reader focus should not go on whole information dialog.

### Actual Behavior

In Scan mode, Screen Reader focus is going on whole information dialog and announcing, 'No next text' or 'No previous text'.

Observation: Not able to verify NVDA and JAWS Screen Reader behavior as there Browse or Curosr mode doesn wotk inside app.
Repository: pytorch
Issue: LazyModules `cls_to_become` field exposes implementation detail
Labels: module: docs,module: nn,triaged,Stale

### 📚 The doc issue

https://pytorch.org/docs/stable/generated/torch.nn.LazyConv1d.html#torch.nn.LazyConv1d
![image](https://user-images.githubusercontent.com/19503980/147448687-0bd47661-eb09-469a-9914-603b762a7350.png)

https://pytorch.org/docs/stable/generated/torch.nn.LazyConv2d.html#torch.nn.LazyConv2d
![image](https://user-images.githubusercontent.com/19503980/147448712-04522f68-5d2c-4f29-9830-f6cb028cbaa8.png)

https://pytorch.org/docs/stable/generated/torch.nn.LazyInstanceNorm1d.html#torch.nn.LazyInstanceNorm1d
![image](https://user-images.githubusercontent.com/19503980/147448791-f500bbc8-9f20-49ba-97b8-e0fa4197442f.png)


### Suggest a potential alternative/fix

_No response_

cc @brianjo @mruberry @albanD @jbschlosser @walterddr @kshitij12345
Repository: terminal
Issue: [Terminal> Command Palette]: Screen Reader is not announcing any info about '>'(more options) for 'New Tab' list item.
Labels: Issue-Docs,Area-Accessibility,Product-Terminal,Priority-3,HCL-E+D,A11yWCAG,HCL-WindowsTerminal,A11yCO,A11ySev3

### Windows Terminal version

1.12.3472.0

### Windows build number

10.0.22504.1010

### Other Software

**Test Environment:**
OS: Windows 11 Version Dev (OS Build 22504.1010)
App: Windows Terminal Preview
Screen Reader: Narrator
Tool: Accessibility Insights for Windows Version 1.1.1741.1

### Steps to reproduce

**Repro Steps:**
1. Open Windows Terminal.
2. Open Command Palette using 'Ctrl + Shift + p'.
3. Open Narrator using 'Win + Ctrl + Enter' keys.
4. Navigate to 'New tab...' suggestion using down arrow keys and observe the issue. 

**User Experience:**
Screen Reader users UX will not be good if Screen Reader doesn't know the full control properties.

**Guideline Reference:**
https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships

**Attachments:**
[Screen Reader is not annoucing any info about ExpandCollapsed control for 'New Tab' list item..zip](https://github.com/microsoft/terminal/files/7779140/Screen.Reader.is.not.annoucing.any.info.about.ExpandCollapsed.control.for.New.Tab.list.item.zip)


### Expected Behavior

Screen Reader should announce 'New Tab 48 of 107 Selected Activate for more options' for 'New Tab' list item.

### Actual Behavior

Screen Reader is not announcing any info about '>'(more options) for 'New Tab' list item. Issue repro with all list item control where '>' (more options) control is present. 
i.e. For 'New tab..  >' Screen reader is only announcing 'New Tab 48 of 107 Selected'

**Observation:** Issue repro with NVDA and JAWS Screen Reader.
Repository: terminal
Issue: [Terminal > Command Palette]: No hint is given to visual/non-visual users about how they can jump between command line mode or Actions Search mode inside Command Palette Window.
Labels: Issue-Bug,Area-Accessibility,Product-Terminal,HCL-E+D,A11yUsable,HCL-WindowsTerminal,A11yCO

### Windows Terminal version

1.12.3472.0

### Windows build number

10.0.22504.1010

### Other Software

**Test Environment:**
OS: Windows 11 Version Dev (OS Build 22504.1010)
App: Windows Terminal Preview
Screen Reader: Narrator


### Steps to reproduce

**Repro Steps:**
1. Open Windows Terminal.
2. Open Command Palette using 'Ctrl + Shift + p'.
3. Press 'Backspace' key.
4. Verify that hint is given to visual/non-visual user about the jumping between command line mode or Actions Search mode or not.

**User Experience:**
Users UX will not be good if user will not know how use certain functionality.

**Attachments:**
[No hint is given to visualnon-visual user about the jumping between command line mode or Actions Search mode..zip](https://github.com/microsoft/terminal/files/7779299/No.hint.is.given.to.visualnon-visual.user.about.the.jumping.between.command.line.mode.or.Actions.Search.mode.zip)

### Expected Behavior

Hint should be given to visual/non-visual user about how they can jump between command line mode or Actions Search mode inside Command Palette Window.

### Actual Behavior

No hint is given to visual/non-visual users about how they can jump between command line mode or Actions Search mode inside Command Palette Window. 
Visual Placeholder Lable is given as 'Type a command name' and 'Enter a wt command line to run'.
Screen Reader announce, 'Command line mode' and 'Actions Search mode' when we jump between two modes but no hint about how they can jump between these two modes. Also Screen Reader remains silent when focus goes on '>' icon.

Observation: Same issue repro with NVDA and JAWS Screen Reader.
Repository: rust
Issue: Derives on deprecated enum variants generate deprecation warnings
Labels: A-lints,A-macros,T-compiler,C-bug,L-deprecated

<!--
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.
-->

I tried this code:

```rust
use serde::{Deserialize, Serialize};

#[derive(Deserialize, Serialize)]
enum Point {
    #[deprecated]
    TwoD(i32, i32),
    ThreeD(i32, i32, i32),
}

fn main() {
    println!("Hello, world!");
}
```

I expected to see this happen: *explanation*

No deprecated warnings generated.

Instead, this happened: *explanation*

use of deprecated tuple variant `Point::TwoD`
`#[warn(deprecated)]` on by default

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.57.0 (f1edd0429 2021-11-29)
binary: rustc
commit-hash: f1edd0429582dd29cccacaf50fd134b05593bd9c
commit-date: 2021-11-29
host: x86_64-unknown-linux-gnu
release: 1.57.0
LLVM version: 13.0.0
```
Repository: terminal
Issue: [Terminal> Set tab color]: 'Custom' control name is not descriptive, and role defined is incorrect.
Labels: Issue-Bug,Area-Accessibility,Product-Terminal,Priority-3,HCL-E+D,A11yWCAG,HCL-WindowsTerminal,A11yCO,A11ySev3

### Windows Terminal version

1.12.3472.0

### Windows build number

10.0.22504.1010

### Other Software

**Test Environment:**
OS: Windows 11 Version Dev (OS Build 22504.1010)
App: Windows Terminal Preview
Screen Reader: Narrator
Tool: Accessibility Insights for Windows Version 1.1.1741.1

### Steps to reproduce

**Repro Steps:**
1. Open Windows Terminal.
2. Open Settings page using 'Ctr+,'.
3. Activate 'Actions' tab and then Add a new actions 'Set tab color' with shortcut key 'Ctrl + Shift + c'.
4. Open Narrator using 'Win + Ctrl + Enter' keys.
5. navigate inside Terminal window.
6. Press 'Ctrl + Shift + c' keys, then navigate to 'Custom' control inside Set tab color pop-up using tab key.
7. Observe the issues.

**User Experience:**
Screen Reader users UX will not be good as control name is not descriptive so they will not be able to know the purpose of controls also role properties does not match visual structure. 

**Guideline Reference:**
https://www.w3.org/WAI/WCAG21/Understanding/name-role-value

**Attachments:**
['Custom' control name is not descriptive, and role defined is incorrect. (2).zip](https://github.com/microsoft/terminal/files/7779775/Custom.control.name.is.not.descriptive.and.role.defined.is.incorrect.2.zip)


### Expected Behavior

'Custom' ontrol name should be more descriptive, and correct role should be defined.
.i.e. For Collapsed 'Custom'  control Screen Reader should announce 'Custom Tab Colors button Collapsed' and For Expanded 'Custom' control Screen Reader should announce 'Custom Tab Colors button Expanded'


### Actual Behavior

'Custom' control name is not descriptive, and role defined is incorrect.
i.e. For Collapsed 'Custom' control Screen Reader should announce 'Custom Button off' and For Expanded 'Custom' control Screen Reader should announce 'Custom Button On'

**Observation:** Issue repro with NVDA and JAWS Screen Reader.
Repository: go
Issue: cmd/compile: some subsequent bounds checks are not eliminated
Labels: Performance,NeedsInvestigation,compiler/runtime

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version devel go1.18-088bb4b Tue Nov 2 06:25:39 2021 +0000 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

</pre></details>

### What did you do?

https://go.dev/play/p/eyem-XNTdye
https://go.godbolt.org/z/bMTGW9E7W

### What did you expect to see?
Since `i` and `size` are always positive numbers,

`i*size+1` is not equal to zero and will be always greater than `i*size`, so

```go
data[i*size]
```
check can be eliminated.

If `i*size+1` overflows or `i*size+1 >= len(data)`, `data[i*size+1]` will panic before accessing `data[i*size]`.

### What did you see instead?

Compiler emits two checks.
Repository: vscode
Issue: Single-char-prefix snippet suggestion is not case sensitive
Labels: suggest,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

<!-- 🪓 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.63.2
- OS Version:Windows 10

Almost same as [issue 8070](https://github.com/microsoft/vscode/issues/8070), in which the reported bug has been fixed. However, if the snippet prefix is a single char, suggestion remains case insensitive.

For example, if I define a `Result` snippet with prefix `Re` and `return` snippet with prefix `re`, while typing `re`, `return` will be the first suggestion. But if the prefix is `R` and `r` respectively, `Result` will be on top while typing `r`.
Repository: flutter
Issue: TextStyle property `height: 0` shows different behavior on web than on mobile
Labels: engine,a: typography,platform-web,has reproducible steps,P2,found in release: 2.8,found in release: 2.9,team-web,triaged-web


## Steps to Reproduce

1. Use Text('Test', style: TextStyle(height: 0))
2. Run on web or mobile platform

**Expected results:** 
Should behave the same on each platform

**Actual results:** 
On the web setting the value of 0 has no impact at all.

Mobile: 
![image](https://user-images.githubusercontent.com/42775578/147475337-b1b8cd1b-9de9-4445-ad98-0c12cef10f6c.png)

Web: 
![image](https://user-images.githubusercontent.com/42775578/147475353-2ca192de-c13e-4e64-9da1-4e259ef609a8.png)

Changing the value to 0.001 shows the same behavior on both platforms.

<details>
<summary>Code sample</summary>

```dart
Text('Test', style: TextStyle(height: 0))
```

</details>

<details>
  <summary>Logs</summary>

```
$ flutter analyze
Analyzing flutterapp...
No issues found! (ran in 2.5s)
```

```
$ flutter doctor -v
[√] Flutter (Channel stable, 2.5.3, on Microsoft Windows [Version 10.0.19043.1348], locale de-CH)
    • Flutter version 2.5.3 at C:\src\flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 18116933e7 (2 months ago), 2021-10-15 10:46:35 -0700
    • Engine revision d3ea636dc5
    • Dart version 2.14.4
    • Pub download mirror https://pub.dev

[√] Android toolchain - develop for Android devices (Android SDK version 30.0.2)
    • Android SDK at C:\Users\SebastianBuechler\AppData\Local\Android\sdk
    • Platform android-31, build-tools 30.0.2
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

[√] Android Studio (version 2020.3)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin can be installed from:
       https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
       https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)

[√] VS Code (version 1.63.2)
    • VS Code at C:\Users\SebastianBuechler\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension version 3.29.0

[√] Connected device (2 available)
    • Android SDK built for x86 (mobile) • emulator-5554 • android-x86    • Android 10 (API 29) (emulator)
    • Chrome (web)                       • chrome        • web-javascript • Google Chrome 96.0.4664.110

• No issues found!
```

</details>
Repository: neovim
Issue: LSP: send language server stderr to a file
Labels: enhancement,lsp

### Feature already in Vim?

(No, this relates to the LSP client).

### Feature description

TL;DR: as a language server maintainer, it would be useful if the language server stderr stream was written to a temporary file. It's okay if this is optional.

Without this:
 - nvim users can't usefully report bugs against our server
 - it's painful to understand/debug server interactions with nvim

---

Background: clangd and many other language servers produce detailed logs on stderr by default.
These logs have all critical information for investigating server behavior, e.g. protocol messages interleaved with internal state, crash dumps etc.

We require logs with bug reports, and provide [per-editor instructions](https://clangd.llvm.org/installation.html) for how to obtain them.
Here's [an example bug](https://github.com/clangd/clangd/issues/859) investigated with the help of logs. 
Viewing logs is also a critical part of development, long live printf debugging!

---

Today nvim sends the error stream to the lsp.log file in the following format:

```
[ERROR][2021-12-25 23:48:54] .../vim/lsp/rpc.lua:417	"rpc"	"clangd"	"stderr"	"I[23:48:54.673] clangd version 14.0.0 (48d868493fa74025e7768afacdbbbd3ea9c82468)\nI[23:48:54.673] Features: linux+grpc\nI[23:48:54.673] PID: 27944\nI[23:48:54.673] Working directory: /home/sammccall\nI[23:48:54.673] argv[0]: clangd\nI[23:48:54.673] argv[1]: --background-index\n"
```

This isn't useful because:
 - it's hard to read due to the long prefixes and escaping
 - structure isn't visible because line boundaries aren't respected (lines are both combined and split)
 - it combines logs from several instances of the server, so:
   - it's too hard to trace state if the instances are concurrent
   - users don't know where to cut logs (it's *so* hard to get them to provide full logs aready)
   - it's easy for users to leak details of private code into a bug report for an isolated example

---

What I'd like is for the stderr stream to be sent to a path created by tempname(), and for this path to be logged to lsp.log and/or available programmatically.

This means the file would be scoped to the lifetime of the editor - it would remain if clangd exits/crashes but be removed once the editor is closed.

I've implemented this solution in my own vim LS-client from years ago and it works really well.

(Passing a --log-file flag to the server isn't a great solution: between ensuring unique file paths, discoverability of the file paths, and giving the files the right lifetime, it's hard to get this right without editor cooperation)
Repository: deno
Issue: Code coverage is not collected from `Worker` context(s)
Labels: bug,testing

```
$ deno --version
deno 1.17.0 (release, x86_64-unknown-linux-gnu)
v8 9.7.106.15
typescript 4.5.2
```

It seems code coverage is not collected for scripts from the worker contexts (neither from the worker script itself, nor from the imported scripts).

Steps to reproduce:
1) Clone the `git@github.com:canonic-epicure/deno-reproduce.git`
2) Inside the repo folder, run `DENO_UNSTABLE_COVERAGE_DIR=cov deno run -A --unstable reproduce.js`
3) Search inside the `cov` folder, it contains a single file for every file, for which coverage information was collected.
There should be a file containing the text: `lib.js` and `worker.js`, but there's none. The file for `reproduce.js` presents as expected.