sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: PowerToys
Issue: PowerToys Run: Shortcut reminders above the bar
Labels: Idea-Enhancement,Product-PowerToys Run,Needs-Triage

### Description of the new feature / enhancement

PowerToys Run can do a lot of things (which is great!), hence to filter out the results you put in the shortcuts to trigger only certain plugins (which is also great!). 

The problem is that there are now lots of plugins with lots of shortcuts to remember. It would be nice if **small shortcut reminders could be displayed above the search bar**. 

These would be the shortcuts we've chosen for each plugin (not the defaults), and if the results of a query had several **types** of results, it would display the shortcuts for all those displayed results

For example, in this query result list: 
![image](https://user-images.githubusercontent.com/3929975/182039072-614a4eb6-a45d-453f-b2dd-fc602f7559d9.png)
above the bar it would display:
_`Shortcuts: . for Programs, < for Window Walker`_
and this bar would update to only show the relevant shortcut as I highlight each result one by one with my mouse/keyboard

It sounds like a niche feature, but it helps become a better power user. And having to navigate all the way to the Settings > PowerToys Run> Plugins> each plugin is very tedious when you forget them

### Scenario when this would be used?

Every time a query is typed in the PowerToys Run input box

### Supporting information

_No response_
Repository: godot
Issue: Crash when opening project after converting it with `--convert-3to4`
Labels: bug,topic:editor,needs testing

### Godot version

4.0 alpha13

### System information

MacOS Monterey, Version 12.4, Apple M1

### Issue description

After running the `--convert-3to4` with Godot Version 4.0 alpha13 I attempted to open my game but Godot instantly crashed. I have attached the crash report.
[godot-crash.txt](https://github.com/godotengine/godot/files/9229466/godot-crash.txt)


### Steps to reproduce

It is difficult to reproduce with a new project and my current project is private and cannot be shared here. 

### Minimal reproduction project

_No response_
Repository: rust
Issue: Macro spans cause erroneous suggestions
Labels: A-macros,T-compiler,A-suggestion-diagnostics,D-invalid-suggestion

Macro spans cause suggestions that, once applied, break other code.

```rust
struct X;

struct Wrapper<T>(T);

macro_rules! m {
    () => { X };
}

fn main() {
    let _: Wrapper<X> = m!();
    let _: X = m!();
}
```

Suggests:
```
help: try wrapping the expression in `Wrapper`
   |
6  |     () => { Wrapper(X) };
   |             ++++++++ +
```

Once applied, causes this error:
```
error[E0308]: mismatched types
  --> src/main.rs:6:13
   |
6  |     () => { Wrapper(X) };
   |             ^^^^^^^^^^ expected struct `X`, found struct `Wrapper`
...
11 |     let _: X = m!();
   |            -   ---- in this macro invocation
   |            |
   |            expected due to this
   |
   = note: expected struct `X`
              found struct `Wrapper<X>`
```

This has some considerations:
1. We could suppress this suggestion if it comes from a macro, which "fixes" this issue, but ideally we'd be suggesting "`Wrapper(m!())`" in the first case.
2. This is a general issue -- while we could fix it in this one case, that's more of a bandaid and I could probably come up with 5 other cases similar to this.
3. Sometimes changing the macro _is_ the correct solution.
Repository: rust
Issue: Rustc fails to infer appropriately general `Fn*` trait implementation in the face of complex HRTBs with GATs
Labels: A-lifetimes,A-closures,C-bug,T-types,A-GATs,A-higher-ranked

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code:

```rust
#![feature(generic_associated_types)]
pub trait Func<'a, T> {
    type Output;
    fn invoke(&mut self, x: T) -> Self::Output;
}
impl<'a, T, U, F> Func<'a, T> for &'a mut F
where
    F: FnMut(T) -> U,
{
    type Output = U;
    fn invoke(&mut self, x: T) -> Self::Output {
        self(x)
    }
}
trait Foo {
    type Bar<'a>
    where
        Self: 'a;
    fn test<F>(f: F)
    where
        for<'a> &'a mut F: Func<'a, Self::Bar<'a>>;
}

impl Foo for () {
    type Bar<'a> = &'a ();
    fn test<F>(mut f: F)
    where
        for<'a> &'a mut F: Func<'a, Self::Bar<'a>>,
    {
        (&mut f).invoke(&());
    }
}
fn main() {
    let f: fn(&()) -> &() = |t| t;
    <()>::test(f); //works
    <()>::test(|t| t); //error
}
```

I expected to see this happen: Code compiles without errors.

Instead, this happened: 

```
   Compiling playground v0.0.1 (/playground)
error: implementation of `FnOnce` is not general enough
  --> src/main.rs:33:5
   |
33 |     <()>::test(|t|t);  //error
   |     ^^^^^^^^^^ implementation of `FnOnce` is not general enough
   |
   = note: closure with signature `fn(&'2 ()) -> &()` must implement `FnOnce<(&'1 (),)>`, for any lifetime `'1`...
   = note: ...but it actually implements `FnOnce<(&'2 (),)>`, for some specific lifetime `'2`

error: could not compile `playground` due to previous error
```
[Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=a37e7a432f252b749abc561ead74e4f7)

The compiler needs closures to be explicitly coerced into a general enough type for the provided trait bounds to work. It's not the end of the world, because I can always use trait objects, but it's definitely an ergonomic issue. Also, it works [just fine](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=d8513f9ede5cdb2811386e7fa4608163) if you use a non-generic associated type.


### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

Playground version:
```
1.64.0-nightly

(2022-07-30 0f4bcadb46006bc484da)
```
Repository: godot
Issue: Rotating Camera2D doesn't stay on target
Labels: bug,topic:core,topic:2d

### Godot version

3.4.4

### System information

Ubuntu 22.04

### Issue description

With [`Camera2D`](https://docs.godotengine.org/en/stable/classes/class_camera2d.html) [`rotating`](https://docs.godotengine.org/en/stable/classes/class_camera2d.html#class-camera2d-property-rotating) enabled, when rotating the player (the parent of the `Camera2D`) the camera should simply rotate with the target. However, sometimes the camera's position shifts drastically:
![CameraRotationBug](https://user-images.githubusercontent.com/9253928/182040635-9aa97cb5-599b-43e1-8ba0-7fc116ff015b.gif)



### Steps to reproduce

Make a `Camera2D` a child of your player. Make the camera `current` and enable `rotating`. Rotate the player and watch the camera position change drastically.
**Note:** I've only seen this happen with camera limits set. However in the MRP the camera limits are always outside the camera boundaries; so they shouldn't affect it.

### Minimal reproduction project

[CameraRotatingBug.zip](https://github.com/godotengine/godot/files/9229524/CameraRotatingBug.zip)
Repository: godot
Issue: Vulkan: viewport flashes white when being resized with volumetric fog enabled
Labels: bug,topic:rendering,confirmed,topic:3d

### Godot version

v4.0.alpha13.official [59dcddc45]

### System information

Fedora Linux 36 (Workstation Edition), Vulkan Clustered, GTX 1660

### Issue description

When the viewport is being resized with VL fogs enabled, it flashes white for about a single frame.

(**Epilepsy warning**)

https://user-images.githubusercontent.com/25323231/182040843-e52dc349-d503-49a5-aeb7-d13e78fdc5e9.mp4



### Steps to reproduce

1. Enable volumetric fog
2. Resize viewport

### Minimal reproduction project

_No response_
Repository: puppeteer
Issue: [Bug]: request.postData() is undefined when request sent via navigator.sendBeacon
Labels: bug,upstream,confirmed,P3

### Bug description

Steps to reproduce the problem:


Run this sample: 
```
const puppeteer = require("puppeteer");

const html = `
<body>
<script>
const url = 'https://jsonplaceholder.typicode.com/todos';
const body = '{foo: "bar"}';

// bug: postData => undefined
navigator.sendBeacon("https://tracking.ott.yandex.net/v1/watch-batch", new Blob([JSON.stringify(body)],  {type : "application/json"}));

// correct: postData => {foo: "bar"}
fetch(url, {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
  },
  body: JSON.stringify({foo: "bar"})
});
</script>
</body>
`;

let browser;
(async () => {
    browser = await puppeteer.launch({headless: true});
    const [page] = await browser.pages();
    page.on('request', (req) => console.log(`
        resourceType: ${req.resourceType()}
        method: ${req.method()}
        postData:${req.postData()}
        ----------------------------------`));
    await page.setContent(html);
})()
    .catch(err => console.error(err))
    .finally(() => browser?.close());
```

Result:
 ```
        resourceType: other
        method: OPTIONS
        postData:undefined <= its correct because its OPTIONS request
        ----------------------------------

        resourceType: other
        method: OPTIONS
        postData:undefined <= its correct because its OPTIONS request
        ----------------------------------

        resourceType: ping
        method: POST
        postData:undefined <= its bug
        ----------------------------------

        resourceType: fetch
        method: POST
        postData:{"foo":"bar"} <= its correct
        ----------------------------------
```



### Puppeteer version

15.5

### Node.js version

16.9.1

### npm version

6.14.16

### What operating system are you seeing the problem on?

macOS

### Relevant log output

_No response_
Repository: rust
Issue: `OneSidedRange` should be an `unsafe trait`
Labels: T-libs-api,C-discussion

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code:

```rust
#![feature(one_sided_range)]
#![feature(slice_take)]

use core::ops::{OneSidedRange, RangeBounds, Bound};

struct X(usize, usize);

impl RangeBounds<usize> for X {
    fn start_bound(&self) -> Bound<&usize> {
        Bound::Included(&self.0)
    }
    
    fn end_bound(&self) -> Bound<&usize> {
        Bound::Excluded(&self.1)
    }
}

impl OneSidedRange<usize> for X {}

fn main() {
    let mut slice: &[_] = &['a', 'b', 'c', 'd'];
    assert_eq!(None, slice.take(X(5, usize::MAX)));
    assert_eq!(None, slice.take(X(0, 5)));
    assert_eq!(None, slice.take(X(0, 4)));
    let expected: &[char] = &['a', 'b', 'c', 'd'];
    assert_eq!(Some(expected), slice.take(X(0, 4)));
}
```

I expected to see this happen: Compiler error because this code did not acknowledge the invariants of `OneSidedRange` without an `unsafe` keyword.

Instead, this happened:

```
Compiling playground v0.0.1 (/playground)
    Finished dev [unoptimized + debuginfo] target(s) in 2.23s
     Running `target/debug/playground`
thread 'main' panicked at 'internal error: entered unreachable code', /rustc/0f4bcadb46006bc484dad85616b484f93879ca4e/library/core/src/slice/mod.rs:104:14
note: [run with `RUST_BACKTRACE=1` environment variable to display a backtrace](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021#)
```

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

Nightly channel (playground)
Build using the Nightly version: 1.64.0-nightly

(2022-07-30 0f4bcadb46006bc484da)

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Backtrace</summary>
<p>

The backtrace starts from here:

https://github.com/rust-lang/rust/blob/ed793d86daa67fb1117dd1db8da5da765e0fc773/library/core/src/slice/mod.rs#L104

</p>
</details>
Repository: vscode
Issue: Use Segoe UI Variable for Windows 11
Labels: ux,under-discussion

<!-- ⚠️⚠️ 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. -->
Please use [`Segoe UI Variable`](https://docs.microsoft.com/en-us/windows/apps/design/signature-experiences/typography "Windows 11 - Typography") (`Small` variant for tiny text, `Text` variant for normal text, `Display` variant for large text) and [`Segoe Fluent Icons`](https://docs.microsoft.com/en-us/windows/apps/design/signature-experiences/iconography "Windows 11 - Iconography"), as the default Sans-Serif font and the icon font - for icons used in Visual Studio Code - respectively, in Visual Studio Code (at least on Windows 11, and maybe Windows 10).  
  
+ [Fonts (Official)](https://docs.microsoft.com/en-us/windows/apps/design/downloads/#fonts "Download")  
+ [Fluent System Icons](https://github.com/microsoft/fluentui-system-icons "Libraries")
  
Thank you.
Repository: godot
Issue: Crash on freeing a node in `_exit_tree()` with `free()`
Labels: bug,topic:core,confirmed,crash

### Godot version

3.4.4.stable.arch_linux

### System information

Arch Linux, GLES 3.0, NVIDIA GeForce GTX 1050 Ti/PCIe/SSE2

### Issue description

While using **remove_child** to keep a node's instance available, using `free()` in the node's `_exit_tree()` function makes it crash, even while avoiding a stack overflow loop.

I need to use `free()` because **remove_child** removes the child from the tree without deleting it, but I sometimes need to delete it when it exits the tree, and `queue_free()` only works if the node is in the scene tree.

### Steps to reproduce

Have a parent node **P** with a child **C**, both with scripts.

In **P**'s script, keep a variable that contains **C**'s reference, and call remove_child(**C**)
```
onready var child = $child

func _ready():
	remove_child(child)
```

In **C**'s script, in _exit_tree(), free the instance : 
```
var deleting = false

func _exit_tree():
	if !deleting and !is_queued_for_deletion():
		deleting = true #necessary to not have a stack overflow
		free()
```


### Minimal reproduction project

[BugTest.zip](https://github.com/godotengine/godot/files/9229705/BugTest.zip)
Repository: rust
Issue: type annotation of closure args breaks borrow checking
Labels: A-lifetimes,A-closures,C-bug,T-types

This example compiles as expected:
```rust
fn main() {
    let mut list = vec![];
    let mut add_to_list = |name: _| {
        list.push(name);
    };
    
    let name = String::from("name1");
    add_to_list(&name);
}
```
but when a type annotation is added to the closure argument, it fails:
```diff
-    let mut add_to_list = |name: _| {
+    let mut add_to_list = |name: &str| {
```

## Workaround
Sometimes type annotation is necessary when type inference fails. :
```rust
fn main() {
    let mut list = vec![];
    let mut add_to_list = |name: _| { //ERROR type annotations needed
        if !name.is_empty() {
            list.push(name);
        }
    };
    
    let name = String::from("name1");
    add_to_list(&name);
}
```
In this case you can use this ugly hack to annotate the type in the closure body:
```diff
     let mut add_to_list = |name: _| {
+        let name: &str = name; // hack: annotate the type here to avoid rustc bug #xxx
         if !name.is_empty() {
```

## But why?
When rustc encounters such closure, It has to pick up one of these two types for the closure:
```rust
/// A closure that expects an argument of SOME specific lifetime, `'a`.
type FnSig1<'a> = dyn         FnMut(&'a str);

/// A closure that expects an argument of ANY lifetime.
/// Aka higher-ranked lifetime.
type FnSig2     = dyn for<'a> FnMut(&'a str);
```
We want the first one here but the compiler is not smart enough to infer this. Instead it follows a set of dumb rules[^1] that leads it to the second type, and then it fails when borrow-checking the closure for the same reason the following fails:
```rust
fn test<'a, 'b>(mut list: Vec<&'a str>, name: &'b str) {
    list.push(name);
}
```

There is a [promising work on a-mir-fomality](https://github.com/rust-lang/rfcs/pull/3216#issuecomment-1116369997) to make this inference smarter.

[^1]: simply if the lifetime appears in type annotation, it's inferred to be higher-ranked
Repository: godot
Issue: Can't access more than one "unsaved" script from scene tree dock after deleting scripts from res://
Labels: bug,topic:editor,usability

### Godot version

v4.0.alpha13.official [59dcddc45]

### System information

Pop!_OS 22.04 LTS

### Issue description

If a script is attached to a node in the scene tree dock, you can still open the script by clicking on the script icon next to the node, even if the script has been deleted from `res://`. It opens in the script editor with [unsaved] as its tab name.

If you have two nodes with different scripts attached and delete both scripts, only one (the first you click) can be accessed by clicking on its script icon. Clicking the script icon for the second node will switch tabs to the [unsaved] tab, but won't open a new one for the second script. The second script is still accessible by e.g. the inspector, or by saving the scene.

https://user-images.githubusercontent.com/61291296/182047870-f70b83bc-859c-448b-8772-985d432b4c8f.mp4

Also happens in `3.x`.

### Steps to reproduce

Create two nodes in the scene tree dock and attach a different script to each.
Delete the scripts from `res://`, then click on the script icons in the scene tree dock. Only one script will open.

### Minimal reproduction project

Create from empty project with above steps.
Repository: godot
Issue: Calling DateTime.Now property for the first time causes an unwanted delay
Labels: bug,platform:android,topic:porting,confirmed,topic:dotnet

### Godot version

v3.4.4.stable.mono.official [419e713a2]

### System information

Android

### Issue description

Tested on both Samsung SM-A127F (Android 12, arm64-v8a, physical device) and Google Pixel (Android 11 x86, emulated device)

As seen on the screenshot below, there's a quite big time difference between the two first calls on Android.
![image](https://user-images.githubusercontent.com/61241910/182102626-1e82dd36-fe4d-4d77-9ce8-bd2dd60db215.png)

There's no such a big delay on desktop though.
![image](https://user-images.githubusercontent.com/61241910/182102360-265f37ef-9de7-45aa-88cd-5f8ddd0c703a.png)


### Steps to reproduce

I ran into this issue while using DateTime.Now property in overridden _Process method.

### Minimal reproduction project

_No response_
Repository: rust
Issue: Unexpected higher-ranked lifetime error in GAT usage
Labels: A-lifetimes,C-bug,A-coroutines,A-async-await,AsyncAwait-Triaged,S-bug-has-test,T-types,A-GATs,A-higher-ranked

I tried this code:

```rust
#![feature(generic_associated_types)]
#![feature(type_alias_impl_trait)]

use std::future::Future;

pub trait FutureIterator: 'static {
    type Iterator;

    type Future<'s, 'cx>: Future<Output = Self::Iterator> + Send + 'cx
    where
        's: 'cx;

    fn get_iter<'s, 'cx>(&'s self, info: &'cx ()) -> Self::Future<'s, 'cx>;
}

trait IterCaller: 'static {
    type Future1<'cx>: Future<Output = ()> + Send + 'cx;
    type Future2<'cx>: Future<Output = ()> + Send + 'cx;

    fn call_1<'s, 'cx>(&'s self, cx: &'cx ()) -> Self::Future1<'cx>
    where
        's: 'cx;
    fn call_2<'s, 'cx>(&'s self, cx: &'cx ()) -> Self::Future2<'cx>
    where
        's: 'cx;
}

struct UseIter<FI1, FI2> {
    fi_1: FI1,
    fi_2: FI2,
}

impl<FI1, FI2> IterCaller for UseIter<FI1, FI2>
where
    FI1: FutureIterator + 'static + Send + Sync,
    for<'s, 'cx> FI1::Future<'s, 'cx>: Send,
    FI2: FutureIterator + 'static + Send + Sync,
{
    type Future1<'cx> = impl Future<Output = ()> + Send + 'cx
    where
        Self: 'cx;

    type Future2<'cx> = impl Future<Output = ()> + Send + 'cx
    where
        Self: 'cx;

    fn call_1<'s, 'cx>(&'s self, cx: &'cx ()) -> Self::Future1<'cx>
    where
        's: 'cx,
    {
        async {
            self.fi_1.get_iter(cx).await;
        }
    }

    fn call_2<'s, 'cx>(&'s self, cx: &'cx ()) -> Self::Future2<'cx>
    where
        's: 'cx,
    {
        async {
            self.fi_2.get_iter(cx).await;
        }
    }
}

fn main() {}

```

I expected to see this happen: both type declaration of `IterCaller::call_1`  and `IterCaller::call_2` pass the compiling

Instead, this happened:
```
error: higher-ranked lifetime error
  --> src/main.rs:60:9
   |
60 | /         async {
61 | |             self.fi_2.get_iter(cx).await;
62 | |         }
   | |_________^
```

### Meta
`rustc --version --verbose`:
```
rustc 1.64.0-nightly (f9cba6374 2022-07-31)
binary: rustc
commit-hash: f9cba63746d0fff816250b2ba7b706b5d4dcf000
commit-date: 2022-07-31
host: x86_64-unknown-linux-gnu
release: 1.64.0-nightly
LLVM version: 14.0.6
```
Repository: godot
Issue: Refresh button doesn't close out network connections
Labels: bug,discussion,topic:multiplayer

### Godot version

4.0 latest

### System information

Windows 10

### Issue description

Very Minor thing I saw and wasn't sure if it was a bug or not, when using the high-level multi-player and having a client connected to a server, if you use the 'restart' button connections to that server aren't terminated during the reload. Eventually these connections will timeout but it can cause unexpected behavior.

### Steps to reproduce

1. Create a client > server application, have the server output when clients connect / disconnect via signals. 
2. Hit the refresh / reload button in the godot editor on the server.

### Minimal reproduction project

_No response_
Repository: go
Issue: proposal: net: UnixListener: provide a way to get the `unlink` attribute
Labels: Proposal

<!--
Our proposal process is documented here:
https://go.dev/s/proposal-process
-->

https://github.com/golang/go/issues/11826 prevents listeners not created by the process to be unlinked.
https://github.com/golang/go/issues/13877 allows devs to explicitly specify whether go should unlink a listener

why does go design a setter `SetUnlinkOnClose` but not a getter? was there any concerns?
would golang provide a getter?