sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Shortcut Event Configuration window does not recognize "/" key in ABNT2 keyboards.
Labels: bug,enhancement,topic:editor,topic:input

### Tested versions

- Happend in v4.2.1.stable.official [b09f793f5]

### System information

Windows 11, ABNT2 generic Dell keyboard

### Issue description

In most IDEs the "toggle comment" shortcut is ctrl+/, tried to configure the same in Godot, but it does not recognize the key press, as if no key had been presse at all. When configure manually to use ctrl+/ for that command, it also did nothing in the code editor.

### Steps to reproduce

Editor > Editor Settings > Shortcuts and trying to set ctrl+/ as a shortcut.

### Minimal reproduction project (MRP)

Happens in any project (even an empty one).
Repository: material-ui
Issue: [styled-engine-sc] Types are not taken into account when using `styled` function with a template string
Labels: package: styled-engine-sc

### Steps to reproduce

Link to live example: https://github.com/DND-IT/material-ui-cra-styled-components-ts/pull/1

Steps:
1. Checkout the project
2. Hover the position variable to see, that the type is `any`


### Current behavior

![Screenshot 2024-01-09 at 14 32 53](https://github.com/mui/material-ui/assets/237739/009b12bf-bf29-4390-bab9-c6e6aaaab90b)

### Expected behavior

The provided types must be taken into account

### Context

We try to use proper typed styled-components

### Your environment

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  System:
    OS: macOS 12.6.1
  Binaries:
    Node: 20.10.0 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.2.3 - /usr/local/bin/npm
  Browsers:
    Chrome: 120.0.6099.199
    Edge: Not Found
    Safari: 15.6.1
  npmPackages:
    @mui/base:  5.0.0-beta.30
    @mui/core-downloads-tracker:  5.15.3
    @mui/lab: latest => 5.0.0-alpha.159
    @mui/material: latest => 5.15.3
    @mui/private-theming:  5.15.3
    @mui/styled-engine:  5.15.3
    @mui/styled-engine-sc: 6.0.0-alpha.11 => 6.0.0-alpha.11
    @mui/system:  5.15.3
    @mui/types:  7.2.12
    @mui/utils:  5.15.3
    @types/react: latest => 18.2.47
    react: latest => 18.2.0
    react-dom: latest => 18.2.0
    styled-components: latest => 6.1.8
    typescript: latest => 4.9.5
```
</details>

### Support Key
#80425

**Search keywords**: styled-engine-sc styled-components typescript
Repository: PowerToys
Issue: Preview Pane not Working Properly in v0.76.2 (and v0.77.0)even in the newest WebView2 Runtime
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

v0.76.2 *updates:: and v0.77.0*

### Installation method

GitHub

### Running as admin

Yes

### Area(s) with issue?

File Explorer: Preview Pane

### Steps to reproduce

### Note: I am not sure whether it is a duplicate issue or not. 
I searched all issues in GitHub `powertoys-issue` panel and find that found it might have something to do with the newly updated WebView2 Runtime but, I checked my Powertoys and WebView2 Runtime they are both the newest.

### My problem is slightly different from those issues I've seen. Details in `Actual behaviors` below.

*However, another drive of my PC is in Canary Chennel of Windows 11, and Powertoys (Preview version) in that Windows seems to work properly !*

This issue happens on my current newly-installed Windows. I haven't installed something else except development kits from Visual Studio. So honestly I think  it may not be my PC's fault.

### ✔️ Expected Behavior

i captured the picture from ms doc, which means it should be:
![image](https://github.com/microsoft/PowerToys/assets/63725840/992099b1-1903-43ce-9acb-732b56437b16)


### ❌ Actual Behavior

as for markdown, when i enable the `Markdown` in powertoys settings, it show `this cannot be previewed`:
![image](https://github.com/microsoft/PowerToys/assets/63725840/a01fb838-b471-482b-81e2-fcf3539e7e21)
then I toggle it, it then shows `no preview available`. 
![image](https://github.com/microsoft/PowerToys/assets/63725840/b982adbc-f08b-468e-92c1-b2aa2ec199cb)

as for `.cpp`, things get a little strange.
when I enable the `source code` in powertoys settings, it also shows `this file cannot be previewed`:
![image](https://github.com/microsoft/PowerToys/assets/63725840/ee547f82-8d19-4c24-8e4d-6a8770f04436)
and I toggle it, now preview panel *did* show the code, but in a plain text.(or it may be a bug since I disabled the `source code` option)
![image](https://github.com/microsoft/PowerToys/assets/63725840/98a5b79e-2c68-4c3c-9ae4-bad8ed5e050e)

Problem remains after reboot.



### Other Software

_No response_
Repository: deno
Issue: node:test mock not implemented
Labels: bug,node compat,node API

While there exists a [`std` implementation for mock / spy](https://deno.land/std@0.211.0/testing/mock.ts) logic, `node:test` does not work as it is not implemented.
Running the following example (as `test.mjs` without the `number` type annotation) works fine with `node --test`.

```ts
import { strictEqual } from "node:assert";
import { test } from "node:test";

test("foo", (t) => {
  const fn = t.mock.fn((a: number, b: number) => a + b);
  strictEqual(fn(2, 3), 5);
  strictEqual(fn.mock.callCount(), 1);
});
```

```plaintext
$ deno test
Check file:///tmp/test.ts
running 1 test from ./test.ts
foo ... FAILED (3ms)

 ERRORS

foo => ./test.ts:4:1
error: Error: Not implemented: test.TestContext.mock
    at notImplemented (ext:deno_node/_utils.ts:9:9)
    at NodeTestContext.get mock (node:test:26:5)
    at file:///tmp/test.ts:5:16
    at node:test:99:13

 FAILURES

foo => ./test.ts:4:1

FAILED | 0 passed | 1 failed (6ms)

error: Test failed
```

```plaintext
$ deno --version
deno 1.39.2 (release, x86_64-unknown-linux-gnu)
v8 12.0.267.8
typescript 5.3.3
```
Repository: vscode
Issue: Terminal cannot be dragged out to a new window directly
Labels: feature-request,workbench-dnd,terminal-persistence,workbench-auxwindow

<!-- ⚠️⚠️ 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. -->
Type: **Feature Request**

To create an external vscode window with a terminal I have to firstly drag the terminal from the bottom panel to the tab and then create a new window moving this tab:

![vscode-terminal](https://github.com/microsoft/vscode/assets/30211831/f5d527e1-a2e6-43d9-99c2-656ac6bf5c64)

I'd be great if I could move the terminal from the bottom panel to a new window directly :)
Repository: neovim
Issue: Enable extending queries via `vim.treesitter.query.set`
Labels: enhancement,treesitter

### Problem

There is no way to extend an existing query using `vim.treesitter.query.set`; it ignores all modelines passed to it, making extending existing queries programmatically harder than it needs to be.

### Expected behavior

Either:
1. `vim.treesitter.query.set` handles modelines, or
2. `vim.treesitter.query.set` accepts a fourth optional argument that serves the same purpose as the modelines: `{ extends:bool?, inherits:string[]? }`

I myself wanted to create a utility plugin that would generate highlight queries for `comment` parser from a user-supplied table in order to add new highlight keywords like `SAFETY`. Hardcoding new keywords into query files is not an option, and polluting user's config with queries is not ideal.
Repository: rust
Issue: impl Trait returned from trait method without arguments not detected as 'static
Labels: A-diagnostics,A-lifetimes,T-compiler,C-bug,D-invalid-suggestion

I tried this code:

```rust
trait Original {
    fn f() -> impl Fn();
}

// provide a type-erased helper trait for Original
trait Erased {
    fn f(&self) -> Box<dyn Fn()>;
}

impl<T: Original> Erased for T {
    fn f(&self) -> Box<dyn Fn()> {
        Box::new(<T as Original>::f())
    }
}
```
[Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3241f7074765794137c5b63c94eca740)

I expected the code to compile successfully, but it failed on Rust 1.75.0 with the following error:

```
error[E0310]: the associated type `<T as Original>::{opaque#0}` may not live long enough
  --> src/lib.rs:11:9
   |
11 |         Box::new(<T as Original>::f())
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |         |
   |         the associated type `<T as Original>::{opaque#0}` must be valid for the static lifetime...
   |         ...so that the type `impl Fn()` will meet its required lifetime bounds
   |
help: consider adding an explicit lifetime bound
   |
10 |     fn f(&self) -> Box<dyn Fn()> where <T as Original>::{opaque#0}: 'static {
   |                                  ++++++++++++++++++++++++++++++++++++++++++

For more information about this error, try `rustc --explain E0310`.
error: could not compile `playground` (lib) due to previous error
```

I understand that `Box<dyn Fn()>` is sugar for `Box<dyn Fn() + 'static>`, but in this case the `impl Fn()` return *is* `'static`. It has to be, because `Original::f()` takes no arguments, so the value it returns cannot reference any non-static lifetime.

The workaround is to change the return type of `Erased::f()` from `Box<dyn Fn()>` to `Box<dyn Fn() + '_>`, which is allows the code to compile. ([Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=7a29a72a2e088827d309ab5c3d8a0ee5).) (Another workaround is to change the definition of `Original::f()` to return `impl Fn() + 'static`, but in the original code `Original` is provided by a different crate and cannot be modified.)

A second, and minor issue is that the compiler's suggestion is not actionable because the opaque type returned from `Original::f()` cannot be named.
Repository: rust
Issue: Egui WASM program failing or not failing depending on whitespace/comments and other irrelevant details
Labels: O-wasm,C-bug,E-needs-mcve,S-needs-repro

Egui WASM program failing or not failing depending very sensitively on whitespace/comments and other irrelevant details, similar to https://github.com/rust-lang/rust/issues/110230 but without the ICE.

See https://github.com/emilk/egui/issues/3796#issuecomment-1883097612 for description and test case. 

`rustc --version --verbose`:
```
rustc 1.74.1 (a28077b28 2023-12-04) (gentoo)
binary: rustc
commit-hash: a28077b28a02b92985b3a3faecf92813155f1ea1
commit-date: 2023-12-04
host: x86_64-unknown-linux-gnu
release: 1.74.1
LLVM version: 17.0.6
<version>
```
Repository: rust
Issue: Empty super::{} and self::{} imports gives an error.
Labels: A-resolve,T-compiler,C-bug

### Code

```Rust
mod foo {
    use super::{};
}
```


### Current output

```Shell
error[E0432]: unresolved import `super`
 --> src/lib.rs:2:9
  |
2 |     use super::{};
  |         ^^^^^^^^^ no `super` in the root

warning: unused import: `super::{}`
 --> src/lib.rs:2:9
  |
2 |     use super::{};
  |         ^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default
```


### Desired output

```Shell
warning: unused import: `super::{}`
 --> src/lib.rs:2:9
  |
2 |     use super::{};
  |         ^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default
```


### Rationale and extra context

The same problem exists with an empty `use self::{};` import.

There is no reason for empty self and super imports gives an error when empty `crate::{}`, `some_crate::{}` and `path::to::a::module::{}` imports are perfectly valid. The compiler should of course emit a warning.

If they should be forbidden nonetheless, the error message could be clearer.

It should be noted that the following code if perfectly valid:

```rust
mod bar {}
mod foo {
    use super::bar::{};
}
use self::bar::{};
```

I obtained such a code with empty `super` imports with macros.

### Other cases

_No response_

### Rust Version

```Shell
rustc 1.75.0 (82e1608df 2023-12-21)
binary: rustc
commit-hash: 82e1608dfa6e0b5569232559e3d385fea5a93112
commit-date: 2023-12-21
host: x86_64-unknown-linux-gnu
release: 1.75.0
LLVM version: 17.0.6
```


### Anything else?

_No response_
Repository: PowerToys
Issue: Mouse Without Borders randomly kills host machine's internet connection
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.76.2

### Installation method

PowerToys auto-update

### Running as admin

No

### Area(s) with issue?

Mouse Without Borders

### Steps to reproduce

Mouse without borders works as expected but sporadically when switching between machines,  my internet connection is killed on the host machine.
When this happens the taskbar shows my computer has an IP but no internet connection, I am then unable to disable the ethernet adapter and the only fix is to force powerdown my computer. Restarting will get stuck on the spinning dots.

EDIT: After more testing, the issue does not happen when I disable Clipboard sharing. So it seems to be related to copying. It would happen often when I Ctrl + C 'ed text or files.




[Log_2024-01-09.txt](https://github.com/microsoft/PowerToys/files/13876165/Log_2024-01-09.txt)


### ✔️ Expected Behavior

MWB should not kill my internet connection.

### ❌ Actual Behavior

Sporadically my internet connection on the host is killed when switching machines.

### Other Software

_No response_
Repository: ant-design
Issue: v5 Menu 的手风琴效果异常抖动，v4 没问题
Labels: 🐛 Bug,help wanted,Inactive

### Reproduction link

[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/p/sandbox/antd-issue-menu-accordion-9cn4p5?file=%2Fdemo.tsx%3A5%2C16)

### Steps to reproduce

官网文档即可复现，步骤：
1. 访问 v5 文档
2. 找到“只展开当前父级菜单”示例
3. 来回切换展开的菜单即可复现（请仔细观察鼠标点击后菜单的抖动）

可对比 v4 的文档，依然是 Menu 的“只展开当前父级菜单”示例，发现是没有上述抖动问题的。

### What is expected?

v5 Menu 手风琴效果展开时，菜单不抖动

### What is actually happening?

v5 Menu 手风琴效果展开时，菜单抖动

| Environment | Info |
| --- | --- |
| antd | 5.12.8 |
| React | 18.0.0 |
| System | macOS 13.3.1 |
| Browser | Chrome Latest |

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: TypeScript
Issue: Weak type not rejected when intersected with `ThisType`
Labels: Bug,Help Wanted

### 🔎 Search Terms

* function overload
* ThisType
* this

### 🕗 Version & Regression Information

- This is a crash


### ⏯ Playground Link

https://www.typescriptlang.org/play?#code/JYOwLgpgTgZghgYwgAgGIHt3IN4ChnJwBcyAzmFKAOa4C+uAJhAgDZxQowCuICYw6EMm4gADAAp2VEuICUyALwA+ZOPzIAZGkzqtAFQAWwUnoCeABwgAeDOiW5ZskgDd0wBo2ZsOwnnwFCIhJSMrrIAArs-HAsNpj2BPpGJhbWtvaOLm4euEHieAD0BcgAegD86sTIAOQAjNV0srk8EnKKKvm4RaUVBFV1DbSOXcUAAmCkALQQAB6WfNNQUOhQzWLibcqqhcXllSS1jU1AA

### 💻 Code

```ts
interface Foo {
  a: string
}
declare function fun0(arg: () => (
  & Foo
  & ThisType<Foo>
)): void
declare function fun0(arg: (
  & Partial<Foo>
  & ThisType<Foo>
)): void

fun0({
// ^? function fun0(arg: (Partial<Foo> & ThisType<Foo>)): void (+1 overload)
  a: '1'
})
fun0(() => ({
// ^? function fun0(arg: () => (Foo & ThisType<Foo>)): void (+1 overload)
  a: '1'
}))
// @ts-expect-error
fun0(() => ({
// ^? function fun0(arg: (Partial<Foo> & ThisType<Foo>)): void (+1 overload)
  a: 1
}))
```
When I intersect `ThisType` with a type similar to `{}` and use it as a function argument, it will always resolve to this declaration.


### 🙁 Actual behavior

overload to `function fun0(arg: (Partial<Foo> & ThisType<Foo>)): void (+1 overload)`

### 🙂 Expected behavior

overload to `function fun0(arg: () => (Partial<Foo> & ThisType<Foo>)): void (+1 overload)`

### Additional information about the issue

When I comment `ThisType` intesection, it works.
<img width="705" alt="image" src="https://github.com/microsoft/TypeScript/assets/51358815/4d73560b-dd05-4c6e-bd63-b72774fb8d40">
Repository: flutter
Issue: Flutter tool should fail gracefully when neither build.gradle and build.gradle.kts exist
Labels: platform-android,tool,t: gradle,P2,team-tool,triaged-tool

### Summary

Issue https://github.com/flutter/flutter/issues/140548 requests that Flutter tool start supporting Gradle KTS (that is `settings.gradle.kts` and `build.gradle.kts` files), in addition to `settings.gradle` and `build.gradle` which use Groovy.

PR https://github.com/flutter/flutter/pull/140744 implements this feature, but does not implement all checks, such as failing when e.g. neither `build.gradle.kts` and `build.gradle` exist.

We didn't do that in PR #140744 because we wanted to keep it lean, and that change caused test failures that would result in many out of scope changes. 

### Changes to be made

Example of code that should be added to [`packages/flutter_tools/lib/src/project.dart`](https://github.com/flutter/flutter/blob/3.16.0/packages/flutter_tools/lib/src/project.dart):

```dart
/// Gets top-level Gradle build file.
/// See https://developer.android.com/build#top-level.
///
/// The file must exist and it must be written in either Groovy (build.gradle)
/// or Kotlin (build.gradle.kts).
File get hostAppGradleFile {
  final File buildGroovy = hostAppGradleRoot.childFile('build.gradle');
  final File buildKotlin = hostAppGradleRoot.childFile('build.gradle.kts');

  if (buildGroovy.existsSync() && buildKotlin.existsSync()) {
    throwToolExit('Both build.gradle and build.gradle.kts exist. Only once can be used.');
  }

  if (buildKotlin.existsSync()) {
    return buildKotlin;
  }

  if (buildGroovy.existsSync()) {
    return buildGroovy;
  }

  throwToolExit("Neither build.gradle nor build.gradle.kts exist. This is an error");
}
```
Repository: go
Issue: x/build: `darwin-amd64` LUCI builders are sometimes too slow
Labels: OS-Darwin,Builders,NeedsInvestigation

```
#!watchflakes
default <- builder ~ `(gotip|go1\.\d\d)-darwin-amd64` && (`test timed out` || `SIGQUIT` || `context deadline exceeded` || `command exceeded time limit` || status == "ABORT")
```

### Go version

aba18d5b6785d501996b475d58a05cc26707d370

### Output of `go env` in your module/workspace:

```shell
N/A
```


### What did you do?

Check status of https://ci.chromium.org/p/golang/g/go-gotip/console.

### What did you see happen?

Multiple failures involving timeouts on the `darwin-amd64_13` builder:
- http://ci.chromium.org/b/8759366472105663201
- http://ci.chromium.org/b/8759455104674769409

### What did you expect to see?

No timeouts: `go test -short cmd/go` takes <20s to run locally, so either the builders should be faster, or they should set a `GO_TEST_TIMEOUT_SCALE` that is long enough to reliably run the tests.

The only timeouts on the builders should be for (a) true deadlocks, and (b) tests that take a similarly long time (approaching 3 minutes) when run locally.
Repository: go
Issue: crypto/x509: relax boringcrypto certificate key size restrictions given the ongoing FIPS 140-3 validation
Labels: NeedsInvestigation

### Go version

go1.21.5

### Output of `go env` in your module/workspace:

```shell
N/A
```


### What did you do?

When `GOEXPERIMENT=boringcrypto` is set and fips is enforced using:
```go
import _ "crypto/tls/fipsonly"
```

The standard library relies on `boringAllowCert` when verifying the validity of certificates:
https://github.com/golang/go/blob/master/src/crypto/x509/boring.go#L19-L39

As a result, certificates with RSA keys starting from 5K up to 16K (this range is specific to my use case) fail.

Given the fact that Go was recently updated to use the 20220614 BoringCrypto module based on a pending FIPS 140-3 validation:

- https://go-review.googlesource.com/c/go/+/549695
- https://go-review.googlesource.com/c/go/+/549975

FIPS 140-3 IG section C.F [1] allows FIPS validations to make use of sizes other than 2048, 3072, and 4096, and the current restriction in the above-linked `boringAllowCert` function dates from earlier FIPS certificates that predate this new guidance and required only specific sizes.

Does the pending FIPS validation allow other (larger) RSA key sizes, and if so, will Go be adjusting the restriction to permit those larger sizes?

[1] https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf

### What did you see happen?

```
tls: failed to verify certificate: x509: certificate specifies an incompatible key usage
```

### What did you expect to see?

A somewhat naive expectation is to see relaxation in size checks given the current FIPS 140-3 guidance and pending validation.
Repository: godot
Issue: Godot always associates itself to the wrong monitor and font are hard to read
Labels: bug,platform:macos,topic:rendering,topic:editor,topic:porting,confirmed,topic:gui

### Tested versions

4.2.1 stable but I believe I've seen this for some time. Not exactly sure since I was not using my external display the whole time.

### System information

MacBook Pro M1 Sonoma 14.2.1 - 4.2.1 stable - Forward+

### Issue description

If I am using Godot when I have my MacBook Pro plugged into my Apple monitor it seems to have a strange resolution. Probably it thinks it's being displayed on the MacBook Pro's screen and not the Display which is a different resolution.

Note: It's not like I moved it from one screen to another. The main screen I use is the external display and Godot displays there from the start. Though if I go into project settings it actually displays on my Macbook's screen while my main Godot window is on the external display.

### Steps to reproduce

Open a project on a Mac with two monitors which have a different resolution. Move the Godot screen to the second monitor. 

Workaround: Going into fullscreen mode seems to make it understand the actual resolution of the screen it's being displayed on

### Minimal reproduction project (MRP)

I don't think I need to provide that in this case.