sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Interface Overload Generic Member - Compiler error when removing overload
Labels: Bug,Help Wanted

# Bug Report

Removing an overload member ``Controller.handle`` from ``Controller`` causes a compilation error.

### 🔎 Search Terms

- Interface overload
- Member Type Parameter
- Works When Removing overload

### ⏯ Playground Link

[Playground](https://www.typescriptlang.org/play?ssl=12&ssc=1&pln=13&pc=1#code/KYDwDg9gTgLgBASwHY2FAZgQwMbDgCRhjACVgBnSJc4AHgBUA+OAbwCg45yZMYBXcgGEIAE2AAuOEj4BbAEZoA3BzhzRAT0n04AHzgBRKFGjKAvmzahIsRCjRZcBIqWABHPhRgNm7TmpHqAPxaZhZW0PDIqBg4eMIoxgA2iWisFpwA9BlwZDIQAG7IAOZwmEjqcBDocDAAFngFaIkQmGLkcDKYANZ42JgCFKVw2BAyYAiJvNBwaMZQKrVlIineABS1zmTunpKExFse3N4AlLubFFQ03sqci0jLdPQHngA0cE8XENTAjOvn29wzvs3IcvB8ATBGKcnMDKF8rh84d9GKFLOAIsNJuR2gBlBBFJAAVTA8RgSRSUEQYxSMmAKHapPJqV8cDuDz+wIhQJcENoeIJz24UO5ZCRV35SEFkLSKk4CGqHJ5oIAdP4KgBeTVSPjJXR6DaclVquCa9VwPj3YDoZDAETHNKcR01WrGADuUmA7sMc1WACIAEKtHIgzy+46yuDmCMjajwY1mg1KzyqjTKCPyuCrY0AQi10l1ADIC6oNHBc2aLWJrUhbfaWU6Y+QICllc0ilmNMqkJhaeGnVGnXU3R6vUZoH6AHIQSLU4C0uwiGYgXBgGAIL5hm6RthR8I2KL2WJwCVSh1SHsSLhk4pbueYCaSbhQG8qMCYbGu6AiR-XpBFLdvh+X7xNaUCdGuXw-s+f5mEAA)

### 💻 Code

Code below compiles

``` typescript
export interface Controller {
  handle<T>(httpRequest: HttpRequest<T>): HttpResponse<T>;
  handle<TRequest, TResponse>(httpRequest: HttpRequest<TRequest>): HttpResponse<TResponse>;
}
```

Code below does not compile

``` typescript
export interface Controller {
  // handle<T>(httpRequest: HttpRequest<T>): HttpResponse<T>;
  handle<TRequest, TResponse>(httpRequest: HttpRequest<TRequest>): HttpResponse<TResponse>;
}
```

Code below does not compile

``` typescript
export interface Controller {
  handle<T>(httpRequest: HttpRequest<T>): HttpResponse<T>;
  // handle<TRequest, TResponse>(httpRequest: HttpRequest<TRequest>): HttpResponse<TResponse>;
}
```

### 🙁 Actual behavior

Code does not compile when removing any of the overloads.

### 🙂 Expected behavior

Since having an overload in ``Controller.handle`` works, having just one member with the correct signature should also work. 

### Additional Info

- [Stack Overflow Question](https://stackoverflow.com/questions/74265542/generics-resolve-into-intersection-type#comment131122918_74265542)
Repository: pytorch
Issue: `torch.nn.RReLU` not reporting `lower > upper` on CUDA
Labels: module: cuda,triaged

### 🐛 Describe the bug

If we set `lower > upper` for a `torch.nn.RReLU` layer, it does not report error when the layer is built, or even when it is applied to a CUDA tensor. It is discovered only after being applied to a tensor on CPU. 

``` python
m = torch.nn.RReLU(lower=0.3, upper=0.2)
x = torch.tensor([-1., -1, -1, -1]).cuda()
mx = m(x)
print(mx)
y = torch.tensor([-1., -1, -1, -1])
my = m(y)
```

Run the code above and you get: 

```
tensor([-0.2930, -0.2569, -0.2189, -0.2043], device='cuda:0')
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
[<ipython-input-3-44e43dbfd4d8>](https://localhost:8080/#) in <module>
      4 print(mx)
      5 y = torch.tensor([-1., -1, -1, -1])
----> 6 my = m(y)

2 frames
[/usr/local/lib/python3.7/dist-packages/torch/nn/functional.py](https://localhost:8080/#) in rrelu(input, lower, upper, training, inplace)
   1673         result = torch.rrelu_(input, lower, upper, training)
   1674     else:
-> 1675         result = torch.rrelu(input, lower, upper, training)
   1676     return result
   1677 

RuntimeError: Expected from <= to to be true, but got false.  (Could this error message be improved?  If so, please report an enhancement request to PyTorch.)
```

Maybe we can check for the validity of `lower` and `upper` immediately when the layer is constructed. It will not affect runtime performance much since it is only done once, not every time when it is applied to a tensor. 

### Versions

Collecting environment information...
PyTorch version: 1.12.1+cu113
Is debug build: False
CUDA used to build PyTorch: 11.3
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.6 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
CMake version: version 3.22.6
Libc version: glibc-2.26

Python version: 3.7.15 (default, Oct 12 2022, 19:14:55)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.133+-x86_64-with-Ubuntu-18.04-bionic
Is CUDA available: True
CUDA runtime version: 11.2.152
CUDA_MODULE_LOADING set to: 
GPU models and configuration: GPU 0: Tesla T4
Nvidia driver version: 460.32.03
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.1.1
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.21.6
[pip3] torch==1.12.1+cu113
[pip3] torchaudio==0.12.1+cu113
[pip3] torchsummary==1.5.1
[pip3] torchtext==0.13.1
[pip3] torchvision==0.13.1+cu113
[conda] Could not collect

cc @ngimel
Repository: storybook
Issue: Vite and Webpack builders handle .env files differently
Labels: documentation,builder-webpack5,builder-vite

### Describe the bug

In Vite, environment variables specified in .env files are only injected into the client if they start with `VITE_`.  For the Storybook builder, we add `STORYBOOK_` as well, and this setting is configurable by the `envPrefix` Vite setting.  This also applies to environment variables specified in the `env` preset field, since calling `presets.apply('env')` returns all variables from the .env file(s) and the `env` preset field.

In the Webpack builder, all environment variables are loaded into Storybook.  This can have security implications, but it is the way that storybook has worked for a long time, so changing it could be disruptive.

This could be confusing to those moving from webpack to vite storybooks, if they are not familiar with the default behavior of Vite.  We should ideally update the webpack behavior to be more secure, but at the very least document the Vite behavior in the docs for the `env` field.

### To Reproduce

_No response_

### System

_No response_

### Additional context

Discussion in Discord: https://discord.com/channels/486522875931656193/1036583015377272882/1036583015377272882
Repository: pytorch
Issue: [docs] torch.is_neg/torch.Tensor.is_neg not documented
Labels: module: docs,triaged

### 📚 The doc issue

It seems to be public but there is no documentation.
```python
>>> torch.is_neg(t)
False
>>> torch.is_neg.__doc__
>>> 
```


### Suggest a potential alternative/fix

_No response_

cc @svekars @carljparker
Repository: pytorch
Issue: Add a config option to raise errors instead of warnings in nvFuser integration
Labels: triaged,module: nvfuser

        FWIW, this test will be less fragile if you have a way to convert nvfuser warnings into true errors. Otherwise, if someone adds an unrelated warning that this test happens to exercise, this test will start failing

_Originally posted by @ezyang in https://github.com/pytorch/pytorch/pull/88186#discussion_r1010485596_
      

cc @kevinstephano @jjsjann123
Repository: storybook
Issue: [Bug]: storyStoreV7 completely break stories
Labels: bug,needs triage

### Describe the bug

storyStoreV7, broken
[screencast-nimbus-capture-2022.11.01-10_59_50.broken.webm](https://user-images.githubusercontent.com/4440365/199266754-fbca90cf-4f8b-4b4e-ba72-dbf0f8bb76cd.webm)

Before v7, ok
[screencast-nimbus-capture-2022.11.01-11_06_55v6.webm](https://user-images.githubusercontent.com/4440365/199266696-206849aa-bfd4-4416-8fc4-537b65c6f84f.webm)


### To Reproduce

The only thing changed was enabling `storyStoreV7` and the `storySort` function.

main..js
```
  features: {
    postcss: false,
    // storyStoreV7: true,
  },
```

preview.js
```
  // Sort the story by their title for easier visual look up
  // See: // https://storybook.js.org/docs/react/writing-stories/naming-components-and-hierarchy#sorting-stories
  options: {
    // Use with storyStore v6
    storySort: (a, b) => {
      return a[1].kind === b[1].kind
        ? 0
        : a[1].id.localeCompare(b[1].id, undefined, { numeric: true });
    }
    // https://github.com/storybookjs/storybook/blob/next/MIGRATION.md#v7-style-story-sort
    // storySort: (a, b) => {
    //   return a.title === b.title
    //     ? 0
    //     : a.id.localeCompare(b.id, undefined, { numeric: true });
    // }
  },
```

The main reason why we want to try v7 is because it is taking too much time to load Storybook, and we wanna speed things up...

### System

```
Environment Info:

  System:
    OS: Linux 5.15 Ubuntu 22.04.1 LTS 22.04.1 LTS (Jammy Jellyfish)
    CPU: (16) x64 Intel(R) Xeon(R) Silver 4108 CPU @ 1.80GHz
  Binaries:
    Node: 16.15.1 - ~/.config/nvm/versions/node/v16.15.1/bin/node
    npm: 8.11.0 - ~/.config/nvm/versions/node/v16.15.1/bin/npm
  Browsers:
    Chrome: 106.0.5249.119
  npmPackages:
    @storybook/addon-actions: ^6.5.12 => 6.5.12 
    @storybook/addon-essentials: ^6.5.12 => 6.5.12 
    @storybook/addon-interactions: ^6.5.12 => 6.5.12 
    @storybook/addon-links: ^6.5.12 => 6.5.12 
    @storybook/addon-storysource: ^6.5.12 => 6.5.12 
    @storybook/preset-create-react-app: ^3.2.0 => 3.2.0 
    @storybook/react: 6.5.12 => 6.5.12 
    @storybook/testing-library: 0.0.13 => 0.0.13
```


### Additional context

_No response_
Repository: vscode
Issue: [Accessibility] Open Folder dialog controls do not have accelerator keys
Labels: feature-request,accessibility,quick-open

CC @isidorn

## System Info

Version: 1.73.0-insider (system setup)
Commit: 3544aabd5a2b0da2cd3a6f3fa3f00759aa9d9709
Date: 2022-10-27T21:34:51.585Z
Electron: 19.0.17
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Windows_NT x64 10.0.22621
Sandboxed: Yes

## Reproducible Steps

1. In VSCode, press Ctrl+K, Ctrl+O to trigger "Open Folder ..." dialog box.

1. See if the following fields have any acceleator keyboard shortcuts:

  - [ ] Folder name text field

  - [ ] Folder location treeview

  - [ ] Select Folder button

None of them above has accelerator keys whereas "Open File ... (Ctrl+O)" dialog has them, such as File Name (Alt+N), File Type (Alt+T), OK (Alt+O), etc.

Please add keyboard shorcuts to each control for better accessibility.
Repository: godot
Issue: Keyboard shortcuts should either not be consumed or not allow conflicts
Labels: discussion,topic:input

### Godot version

4.0 beta 4

### System information

MacOS 12.3.1

### Issue description

Half the time I use a keyboard shortcut in Godot (3 or 4), it doesn't work because I have the Script Editor focused and it consumes the shortcut.  The other half of the time it seems something else I've focused consumes the shortcut :) . 
 [Examples: #61782, #56961]

Yet Godot ships with these overlapping shortcuts which then fail to work as advertised.

To fix this we should do one of the following:

1. Allow shortcuts to trigger *all* mapped actions and provide a warning when mapping to an existing shortcut (like other IDEs e.g. VSCode do).
2. Prevent conflicting shortcuts from existing if both contexts could be simultaneously active (e.g. Script Editor and general IDE shortcuts).

Whichever one gets implemented, the default shortcuts should then be updated to not conflict to adhere to the Principle Of Least Astonishment.

### Steps to reproduce

1. Open a script in an existing project.
2. Focus the Script Editor.
3. Press Command+Comma or Command+B on mac.

Expected behavior: Editor Settings opens or the project plays, respectively.
Actual result: Nothing (or probably something to do with breakpoints or bookmarks)

### Minimal reproduction project

_No response_
Repository: create-react-app
Issue: Reduce dependency on config overriding libraries
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?

Today, CRA does not allow us to create named vendor bundles. The vendor chunks continue to be numbered (`1.hash.chunk.js`) instead of named (`vendors~main.hash.js`). We have post build processing in our CI pipelines that scans the code that is generated for any open source dependency vulnerability but the because the bundles generated are numbered and not named, they are getting ignored today. Our way past it is to use config override libraries like craco - that allow us to create named vendor bundles. However, these libraries are not being maintained actively to make it work with different scenarios like npm 7+ which has changed legacy peer dependency behavior resulting in failed builds. They also don't have well-documented release cadence that line up with the releases of CRA.

### Describe the solution you'd like

It would be really great if CRA provided a config somewhere which would allow us to choose between named vs numbered vendor bundles (chunks). I have seen this https://github.com/facebook/create-react-app/issues/6155 and did not see any maintainer respond to the issue. 

I would love to move away from this custom libraries that augment the ability of CRA as that reduces our project's ability to reliably upgrade to the latest version of CRA.

### Describe alternatives you've considered

As mentioned above, we have used the library called craco - that allows us to override the underlying webpack config. I would like to move away from these libraries if I can to improve the reliability of my project upgrades. Currently we are not able to move to CRA 5 because the latest version of Craco is still not compatible with CRA 5 and we can avoid delays in the upgrade if we are solely invested in the CRA eco-system without any 3rd party libraries.
Repository: PowerToys
Issue: Screen ruler: option to auto select the 'Bounds' option automatically without extra click
Labels: Idea-Enhancement,Needs-Triage,Product-Screen Ruler

### Description of the new feature / enhancement

After pressing the hotkey WIN + Shift + M, auto select the first option 'Bounds'.

Or provide a drop down in the settings to select which draw option is auto selected.

### Scenario when this would be used?

When having to measure many things back to back, that extra click is proving to be quite tedious. I personally only use the 'bounds' option.

### Supporting information

_No response_
Repository: godot
Issue: Shift+Command+Up is hidden, unremovable shortcut conflicting with user shortcut
Labels: bug,topic:editor,topic:input,topic:gui

### Godot version

4.0 beta 4

### System information

Mac OS 12.3.1

### Issue description

In the Script Editor Shift+Command+Up behaves as expected in Mac OS: it selects text to the beginning of the document.

But if that key combo is added by the user as a keyboard shortcut for e.g. Expand Bottom Panel, it won't work when the Script Editor is focused, as the Script Editor consumes the shortcut (#68122).

The normal workaround until #68122 is fixed is to remove the offending Script Editor shortcut, but this one does not appear in the shortcut editor.

The fix: either fix #68122 or expose Shift+Command+Up and other text-movement-related keys as shortcuts to remove.

### Steps to reproduce

1. Remap Expand Bottom Panel to Shift+Command+Up instead of Shift+F12.
2. Focus the Script Editor.
3. Press Shift+Command+Up.  The Bottom panel is not expanded.
4. Open Keyboard Shortcuts and search for Shift+Command+Up to remove it as a workaround for #68122.

Expected behavior:
Shift+Command+Up is listed for "Select to beginning of document" so that you can delete or remap it.

Actual behavior:
No results found.

### Minimal reproduction project

_No response_
Repository: vscode
Issue: Support custom "reverse requests" from debug adapters
Labels: debug,under-discussion,api-proposal

Debug adapters can send events that are not part of the DAP spec that can be handled by extensions by subscribing to [`vs.debug.onDidReceiveDebugSessionCustomEvent`](https://code.visualstudio.com/api/references/vscode-api#debug.onDidReceiveDebugSessionCustomEvent).

But events are not the only thing that DAs can send, they can also send ["reverse requests"](https://microsoft.github.io/debug-adapter-protocol/specification#reverse-requests) such as `runInTerminalRequest`.

It's not currently possible to create custom reverse requests because there is no hook like `onDidReceiveDebugSessionCustomEvent` for handling custom requests. This can be useful when a debug adapter needs to get some information from the extension - for example if a debug adapter is launching a web app and needs to expose a URI through `vscode.env.asExternalUri()` and get back the public URI. Right now this has to be done by firing an event from the DA and then having the extension send back another event (which feels awkward given reverse requests already exist in DAP).

@weinand I filed this here because I think it's a VS Code API that's missing and not something for the DAP spec, but if it makes more sense somewhere else like (https://github.com/Microsoft/debug-adapter-protocol), let me know and I can re-raise it. Thanks!
Repository: flutter
Issue: [tool] Support building Android apps with Vulkan Validation Layers
Labels: c: new feature,platform-android,tool,c: proposal,P3,team-android,triaged-android

See https://github.com/flutter/engine/pull/37200

Vulkan is eventully going to become more normal to build/run with on Android. Ideally, developers would benefit from additionaly reporting from VVL during development, which would create better bug reports when something goes wrong. It would be nice if this can be supported in the tool for debug or perhaps non-release builds.
Repository: TypeScript
Issue: Switch-like statement to avoid repetitive 'extends' ternary
Labels: Suggestion,Awaiting More Feedback

# Suggestion

Hi 👋 

I've recently been using the `type MyType<T> = T extends X ? A : B;` more and more, and while it's extremely powerful, the syntax gets messy with a lot of potential types:

```ts
type MyType<T> = T extends A
? AProperties
: T extends B
? BProperties
: T extends C
? CProperties
// ...
: never;
```

My thinking is something like this would be cleaner:

```ts
type MyType<T> = switch(T) {
  case A: AProperties,
  case B: BProperties,
  case C: CProperties,
  // ...
  default: never;
}
```

I feel like this syntax is more reader-friendly - would encourage this conditional/dynamic type pattern usage more (which IMO it should be utilised a lot more).

## 🔍 Search Terms

<!--
  💡 Did you know? TypeScript has over 2,000 open suggestions!
  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.
  The "Common Feature Requests" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests

  Replace the text below:
-->

List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily and help provide feedback.

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
My suggestion meets these guidelines:

* [ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [ ] This wouldn't change the runtime behavior of existing JavaScript code
* [ ] This could be implemented without emitting different JS based on the types of the expressions
* [ ] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [ ] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

<!-- A summary of what you'd like to see added or changed -->

## 📃 Motivating Example

<!--
  If you were announcing this feature in a blog post, what's a short explanation that shows
  a developer why this feature improves the language?
-->

## 💻 Use Cases

<!--
  What do you want to use this for?
  What shortcomings exist with current approaches?
  What workarounds are you using in the meantime?
-->
Repository: TypeScript
Issue: Spread operator with wrong optional property raises error on incorrect source line
Labels: Bug,Help Wanted

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms
spread error wrong line
<!--
  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 versions of TypeScript.

Please keep and fill in the line that best applies:
-->
- This is the behavior in every version I tried, [not applied: and I reviewed the FAQ for entries about]. I tried on v3.3.3 and also on nightly.

### ⏯ Playground Link
<!--
  A link to a TypeScript Playground "Share" link which shows this behavior

  The TypeScript Workbench can be used for more complex setups, try
  https://www.typescriptlang.org/dev/bug-workbench/

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
[Playground link with relevant code](https://www.typescriptlang.org/play?ts=4.9.0-dev.20221025#code/C4TwDgpgBAksEFsoF4oG8CwAoKuoENhgAnASwCMBXeALigGcTSA7AcwG5sBfTrbAYwD2zRlGIR6lADbA6ABXzFgpfFIA8AJQhDiAEzUByQkyrwDAGgZM2UAD5Rm0qQD5nKdNjwEiZUxDoARAHm3NgCwqKk8Ah0cIgomDh4xr7U-lBBIUm4AHR54pIyWVxAA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
type Item = {
    attribute: string;
};

const result: Partial<Record<'attribute', string | null>> = {
    attribute: "",
}

const item: Item ={
    attribute: "",
    ...result,
}
```

### 🙁 Actual behavior
This code is, of course, an error. The surprising thing is *where* the error is raised. In this case the line reading `attribute: "",` will be highlighted with `Type 'string | null' is not assignable to type 'string'.`

In this simple reproduction the error is clear, but when I discovered it the types were more complicated and there were a dozen or more attributes in between the scary red line and the offending spread.
<!-- What happened, and why it was wrong -->

### 🙂 Expected behavior
The diagnostic error would be much more helpful if the spread containing the invalid property was highlighted instead of the property which actually has correct types.
<!-- What you expected to happen instead, and why -->
Repository: flutter
Issue: Text cursors should deterministically show in goldens tests
Labels: a: tests,a: text input,team,framework,P2,team-framework,triaged-framework

Every few months a change to text editing will cause the text cursor animation to shift. This requires goldens to be updated to trivially either show or hide the cursor.

For larger customers, this can be a pain as it can impact several thousand goldens.

By default, text cursors should always show in goldens.

\cc @justinmc @Piinks