sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: QuickPick API: When input value changes, first item becomes active item
Labels: bug,quick-pick

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->
<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: https://code.visualstudio.com/insiders/ -->

<!-- Use Help > Report Issue to prefill these. -->
Version: 1.52.1 (system setup)
OS: Windows_NT x64 10.0.20231

Steps to Reproduce:

Hi, I'm working on https://github.com/bodil/vscode-file-browser/ fork on my local.

I have something like that.
```ts
picker = vscode.window.createQuickPick();
picker.sortByLabel = false
```
I disabled sorting and manually focusing elements by input value. My problem is, when everytime `onDidChangeValue` event fires, active item is resets to first item. I'm setting active item in listener of this event, but it flashes on first item.

_(the file icons on video comes from custom script which is injected to workbench.html, i didnt modify core files)_

https://user-images.githubusercontent.com/19991745/103301702-f9751a00-4a12-11eb-81af-a6e35a0091bf.mp4
Repository: rust
Issue: Use sort_unstable to sort primitive types
Labels: I-slow,T-libs,A-slice

When sorting primitive types, without a  sort_by function, sort and sort_unstable produce the same output (because the "identical elements" are themselves indistinguishable).

This change was done by hand ( https://github.com/rust-lang/rust/pull/76541 ), and clippy will recommend changing sort to sort_unstable on primitive types.

However, if it is so useful it feels like it should be easy to do within the standard library itself, if there is a trait (or a trait was added) for primitive types.

This feel preferably to the current situation, where clippy tells users to change it, as then (see #76541 for example ), users have to keep adding comments to remind themselves that the sort_unstable is actually stable in this case.
Repository: pytorch
Issue: [FX] intermediate types of empty lists/dicts not preserved during torch.fx tracing
Labels: oncall: jit,TSRootCause:DefaultTypes,TSUsability

## 🐛 Bug

On occasions we may want to pass, for example, an empty list to a leaf function. In TorchScript, these empty lists are assumed to have type `List[torch.Tensor]`, as most types in TorchScript (Tensor type defaulting behavior). In order to get around this defaulting behavior, we can either:
1. Annotate the type of the variable: `var1: List[str] = []`
2. Use `torch.jit.annotate` to notify the TorchScript compiler: `var1 = torch.jit.annotate(List[str], [])`

However, during torch.fx, neither of these methods will annotate the variables in the resulting `GraphModule`. Thus, TorchScript will always assume that these are `List[Tensor]` and may fail to compile the resulting module.

## To Reproduce

Suppose that `my_identity` is a custom op with the following signature:

```
c10::List<std::string> identity(c10::List<std::string> x, at::Tensor& t) {
  return x;
}

TORCH_LIBRARY(my_ops, m) {
  m.def("identity", &identity);
}
```
Then use this in a module and trace it:
```
import torch
from typing import List
from torch.fx import symbolic_trace

class TestModule(torch.nn.Module):
    def forward(self, x: torch.Tensor) -> torch.Tensor:
        out = torch.ops.my_ops.identity(
            torch.jit.annotate(List[str], []),
            x
        )
        return out

graph_module = symbolic_trace(TestModule())
print(graph_module)
```
yielding:
```
import torch
def forward(self, x : torch.Tensor):
    identity = torch.ops.my_ops.identity([], position)
    return identity
```
Finally, run the graph module through TorchScript via `torch.jit.script(graph_module)`.

## Expected behavior

TorchScript should ideally compile fine.

## Actual behavior

The TorchScript compiler complains about the empty list:
```
my_ops::identity(str[] x, Tensor t) -> str[]:
Expected a value of type 'List[str]' for argument 'x' but instead found type 'List[Tensor]'.
Empty lists default to List[Tensor]. Add a variable annotation to the assignment to create an empty list of another type (torch.jit.annotate(List[T, []]) where T is the type of elements in the list for Python 2)
:
import torch
def forward(self, x : torch.Tensor):
    identity = torch.ops.my_ops.identity([], position)
               ~~~~~~~~~~~~~~~~~~~~~~~~~ <--- HERE
    return identity


cc @gmagogsfm
Repository: rust
Issue: compare_and_swap "migration" documentation should explain how to get return value
Labels: C-enhancement,T-libs-api,A-docs

The `compare_and_swap` docs explain how to switch the `order` to `compare_exchange`, but that is not the only difference: the return type also changed. The docs don't say anything about how to best get the old behavior back with the new method. Many concurrent algorithms are written based on getting the old value back, so there should be a convenient way to get that behavior.

Cc @faern
Repository: pytorch
Issue: RFC: Add a "see also" section to operators' documentation
Labels: module: docs,triaged

Some operators such as `torch.flatten` have operators that have similar behavior e.g. `torch.ravel` and `torch.reshape`. As to improve operator discoverability, it could be useful to capture these relationships systematically in the documentation.

In this RFC we propose adding an optional "see also" section in the operator documentation where we link operators that might also be interesting to the reader. See https://numpy.org/doc/stable/reference/generated/numpy.ndarray.flatten.html for how NumPy does this.

Having a unified way of doing this prevents inefficiencies when people try to do it in an ad hoc way, e.g. through notes.  An example is `torch.msort` and `torch.sort` where `torch.msort` can be expressed in terms of `torch.sort`. Currently this is documented in a note, where its displayed very prominently. The issue with this is that its not immediately known by virtue of it being a note what the content could be. So the diligent reader will always be forced to read it, even though it may not povide too much value. Having a more varied visual language, i.e., differently themed note specifically for displaying similar operators would reduce this type of confusion and improve clarity.




cc @jlin27 @mruberry
Repository: PowerToys
Issue: [KBM] Exclude app list
Labels: Idea-Enhancement,Help Wanted,Product-Keyboard Shortcut Manager

<!--
**Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**.
Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue.
-->

## ℹ Computer information

- PowerToys version: 0.27.1
- PowerToy Utility:Keyboard Manager
- Running PowerToys as Admin: Yes
- Windows build number: [run "winver"] 20H2 19042.685

## 📝 Provide detailed reproduction steps (if any)

I am using a Logitech MX Master 3, using the latest Logitech Options but it seems there are some conflicts

1. install both PowerToys and Logitech Options
2. In PowerToys, swap windows key with ctrl
3. In Logitech Options, set "Zoom in/out" for Thumb wheel scroll, set "Gesture button" for the bottom button (the one under the thumb)

### ✔️ Expected result

everything still works

### ❌ Actual result

the zoom in/out doesn't work anymore using the thumb wheel scroll

## 📷 Screenshots
![Snipaste_2020-12-29_17-21-36](https://user-images.githubusercontent.com/17813900/103317812-587a6500-49fa-11eb-8436-7b6d4776d93b.png)


_Are there any useful screenshots? WinKey+Shift+S and then just paste them directly into the form_
Repository: go
Issue: cmd/compile: better optimization/inlining for sort.Search
Labels: Performance,NeedsFix,FeatureRequest,compiler/runtime

### What version of Go are you using (`go version`)?

<pre>
$ go version
go 1.15.6
</pre>

### Does this issue reproduce with the latest release?

go 1.15.6

### 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?

When I use a helper func `SearchLineInfos()` and `SearchFiles` similar as `searchInts()`, I test those func benchmark

benchmark result:

```
name               old time/op  new time/op  delta
SearchLineInfos-8  20.7ns ±19%   6.0ns ± 2%  -70.98%  (p=0.000 n=10+10)
SearchFiles-8      9.48ns ±19%  3.22ns ± 1%  -66.05%  (p=0.000 n=10+8)
```

CL: https://go-review.googlesource.com/c/go/+/279447

### What did you expect to see?

In `position.go`, we impl helper func for sort.Search.

### What did you see instead?

```
if i := sort.Search(len(f.lines), func(i int) bool { return f.lines[i] > offset }) - 1; i>= 0 {
	line, column = i+1, offset-f.lines[i]+1
}

...
```

Remove `func searchInts(a []int, x int) int`

cc @mdempsky
Repository: vscode
Issue: A place to chat/discuss about VS Code.
Labels: question-discussion

I can't seem to find one.

Maybe it would be worth opening up the Discussions tab here on GitHub?
Repository: vscode
Issue: Keep specific extension enabled while running Extension Bisect
Labels: feature-request,bisect-ext

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

I'm having issues with the [vim](https://marketplace.visualstudio.com/items?itemName=vscodevim.vim) extension where it completely hangs in certain cases. The vim extension is fine when it is the only extension running. The bisect feature isn't helpful here because it will have me go through steps where the vim extension isn't even enabled. I think it would be useful to be able to tell bisect that vim should remain enabled the whole time. FWIW, bisect wasn't able to find an issue - I got the "maybe the issuse is in code" error.
Repository: TypeScript
Issue: Boolean literal should be LiteralExpression
Labels: Bug,API

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

Sorry, In my memory there's a duplicate issue about the same problem but I can't find it out.

### 🔎 Search Terms
API, Boolean, Literal
<!--
  What search terms did you use when trying to find an existing bug report?
  List them here so people in the future can find this one more easily.
-->

### 🕗 Version & Regression Information

<!-- When did you start seeing this bug occur?

"Bugs" that have existed in TS for a long time are very likely to be FAQs; refer to
  https://github.com/Microsoft/TypeScript/wiki/FAQ#common-bugs-that-arent-bugs

If possible, please try testing the nightly version of TS to see if it's already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly

Note: The TypeScript Playground can be used to try older verions of TypeScript.

Please keep and fill in the line that best applies:
-->
- I was unable to test this on prior versions because It's API

### ⏯ Playground Link

None
### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
    export interface TrueLiteral extends PrimaryExpression {
        readonly kind: SyntaxKind.TrueKeyword;
    }

    export interface FalseLiteral extends PrimaryExpression {
        readonly kind: SyntaxKind.FalseKeyword;
    }
```

### 🙁 Actual behavior
`isLiteralExpression(trueLiteral) === false`
<!-- What happened, and why it was wrong -->

### 🙂 Expected behavior
`isLiteralExpression(trueLiteral) === true`
<!-- What you expected to happen instead, and why -->
Repository: node
Issue: The store when using enterWith/exitWith in asyncLocalStorage is not "stacked"
Labels: async_hooks

* **Version**: 15.5.0
* **Platform**: MacOS
* **Subsystem**: async_hooks

### What steps will reproduce the bug?

I expected the following program to work:

```js
import {AsyncLocalStorage} from 'async_hooks'
import assert from 'assert'

const asyncLocalStorage = new AsyncLocalStorage()

// This section works nicely: the store is "stacked"
asyncLocalStorage.run({depth: 1}, () => {
  assert.deepStrictEqual(asyncLocalStorage.getStore(), {depth: 1})

  asyncLocalStorage.run({depth: 2}, () => {
    assert.deepStrictEqual(asyncLocalStorage.getStore(), {depth: 2})
  })

  assert.deepStrictEqual(asyncLocalStorage.getStore(), {depth: 1})
})

// This section how when using enterWith/exit the store is not stacked
asyncLocalStorage.enterWith({depth: 1})
assert.deepStrictEqual(asyncLocalStorage.getStore(), {depth: 1})

asyncLocalStorage.enterWith({depth: 2})
assert.deepStrictEqual(asyncLocalStorage.getStore(), {depth: 2})

asyncLocalStorage.exit(() => {
  // **** this fails because the store returns undefined
  assert.deepStrictEqual(asyncLocalStorage.getStore(), {depth: 1})

  asyncLocalStorage.exit(() => {
    assert.deepStrictEqual(asyncLocalStorage.getStore(), undefined)
  })
})

assert.deepStrictEqual(asyncLocalStorage.getStore(), {depth: 2})
```

But it fails in the line after the marked `****`. The reason I expected it to work is because I assumed that `enter/exit` has the same "stacked" semantics as `run`, in that entering twice and exiting once will give me the store of the first enter. Unfortunately, the store I get after the first `exit` is `undefined`.

### How often does it reproduce? Is there a required condition?

Consistent. Always.

### What is the expected behavior?

The program should pass without error. See above for why.

### What do you see instead?

A failure of the code:

```
node:internal/process/esm_loader:74
    internalBinding('errors').triggerUncaughtException(
                              ^

AssertionError [ERR_ASSERTION]: Expected values to be strictly deep-equal:
+ actual - expected

+ undefined
- {
-   depth: 1
- }
    at file:///Users/giltayar/code/mono/packages/request-id-logger-fastify-plugin/src/foo.js:26:10
    at AsyncLocalStorage.exit (node:async_hooks:323:14)
    at file:///Users/giltayar/code/mono/packages/request-id-logger-fastify-plugin/src/foo.js:24:19
    at ModuleJob.run (node:internal/modules/esm/module_job:152:23)
    at async Loader.import (node:internal/modules/esm/loader:166:24)
    at async Object.loadESM (node:internal/process/esm_loader:68:5) {
  generatedMessage: true,
  code: 'ERR_ASSERTION',
  actual: undefined,
  expected: { depth: 1 },
  operator: 'deepStrictEqual'
}
```

### Additional information

This also fails in v14.15.1
Repository: ant-design
Issue: 自定义主题时将 @font-size-base 设置为 12px 后 @input-padding-vertical-base 计算有 0.2px 的误差导致样式异常
Labels: help wanted,Inactive

- [x] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### Reproduction link
[https://github.com/Carrotzpc/antd-demo](https://github.com/Carrotzpc/antd-demo)

### Steps to reproduce
```
git clone https://github.com/Carrotzpc/antd-demo.git
cd antd-demo
yarn
yarn start
```

### What is expected?
input 高度正常

### What is actually happening?
input 高度不正常，期望 antd 改进 `@input-padding-vertical-base` 的计算方法

| Environment | Info |
|---|---|
| antd | 4.9.4 |
| React | 17.0.1 |
| System | win10 |
| Browser | Chrome  87.0.4280.88（正式版本） （64 位） |

### 补充
![image](https://user-images.githubusercontent.com/10265417/103342987-e1120780-4ac5-11eb-94eb-a4f24dea5aa2.png)
![image](https://user-images.githubusercontent.com/10265417/103343008-eec78d00-4ac5-11eb-9d7e-dd6540b614d2.png)

### 临时解决办法

将 `@input-padding-vertical-base`  这个 less 变量替换为 `5.8px`

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: storybook
Issue: Creating a const var of type Meta then default exporting it results in having a blank story source panel
Labels: bug,addon: storysource

**Describe the bug**

Creating a const var of type Meta then default exporting it results in having a blank story source panel.

The inline default export "as Meta" works well.

**Expected behavior**

The source code should display correctly with the default export of a const var of type Meta.

**Screenshots**

Empty story source panel:

![image](https://user-images.githubusercontent.com/75311636/103343984-9b394d00-4a8d-11eb-8acc-3a326be0b317.png)

Working story source panel:

![image](https://user-images.githubusercontent.com/75311636/103344634-6f1ecb80-4a8f-11eb-9e8c-51e1ca72637a.png)

**Code snippets**

Empty story source panel:

```
/** @jsx jsx */
import { jsx } from "@emotion/core";

import { FC } from "react";
import { Meta, Story } from "@storybook/react/types-6-0";

export const Issue: Story<FC> = () => (
  <input onChange={() => {}} value="No code in the panel" />
);

const meta: Meta = {
  title: "Issue",
  component: Issue,
};

export default meta;
```

Working story source panel:

```
/** @jsx jsx */
import { jsx } from "@emotion/core";

import { FC } from "react";
import { Meta, Story } from "@storybook/react/types-6-0";

export const Issue: Story<FC> = () => (
  <input onChange={() => {}} value="This is working" />
);

export default {
  title: "Issue",
  component: Issue,
} as Meta;
```

**System**

Versions:

    "@storybook/addon-storysource": "^6.1.11",
    "@storybook/addons": "^6.1.11",
    "@storybook/preset-create-react-app": "^3.1.5",
    "@storybook/react": "^6.1.11",
    "@storybook/theming": "^6.1.11",

    "react": "^17.0.0",
    "@types/react": "^16.9.34",
    "@emotion/core": "^10.0.27",

Browser:

     "Google Chrome Version 87.0.4280.88"

OS: 

     "Windows 10 Pro 20H2"
Repository: TypeScript
Issue: Type parameter gets optionalized during call signature comparison
Labels: Bug

# Bug Report

### 🔎 Search Terms

type parameter union undefined optional

### 🕗 Version & Regression Information

3.3.3333, 4.1.3, master (303ed3a357)

### ⏯ Playground Link

[Playground link with relevant code](https://www.typescriptlang.org/play?ts=4.1.3#code/JYOwLgpgTgZghgYwgAgILIN4FgBQzkA8AKgHwAUu++EAHhAgK5gD2UAXMhXlflBAM7MANgDcIHbNx74yIuEIbjkRAJQcRzYABMA3JWkBfZADJM+6ZzkKIAfg6r1m3eaoGXK5AF4SyDdv1qyno4bji4oJCwiCgAQmbcxOQutPRMrBxcFnyCokqSFjJWivaBfs5SribxBZbyinbKpU7BFqE8Ht6+TgH2waG4CMwg-GDIcBxxnphGcPxowUA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
interface A {
  <T>(
    executor: (
      resolve: {
        (value: T): void;
      } & {
        (value?: T): void;
      }
    ) => void
  ): T;
}

interface B {
  <T>(
    executor: (
      resolve: {
        (value: T): void;
      } & {
        (value?: T): void;
      }
    ) => void
  ): T;
}

const a: B = {} as A;
```

### 🙁 Actual behavior

Compile error at the last line:

```
Type 'A' is not assignable to type 'B'.
  Type 'T | undefined' is not assignable to type 'T'.
    'T' could be instantiated with an arbitrary type which could be unrelated to 'T | undefined'.
      Type 'undefined' is not assignable to type 'T'.
        'T' could be instantiated with an arbitrary type which could be unrelated to 'undefined'.
```

### 🙂 Expected behavior

There should be no compile error, as `A` and `B` have exactly the same definition.
Repository: rust
Issue: Diagnostics hint for const generics
Labels: C-enhancement,A-diagnostics,T-compiler,A-suggestion-diagnostics,A-const-generics,D-terse

## Current Behavior

Given the following code:

```rust
let mut combinations = (1..2).combinations();
assert_eq!(combinations.next(), None);
```
where `Iterator::combinations` is defined as:

```rust
fn combinations<const N: usize>(self) -> Combinations<Self, N>;
```
The following diagnostic is provided:
```txt
error[E0282]: type annotations needed
   --> src\lib.rs:144:32
    |
144 |         let mut combinations = (1..2).combinations();
    |                                ^^^^^^^^^^^^^^^^^^^^^
    |
    = note: unable to infer the value of a const parameter
```

**Attempting a fix, and failing:**

Naively I thought I could fix this by adding a turbofish, but that doesn't seem to help:

```rust
let mut combinations = (1..2).combinations::<[usize; 2]>();
assert_eq!(combinations.next(), None);
```
```txt
error[E0107]: wrong number of const arguments: expected 1, found 0
   --> src\lib.rs:144:39
    |
144 |         let mut combinations = (1..2).combinations::<[usize; 2]>();
    |                                       ^^^^^^^^^^^^ expected 1 const argument

error[E0107]: wrong number of type arguments: expected 0, found 1
   --> src\lib.rs:144:54
    |
144 |         let mut combinations = (1..2).combinations::<[usize; 2]>();
    |                                                      ^^^^^^^^^^ unexpected type argument
```

## Expected behavior
Providing a hint on how to correctly define const generics would be immensely helpful. I'm sure I'll be able to figure out the syntax for this eventually (currently going through https://github.com/rust-lang/rust/pull/78460 among others), but given we're set for a 1.51 stabilization of `min_const_generics` I suspect more people will be running into this soon.

## Further Considerations

I was looking at how hints work for e.g. missing type params in `collect`, and noticed no hints are provided there either. It only explains what to do, not showing how to do it. For something that's notoriously tricky to learn that seems like it could benefit from hints as well.

```rust
let x = (1..5).collect();
```
```txt
error[E0282]: type annotations needed
 --> src/main.rs:2:9
  |
2 |     let x = (1..5).collect();
  |         ^ consider giving `x` a type
```