sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Git - Missing context menu command to stage deleted hunk in Git
Labels: bug,git

Issue Type: <b>Bug</b>

1. Open a git-tracked file
2. Delete some lines
3. Open a the diff view for the file so that the deleted hunk is marked with a red background
4. Right-click the deleted hunk

Expected:
I can click "stage selected ranges" like I can for added lines.

Actual:
I can only "copy deleted lines" or revert the change from the context menu.

<img width="507" alt="image" src="https://user-images.githubusercontent.com/278463/179004706-5ad9aaf4-39af-4dd5-acb1-4d1955406032.png">

I am creating this as a bug report because I remember being able to do that in the past. I also tried selecting all lines of the deleted hunk before right-clicking but the context menu is the same.


VS Code version: Code 1.69.1 (b06ae3b2d2dbfe28bca3134cc6be65935cdfea6a, 2022-07-12T08:22:10.822Z)
OS version: Darwin arm64 21.3.0
Restricted Mode: No

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Apple M1 Max (10 x 24)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: disabled_off<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>metal: disabled_off<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>skia_renderer: enabled_on<br>video_decode: enabled<br>video_encode: enabled<br>webgl: enabled<br>webgl2: enabled|
|Load (avg)|2, 2, 4|
|Memory (System)|32.00GB (3.42GB free)|
|Process Argv|--crash-reporter-id ff1fb4d3-cce0-4bfb-ad75-165dafb770c7|
|Screen Reader|no|
|VM|0%|
</details><details><summary>Extensions (20)</summary>

Extension|Author (truncated)|Version
---|---|---
vscode-sqlite|ale|0.14.1
emojisense|bie|0.9.1
better-toml|bun|0.3.2
vscode-github-actions|csc|0.24.1
vscode-eslint|dba|2.2.6
githistory|don|0.6.19
gitlens|eam|12.1.2
EditorConfig|Edi|0.16.4
prettier-vscode|esb|9.5.0
vscode-pull-request-github|Git|0.46.0
gc-excelviewer|Gra|4.2.55
vscode-graphql|Gra|0.6.0
dotenv|mik|1.0.1
vscode-json5|mrm|1.0.0
vscode-yaml|red|1.9.1
rust-analyzer|rus|0.4.1126
mdx|sil|0.1.0
errorlens|use|3.5.2
vscode-lldb|vad|1.7.0
vscodeintellicode|Vis|1.2.22

(3 theme extensions excluded)

</details><details>
<summary>A/B Experiments</summary>

```
vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscorecescf:30445987
pythondataviewer:30285071
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
vsc1dst:30438360
pythonvs932:30410667
wslgetstarted:30449410
vscscmwlcmt:30465135
cppdebug:30492333
vscaat:30438848
vsclangdc:30486549

```

</details>

<!-- generated by issue reporter -->
Repository: TypeScript
Issue: Support import types in JSDoc @implements
Labels: Bug,Help Wanted

# Suggestion

## 🔍 Search Terms

`@implements` `jsdoc` `import` `export`

## ✅ Viability Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

We're using JSDoc comments in a package so that we can avoid a build process but still have type validation. We've found current JSDoc support to be very usable, but there is one specific scenario which isn't ideal. When we want to declare an interface that a class should implement we use `@implements` but unlike all of the other tags we're using we can't use an `import('..').Type` node as the implements type. This means we have to use a `@typedef` before hand, which isn't terrible, but also re-exports the type from this module. For commonly used types this leads to massive pollution of the suggestions you get when VSCode is trying to help you automatically import a type.

Ideally there would be some way to import a type for local use, or the `import().Type` syntax would be supported by `@implements` tags.

## 📃 Motivating Example

`SomeLog.ts`
```
export interface SomeLog {
  foo(): void
}
```

`Log.mjs`
```
/** @typedef {import('./SomeLog')} SomeLog */

/**
 * @implements {SomeLog}
 */
export class Log {
  foo() { }
}
```

With this setup `SomeLog` is "exported" from both `SomeLog.ts` and `Log.mjs` which is undesirable and leads to accidentally importing code from the wrong place.

## 💻 Use Cases

I think I explained this in my suggestion pretty well.
Repository: go
Issue: x/tools/gopls: use overlays when computing mod tidy diagnostics
Labels: gopls,Tools

We currently invalidate mod tidy results whenever metadata changes, but compute diagnostics based on saved files. This can be very confusing as go.mod diagnostics do not match the current workspace state.

With native overlay support, we should be able to make mod tidy diagnostics honor unsaved changes, and should explore updating mod tidy diagnostics whenever metadata changes.
Repository: material-ui
Issue: [Alert] Filled variant text color should be using theme.palette[color].contrastText and not theme.palette.getContrastText
Labels: docs,component: alert

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Current behavior 😯

Currenly theme.palette.getContrastText is used to calculate text color.

### Expected behavior 🤔

Expected color to be provided from theme.palette[color].contrastText

![image](https://user-images.githubusercontent.com/8037810/179012093-8ddc8a0a-e4b4-4319-9acc-10d1da80dc6c.png)


### Steps to reproduce 🕹

https://codesandbox.io/s/clever-almeida-u36ek8?file=/src/App.tsx

### Context 🔦

Pull request broke Alert https://github.com/mui/material-ui/pull/29813 text colour. If contrastText is provided it should not calculate theme.palette.getContrastText or should account on provided contrastText

### Your environment 🌎

_No response_
Repository: PowerToys
Issue: Automatic window arrangement in FancyZones
Labels: Idea-Enhancement,Product-FancyZones,Needs-Triage

### Description of the new feature / enhancement

The FancyZones function is a very useful tool for anyone looking for productive efficiency on their computer, but there's only one small option missing to make it the perfect tool: Automatic window arrangement. Every time I open the windows, they open one on top of the other, in the last recognized position, but what if they automatically sorted themselves into the template in use? Here's this suggestion that can improve the tool a lot.

### Scenario when this would be used?

FancyZones

### Supporting information

_No response_
Repository: rust
Issue: Unintuitive behavior with inferred lifetimes for closures
Labels: A-lifetimes,A-closures,A-inference,T-types

I'm not sure this is a bug at all, but it's an unintuitive behavior, and I couldn't find any other issues about it, so I figured I would bring it to attention. I have a trait like so:
```rust
trait MyFn<Params> {
    
    type Output;
    
    fn call(&mut self, params: Params) -> Self::Output;
    
}
```
And a macro to generate `impl`s up to a certain arity, like so:
```rust
impl<P0, R, F: FnMut(P0,) -> R> MyFn<(P0,)> for F {
    
    type Output = R;
    
    fn call(&mut self, (p0,): (P0,)) -> R {
        self(p0,)
    }
    
} 
```
(For an example of how this kind of "custom Fn" trait can be useful, see [bevy's systems](https://docs.rs/bevy/latest/bevy/prelude/struct.App.html#method.add_system).)

In my case, I would like to `Box` these `MyFn`s and use them dynamically, like so:
```rust

struct FnBox {
    
    f: Option<Box<dyn for<'a> MyFn<(&'a u8,), Output = ()> + 'static>>
    
}

impl FnBox {
    
    fn new() -> Self {
        Self { f: None }
    }

    fn set<F: for<'a> MyFn<(&'a u8,), Output = ()> + 'static>(&mut self, f: F) {
        self.f = Some(Box::new(f));
    }
    
    fn call(&mut self, b: &u8) {
        if let Some(f) = self.f.as_mut() {
            f.call((b,));
        }
    }
    
}
```

However, if I try to call `FnBox::set` with a closure, (i.e. `fb.set(|b| println!("{b}"));`)
I get this error:
```
error: implementation of `FnOnce` is not general enough
 --> src/main.rs:5:8
  |
5 |     fb.set(|b| println!("{b}"));
  |        ^^^ implementation of `FnOnce` is not general enough
  |
  = note: closure with signature `fn(&'2 u8)` must implement `FnOnce<(&'1 u8,)>`, for any lifetime `'1`...
  = note: ...but it actually implements `FnOnce<(&'2 u8,)>`, for some specific lifetime `'2`
```
which, if I'm reading it correctly, means that it's inferring `|b: &'2 u8| println!("{b}")` when what I want is `for<'1> |b: &'1 u8| println!("{b}")` (of course, I can't actually name `'1` or `'2` currently; I've got my eye on you, [closure lifetime binder](https://rust-lang.github.io/rfcs/3216-closure-lifetime-binder.html)).

Of course, I want this code to work, but the actual point of this issue is that this is inconsistent with the behavior of the `Fn` traits: if I change the signature of `FnBox::set` to
```rust
fn set<F: for<'a> FnMut(&'a u8,) -> () + 'static>(&mut self, f: F)
```
then the lifetime is inferred correctly and the code works exactly as expected (I don't even need to change any of the other code to match thanks to the `impl MyFn for F: FnMut`).

Like I said at the beginning, I doubt this is a bug; it's probably more or less intended behavior, but I'm bringing it up to question whether it *should* be intended behavior.
Repository: PowerToys
Issue: We should be able to specifiy which modifier (right or left or both) should open PowerToys Run
Labels: Idea-Enhancement,Product-PowerToys Run

### Description of the new feature / enhancement

The title explains it all, I did some remapping in my keyboard to be able to match mac, my left ctrl is set to right ctrl and my alt key as left ctrl and i really wish i can specify which one of those two can open PowerToys

### Scenario when this would be used?

when i want to open it with left ctrl + space but not right ctrl + space because it's used as another shortcut for another thing like vs code togglesuggestions for example

### Supporting information

_No response_
Repository: rust
Issue: NVPTX: Debug section symbol naming in .ptx output
Labels: A-debuginfo,T-compiler,O-NVPTX,C-bug

When the panic machinery is used in a `ptx-kernel` it generates a symbol in the debug section that is generated in a different way than the symbol it refers to.

Today when compiling to ptx (`--target nvptx64-nvidia-cuda`) all debug info is stripped by ptx-linker [here](https://github.com/denzp/rust-ptx-linker/blob/master/src/linker.rs#L167). This decision predates debug info support on nvptx in llvm and it seems like there are only a few obstacles left to be able to debug rust code with cuda-gdb. **Nonetheless, getting debug symbols into .ptx requires installing a ptx-linker with [this](https://github.com/denzp/rust-ptx-linker/blob/master/src/linker.rs#L168) `LLVMStripModuleDebugInfo` commented out**.

It is reproducable with the following code compiled with `cargo +nightly-2022-06-18 rustc --target nvptx64-nvidia-cuda -Zbuild-std -- -C target-cpu=sm_86`
```rust
#![no_std]
#![feature(abi_ptx)]

#[no_mangle]
pub extern "ptx-kernel" fn foo() {
    panic!("bar");
}

#[panic_handler]
fn panic(panic_info: &core::panic::PanicInfo) -> ! {
    loop{
    }
}
```

Inside `.section .debug_info` i get a line looking like `.b64 anon.e3d4032e2030354db324b88c41516303.47`. I assume it refers to the line `.global .align 8 .u64 anon_$_e3d4032e2030354db324b88c41516303_$_47[4] = {_ZN4core3ptr88drop_in_place$LT$core$$panic$$panic_info$$PanicInfo$$internal_constructor$$NoPayload$GT$17h951018dc744e645eE, 0, 1, _ZN36_$LT$T$u20$as$u20$core$$any$$Any$GT$7type_id17h215c4e91a81cf303E};`

If I manually change this line to `.b64 anon_$_e3d4032e2030354db324b88c41516303_$_47` ptxas stops complaining on this line (but still complains on a different nvptx debug info issue).

If anyone got any pointers to where I should start investigate how this symbol mangling can be different from debug symbols and for `.global` variables I would be thankful.

Have you had to deal with this @RDambrosio016?
Repository: material-ui
Issue: [docs-infra] mui.com/docs does not exist
Labels: scope: docs-infra

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Summary 💡

Now that each of MUI's products has its own documentation, we need some kind of unifying landing page to show users how to make the most of our docs to find what they need.

I'm envisioning a "Welcome" page at mui.com/docs similar to [plausible.io/docs](http://plausible.io/docs). This would be like an Overview of the Overview pages that we've been publishing for each of the products—one or two lines introducing the products, plus details about how to use the docs (search, play with codesandbox demos), how to get help, how to submit issues, etc.

Once we've established this new area of the docs, we can expand it over time to include any documentation that applies across all products. But I think it needs to start with a single landing page.

### Examples 🌈

<img width="1604" alt="Screen Shot of plausible.io/docs showing their documentation Welcome page" src="https://user-images.githubusercontent.com/71297412/179036477-798cbaf2-653b-4210-a981-5d6ba24cbc99.png">


### Motivation 🔦

When users click on **Docs** in the mui.com nav bar, it feels like it should lead to mui.com/docs rather than forcing them to choose one of our products. What if they don't know which one to select? They should be able to easily compare the products in one location without having to read multiple docs in different places. 

### Benchmark

- Introduction docs page https://www.apollographql.com/docs/ Apollo Docs Home
- Generic list https://www.twilio.com/docs
- Generic list https://developers.google.com/
- Generic list https://grafana.com/docs/
- Generic list https://docs.konghq.com/
- No centralized docs page https://www.hashicorp.com/products/terraform
Repository: flutter
Issue: Getting GestureRecognizers to respect each other
Labels: a: text input,framework,f: gestures,a: desktop,P2,team-framework,triaged-framework

In super_editor, we're trying to add support to `SuperTextField` on desktop to allow arbitrary gesture interactions on top of the text field. For example, an app should be able to implement `ALT + LEFT CLICK` to open a context menu.

Currently, this is a challenge because we can't seem to prevent both the app-level gestures and the `SuperTextField` internal gestures from both responding to user interactions. I have a PR that illustrates our attempt to do this: https://github.com/superlistapp/super_editor/pull/692

FYI - There's a test in the PR that's currently failing. That should demonstrate the issue.

I think we need the insight of the Flutter team to determine if there's presently a mechanism that would allow these two `GestureRecognizer`s to cooperate in the gesture arena, or whether this use-case is impossible with the current gesture system.
Repository: vscode
Issue: The background of main interface became grey.
Labels: bug,freeze-slow-crash-leak,notebook-output

Issue Type: <b>Bug</b>

I am using Jupyter Notebook in VS code. When I wheeled down the interface, it became grey. It happened before. Cannot see any pics clearly.

VS Code version: Code 1.69.1 (b06ae3b2d2dbfe28bca3134cc6be65935cdfea6a, 2022-07-12T08:21:24.514Z)
OS version: Windows_NT x64 10.0.19044
Restricted Mode: No

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz (12 x 3192)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: disabled_off<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>skia_renderer: enabled_on<br>video_decode: enabled<br>video_encode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled|
|Load (avg)|undefined|
|Memory (System)|31.80GB (21.36GB free)|
|Process Argv|--crash-reporter-id 1c7786f7-3567-42d0-bd46-6060e36fc1d0|
|Screen Reader|no|
|VM|0%|
</details><details><summary>Extensions (7)</summary>

Extension|Author (truncated)|Version
---|---|---
copilot|Git|1.31.6194
python|ms-|2022.10.0
vscode-pylance|ms-|2022.7.30
jupyter|ms-|2022.6.1101950301
jupyter-keymap|ms-|1.0.0
jupyter-renderers|ms-|1.0.8
cpptools|ms-|1.10.8

(2 theme extensions excluded)

</details><details>
<summary>A/B Experiments</summary>

```
vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonvspyt551cf:30345471
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593:30376534
vsc1dst:30438360
pythonvs932:30410667
wslgetstarted:30449410
vscscmwlcmt:30465135
cppdebug:30492333
vsclangdf:30486550

```

</details>

<!-- generated by issue reporter -->
Repository: godot
Issue: No resize pointer when hovering over the borders of a settings dialog
Labels: platform:linuxbsd,topic:porting,needs testing

### Godot version

3.4.4 (Flatpak)

### System information

Linux Mint 20.3

### Issue description

When resizing a dialog window in Godot, the mouse pointer does not change to a dialog resize pointer when hovering over the dialog window border.

As an example, here is a screenshot of the editor settings with a normal mouse pointer where a dialog resize pointer should actually appear.

![Flatpak_Godot3 4 4_Editor-settings_no-window-resize-cursor](https://user-images.githubusercontent.com/628474/179098071-4668641c-2a98-46c9-ab2e-026d380d5618.png)
.

### Steps to reproduce

1. Install [Godot 3.4.4 as a Flatpak](https://flathub.org/apps/details/org.godotengine.Godot) (on Linux Mint 20.3)
2. Open Godot
3. Open a settings dialog window
4. Hover over the border of this settings dialog with your mouse pointer

### Minimal reproduction project

_No response_
Repository: TypeScript
Issue: API: Expose a way to figure out the `scriptKind`
Labels: Suggestion,Awaiting More Feedback

# Suggestion

## 🔍 Search Terms

api scriptkind

## ✅ Viability Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

It seems like at the moment the `scriptKind` property of `SourceFile` is marked as `@internal`, it would be nice if this was exposed in the public api.

https://github.com/microsoft/TypeScript/blob/a21024dbe7e79dc018e4193f27ecb66e0465b638/src/compiler/types.ts#L3802-L3804

## 📃 Motivating Example

I'd like to know if a `SourceFile` is of `ScriptKind.JS`, so that I can make specific modifications to `.js` files only.
I could simply check if the `SourceFile.fileName` ends with `.js`. But I'd rather make use of the same logic that is used by TypeScript for checking if a file is a JavaScript file. That way I can be sure my application and TypeScript are on the same page of what is and isn't a JavaScript file.

## 💻 Use Cases

I have written a basic transformer that makes several modifications to files in a project. And now I'd like to add `// @ts-nocheck` to all JavaScript files.
Repository: transformers
Issue: [TRACKER] Add alibi tests on BLOOM
Labels: WIP

### Feature request

Add ALiBi tests on BLOOM ! 
We should add several tests to simply to test if alibi has been created correctly

- test padding 
- test expected output

@Narsil 

### Motivation

Build stronger CI tests

### Your contribution

Design and build the tests mentioned above
Repository: godot
Issue: Can't move or rotate an object whose scale is `(0, 0, 0)` using editor gizmos
Labels: bug,topic:editor,usability,regression,topic:3d

*Related to #61491, https://github.com/godotengine/godot/issues/63011 and https://github.com/godotengine/godot/issues/63012.*

### Godot version

4.0.alpha (5fec0d232)

### System information

Fedora 36, GeForce GTX 1080 (NVIDIA 510.68.02)

### Issue description

The 3D editor doesn't make it possible to move or rotate an object whose scale is `(0, 0, 0)` using editor gizmos.

https://user-images.githubusercontent.com/180032/179119572-15aa036b-c7ae-4ae8-87b1-de407b5398a2.mp4

When attempting to rotate a 3D object of scale 0, the following error is also printed every frame:

```
core/math/basis.cpp:64 - Condition "det == 0" is true.
The axis Vector3 must be normalized.
```

This message isn't printed when attempting to move the 3D object though. I also can't reproduce this on 3.5.rc 3f0201335.

### Steps to reproduce

- Add a 3D node of any type (I tested with MeshInstance3D here).
- Set its scale to `Vector3(0, 0, 0)`.
- Try to move it using editor manipulation gizmos.

### Minimal reproduction project

[test_3d_object_move_scale_0.zip](https://github.com/godotengine/godot/files/9116631/test_3d_object_move_scale_0.zip)
Repository: godot
Issue: `ERROR: Condition "det == 0" is true.` is printed when CPUParticles3D has its scale set to `(0, 0, 0)`
Labels: bug,topic:rendering,regression,topic:3d

*Related to https://github.com/godotengine/godot/issues/63010 and https://github.com/godotengine/godot/issues/63012.*

### Godot version

4.0.alpha (5fec0d232)

### System information

Fedora 36, GeForce GTX 1080 (NVIDIA 510.68.02)

### Issue description

This error message is printed once when CPUParticles3D (or any of its parents) has its scale set to `(0, 0, 0)`:

```
ERROR: Condition "det == 0" is true.
   at: invert (core/math/basis.cpp:64)
```

 This doesn't occur with other 3D nodes such as MeshInstance3D. I also can't reproduce this on 3.5.rc 3f0201335.

### Steps to reproduce

- Add a CPUParticles3D node (even without a mesh).
- Set its scale to `Vector3(0, 0, 0)`.

### Minimal reproduction project

[test_cpuparticles3d_scale_0.zip](https://github.com/godotengine/godot/files/9116642/test_cpuparticles3d_scale_0.zip)