sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Button can grab focus when window is out of focus, even if tree is paused
Labels: bug,topic:gui

### Godot version

3.5 beta3

### System information

linux

### Issue description

I seem to have related issues:
- when paused is true, buttons can grab focus or be hovered
- when paused is true and another window has focus, buttons can still grab focus or be hovered
- when paused is false and another window has focus, buttons can be pressed and emit signals (and still grab focus or be hovered)

The inputs to change focus or press buttons are made with a controller




### Steps to reproduce

Launch the project, Alt-TAB to another window, make sure you can see the buttons below, use dpad to move through the buttons

### Minimal reproduction project

[test_paused_out_focus.zip](https://github.com/godotengine/godot/files/9033697/test_paused_out_focus.zip)
Repository: rust
Issue: Better error message when asking for derive when there are already derive macros
Labels: A-diagnostics,T-compiler

Hi !

I just notice something that looks like a subtlety than anything else, but I still created this issue.
Consider the following program:

```rust
#[derive(Copy, Clone)]
struct Single;

fn main() {
	let a = Single;
	println!("coucou {:?}", a);
}
```
A snippet on the playgroud: [Link to Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=acf2c1194991f9854a9b384f1d8935e5)

This code obviously doesn't compile, but the error message could be better (in my opinion). The current error message is:

```console
error[E0277]: `Single` doesn't implement `Debug`
 --> main.rs:7:26
  |
6 |     println!("coucou {:?}", a);
  |                             ^ `Single` cannot be formatted using `{:?}`
  |
  = help: the trait `Debug` is not implemented for `Single`
  = note: add `#[derive(Debug)]` to `Single` or manually `impl Debug for Single`
  = note: this error originates in the macro `$crate::format_args_nl` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider annotating `Single` with `#[derive(Debug)]`
  |
2 | #[derive(Debug)]
  |

error: aborting due to previous error

For more information about this error, try `rustc --explain E0277`.
```

Maybe it could look like that:
```console
error[E0277]: `Single` doesn't implement `Debug`
 --> main.rs:7:26
  |
6 |     println!("coucou {:?}", a);
  |                             ^ `Single` cannot be formatted using `{:?}`
  |
  = help: the trait `Debug` is not implemented for `Single`
  = note: add `#[derive(Debug)]` to `Single` or manually `impl Debug for Single`
  = note: this error originates in the macro `$crate::format_args_nl` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider annotating `Single` with `#[derive(Debug)]`
  |
1 | #[derive(Copy, Clone, Debug)]
  |                       ^
  |                       ++++++
  |

error: aborting due to previous error

For more information about this error, try `rustc --explain E0277`.
```

My point is, maybe this error message could take into account the fact that deriving traits is already present, instead of stacking them... Another way to look at this is that it depends of the developer style, then this error message couldn't display both versions...
Repository: flutter
Issue: [Web] - Space Key on Physical keyboard scrolls the list on mobile devices
Labels: framework,f: scrolling,has reproducible steps,P2,found in release: 3.0,found in release: 3.1,team-framework,triaged-framework

In `super_editor` we ran into the problem in #74191, whereby the `space` bar on mobile causes the page scroll, rather than insert a space.

The solution that we had to use was to block `Shortcuts` behavior: https://github.com/superlistapp/super_editor/pull/665

`super_editor` doesn't use `Shortcuts` and therefore I believe it's an inappropriate solution for `super_editor` to introduce arbitrary interventions into the `Shortcuts` system. This seems to be either a bug or a poor architecture within `Shortcuts`. 

Is there a way to obtain expected `space` bar behavior without adding `Shortcuts` references to our widget tree? If not, I think Flutter should update the `Shortcuts` architecture to make that possible.
Repository: PowerToys
Issue: [PT Run] Show some/common info/config, with needing to expand plugin. 
Labels: Idea-Enhancement,Product-PowerToys Run,Product-Settings,Needs-Triage

### Description of the new feature / enhancement

I would like to be able see some common data like the direct activation command and if the results show in the global results, without having to open every single enabled plug.

Mockup
![image](https://user-images.githubusercontent.com/4396667/177018996-18c25c94-3f1e-4ba0-969b-3b4e2d52b8d9.png)

### Scenario when this would be used?

If you want to pick a different "direct activation command", you need to open every other one, since we don't tell you which are already in use. 

Perhaps, these two settings (direct activation command and global results), should not be hidden under the expand? Only non-standard options for each plugin need to be under there?

### Supporting information

_No response_
Repository: rust
Issue: `Self` keyword is documented as `SelfTy`
Labels: T-rustdoc,C-bug

This should just be `Self`. "`SelfTy`" is [not a keyword](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1bf26a96870a6e5030045bf492b3de8a).

The doc page cannot be https://doc.rust-lang.org/nightly/std/keyword.Self.html on a case-insensitive host because that will conflict with https://doc.rust-lang.org/nightly/std/keyword.self.html.

IMHO: the ideal would be https://doc.rust-lang.org/nightly/std/keyword.Self%20(type).html as the URL, and to properly display the keyword as `Self`.

-----

https://doc.rust-lang.org/nightly/std/keyword.SelfTy.html

![rustdoc keywords list](https://user-images.githubusercontent.com/5992217/177019111-2366b46f-7286-4260-ad96-50748eae9be9.png)

![rustdoc keyword page for `SelfTy`](https://user-images.githubusercontent.com/5992217/177019126-f459995c-de11-43cc-84fe-673174ad0a24.png)

@rustbot modify labels +A-rustdoc
Repository: rust
Issue: Conflicting impls where one type is an associated type should provide a note that another crate could define the associated type to make the impls overlap
Labels: A-diagnostics,T-compiler

<!--
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.

If you cannot produce a minimal reproduction case (something that would work in
isolation), please provide the steps or even link to a repository that causes
the problematic output to occur.
-->

Given the following code: [[playground]](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=ac0ec13c782fd22f9efa6a20aef81f5a)

```rust
pub trait Trait<X> {}

impl<X> Trait<X> for X::Owned
where
    X: ToOwned,
{}

impl<X> Trait<X> for &X
{}

```

The current nightly (2022-07-01) output is:

```
error[[E0119]](https://doc.rust-lang.org/nightly/error-index.html#E0119): conflicting implementations of trait `Trait<_>` for type `&_`
 --> src/lib.rs:8:1
  |
3 | impl<X> Trait<X> for X::Owned
  | ----------------------------- first implementation here
...
8 | impl<X> Trait<X> for &X
  | ^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `&_`
```

<!-- The following is not always necessary. -->
Ideally the output should look like:

```
error[[E0119]](https://doc.rust-lang.org/nightly/error-index.html#E0119): conflicting implementations of trait `Trait<_>` for type `&_`
 --> src/lib.rs:8:1
  |
3 | impl<X> Trait<X> for X::Owned
  | ----------------------------- first implementation here
...
8 | impl<X> Trait<X> for &X
  | ^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `&_`
  | 
  = note: another crate could provide some `X: ToOwned<Owned=X>`
```

<!--
If the problem is not self-explanatory, please provide a rationale for the
change.
-->

I've spent multiple hours trying to figure out how this impl could be overlapping on at least two separate occasions. I'd like to prevent that from happening again 🙂

(An *even more fun* case is `impl<X> Trait<&X> for &&X`, as the conflicting `&X: ToOwned<Owned=&&X>` can only exist with a coherence-impacting proof that `X: !Clone`.)

<!--
If dramatically different output is caused by small changes, consider also
adding them here.

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. The output might also be
different depending on the Edition.
-->
Repository: rust
Issue: `negative_impls` doesn't seem to agree with `const_trait_impl`
Labels: T-compiler,C-bug,requires-nightly,F-negative_impls

<!--
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.
-->

```rust
#![feature(const_trait_impl)]
#![feature(auto_traits, negative_impls)]

auto trait NotPartialOrd {}
impl<T: ~const PartialOrd> const !NotPartialOrd for T {}

const fn foo<T: ~const PartialOrd>(_t: &T) { }
const fn bar<T: ~const NotPartialOrd>(_t: &T) { }

const b1: () = foo(&4_u32);
const b2: () = bar(&4_u32);

```

This fails compilation on both consts; the first because `the trait ~const PartialOrd is not implemented for u32 (note: the trait PartialOrd is implemented for u32, but that implementation is not const)`, and the second because `the trait bound u32: ~const NotPartialOrd is not satisfied`. 

I tried `with_negative_coherence` too, but it did not impact this test case.

### Meta
[Playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=014b9e2e4e72a9fcb66f714a69c248a0)

```shell
$ rustc --version --verbose`:
rustc 1.64.0-nightly (c80c4b8fd 2022-06-26)
binary: rustc
commit-hash: c80c4b8fdcf3da69cd483e2fec172c9b1f95842c
commit-date: 2022-06-26
host: x86_64-unknown-linux-gnu
release: 1.64.0-nightly
LLVM version: 14.0.5
```
Repository: node
Issue: `SourceTextModule`: Using dynamic imports while passing `cachedData` throws `TypeError: Invalid host defined options`
Labels: confirmed-bug,vm,v8 engine

### Version

v18.4.0

### Platform

Linux arch-linux 5.18.8-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC Wed, 29 Jun 2022 23:03:10 +0000 x86_64 GNU/Linux

### Subsystem

`node:vm`

### What steps will reproduce the bug?

> Needs `--experimental-vm-modules` flag
```js
import { SourceTextModule } from 'node:vm'

async function linker() {
  const fakeMod = new SourceTextModule('console.log("Hello, world!")')
  await fakeMod.link(() => {})
  await fakeMod.evaluate()
  return fakeMod
}

const code = 'import("")'
const modA = new SourceTextModule(code, {
  importModuleDynamically: linker,
})

const modB = new SourceTextModule(code, {
  importModuleDynamically: linker,
  cachedData: modA.createCachedData(),
})

await modA.link(linker)
await modA.evaluate() // logs "Hello, world!"

await modB.link(linker)
await modB.evaluate() // TypeError: Invalid host defined options
```

### How often does it reproduce? Is there a required condition?

100% of the time when passing `cachedData`

### What is the expected behavior?

Dynamic imports works as expected.

### What do you see instead?

```
vm:module(0):1
import("")
^

TypeError: Invalid host defined options
    at vm:module(0):1:1
    at SourceTextModule.evaluate (node:internal/vm/module:226:23)
    at file:///home/chooks/code/play/test.js:24:12
```

### Additional information

- Works when `cachedData` is not passed.
- Works when using static imports.
- Breaks even if returned the same reference to `fakeMod`.
Repository: pytorch
Issue: `hardshrink` gives wrong gradient for 0 input when `lambd` is 0.
Labels: module: autograd,triaged,module: edge cases

### 🐛 Describe the bug

`hardshrink` gives wrong gradient for 0-valued input when `lambd` is 0.

```python
import torch

def fn(input):
    fn_res = input.hardshrink(lambd=0.0)
    return fn_res

input = torch.tensor([0.], dtype=torch.float64, requires_grad=True)
torch.autograd.gradcheck(fn, (input))
```

```
torch.autograd.gradcheck.GradcheckError: Jacobian mismatch for output 0 with respect to input 0,
numerical:tensor([[1.]], dtype=torch.float64)
analytical:tensor([[0.]], dtype=torch.float64)
```

Based on the definition of `hardshrink`, it should be `f(x) = x` if `lambd=0`. Thus, it's supposed to return 1 as the gradient when input is 0.

### Versions

pytorch: 1.11.0

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
Repository: pytorch
Issue: `torch.renorm` gives wrong gradient for 0-valued input when `p` is even and `maxnorm=0`.
Labels: module: autograd,triaged,module: edge cases

### 🐛 Describe the bug

`torch.renorm` gives wrong gradient for 0-valued input when `p` is even and `maxnorm=0`.

```py
import torch

def fn(input):
    p = 2
    dim = -1
    maxnorm = 0
    fn_res = torch.renorm(input, p, dim, maxnorm, )
    return fn_res
input = torch.tensor([[0.1, 0.], [0., 0.]], dtype=torch.float64, requires_grad=True)

torch.autograd.gradcheck(fn, (input))
```

```
GradcheckError: Jacobian mismatch for output 0 with respect to input 0,
numerical:tensor([[0., 0., 0., 0.],
        [0., 0., 0., 0.],
        [0., 0., 0., 0.],
        [0., 0., 0., 0.]], dtype=torch.float64)
analytical:tensor([[1., 0., 0., 0.],
        [0., 1., 0., 0.],
        [0., 0., 1., 0.],
        [0., 0., 0., 1.]], dtype=torch.float64)
```

Because `p=2` and `maxnorm=0`, this function should be `f(x) = 0` for every element. Therefore, it should return 0 as the gradient.

### Versions

pytorch: 1.11.0

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
Repository: vscode
Issue: Extensions want to add VSCODE_GIT_IPC_HANDLE 
Labels: git,under-discussion

I am seeing this issue:
https://github.com/microsoft/vscode/issues/102727

in 1.68.1

Note, in my setup:
- I work with Remote containers
- I have setup devcontainer.json to have the setting: `"remote.containers.gitCredentialHelperConfigLocation": "none"`

This happens every time I "reopen" VSCode when I closed it with the window connected to the Container open.

There should be no need for VSCode to configure Git IPC Handle in this case.
Repository: next.js
Issue: [NEXT-696] New middleware slows down routing in production
Labels: bug,linear: next

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 10 Pro   
Binaries:
  Node: 16.14.2
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant packages:
  next: 12.2.0
  eslint-config-next: 12.2.0
  react: 18.2.0
  react-dom: 18.2.0

### What browser are you using? (if relevant)

Chrome 103.0.5060.66

### How are you deploying your application? (if relevant)

next start

### Describe the Bug

New middleware slows down on routing in production (dev is okay), example code that slows down:

```js
import { NextResponse } from 'next/server';

const Middleware = (req) => {
  /** To lower case redirect. */
  if (req.nextUrl.pathname === req.nextUrl.pathname.toLowerCase())
    return NextResponse.next();

  return NextResponse.redirect(new URL(req.nextUrl.origin + req.nextUrl.pathname.toLowerCase()));
};

export default Middleware;
```

### Expected Behavior

Work as expected with no slow down, with previous `_middleware.js` there was no problem

### To Reproduce

Create `middleware.js` file under root folder and use code from example

<sub>[NEXT-696](https://linear.app/vercel/issue/NEXT-696/new-middleware-slows-down-routing-in-production)</sub>
Repository: godot
Issue: editor still unresponsive after minimizing Pop-Ups
Labels: bug,topic:editor,usability

### Godot version

v4.0.alpha11.official [afdae67cc]

### System information

Ubuntu (Zorin Os)

### Issue description

After minimizing Pop-Ups the editor is still  unresponsive.
Closing the Pop-Up fixes the issue.
It can be very irritating though.
The minus (the minimize icon) should be unclickable
### Steps to reproduce
Create a new project
Open the Editor Settings (or any other Pop-Up-Window)
Click the little minus in the top left corner of the window to minimize it


### Minimal reproduction project

_No response_
Repository: godot
Issue: Vulkan: SDFGI has artifacts on off-axis geometry due to bias being too low
Labels: discussion,topic:rendering,topic:3d

### Godot version

4.0 Alpha 11

### System information

Windows 10, GTX1080, i7 6700

### Issue description

Geometry that is not flat on the X, Y or Z axes will create noticeable lighting artefacts and sudden unrealistic shifts in lighting.
This occurs with geometry that is modeled with polygons at any angle other than flat in X, Y, or Z in global space, and any objects that are rotated to become off-axis.

This is reduced but not resolved by reducing Cascades count and increasing Min Cell Size. These adjustments simply reduce the frequency but they still persist on a large scale.
VoxelGI can not be used since it has its own (arguably more severe) problems with off-axis geometry.

On-axis geometry:
![SDFGI_AxisArtifactsBug01](https://user-images.githubusercontent.com/70243134/177041878-98681c54-ce92-4f4d-98f0-066053628721.JPG)

Off-axis geometry. Notice the extreme bright spots, sharp tonal shifts and strongly occluded corners:
![SDFGI_AxisArtifactsBug02](https://user-images.githubusercontent.com/70243134/177041883-ff509dab-85a5-411b-9062-16953e047a39.JPG)
![SDFGI_AxisArtifactsBug03](https://user-images.githubusercontent.com/70243134/177041885-f4fc496e-1eac-4c04-8faf-a7cfdf143f1a.JPG)



### Steps to reproduce

- Import any geometry that is modeled with angular polygons that don't perfectly align with the X, Y and Z axes.
- Alternatively, rotate a cubic model so it is out of alignment with the global space.
- Example geometry is provided in the example.

### Minimal reproduction project

[SDFGI_OffAxisArtifactsBug.zip](https://github.com/godotengine/godot/files/9034853/SDFGI_OffAxisArtifactsBug.zip)
Repository: godot
Issue: Vulkan: SDFGI light occlusion results in sudden deep blacks
Labels: enhancement,discussion,topic:rendering,topic:3d

### Godot version

4.0 Alpha 11

### System information

Windows 10, GTX1080, i7 6700

### Issue description

SDFGI will regularly produce noticeable pitch-black patches in areas of occlusion.
These are persistent regardless of setting but can be slightly reduced by decreasing Cascades and increasing Min Cell Size.
They occur regardless of intersecting or watertight geometry, but seem most egregious with intersecting geometry that is organic/not built with faces at 90 degree angles that align with global space.

The effect is highly noticeable in detailed PBR scenes since the deep blacks will also affect normal maps, creating many spots of extreme contrast. This might be resolved if occluded areas had softer transitions or probes inside watertight geometry were disregarded or took less priority than those outside of objects.

All shots taken at default SDFGI settings.
![SDFGI_BlackArtifacts01](https://user-images.githubusercontent.com/70243134/177042794-933bfe56-0101-4afa-b068-dc37f2d0b8a2.JPG)
![SDFGI_BlackArtifacts02](https://user-images.githubusercontent.com/70243134/177042805-ea3c272d-c277-43ec-b887-9db865ac5346.JPG)
![SDFGI_BlackArtifacts03](https://user-images.githubusercontent.com/70243134/177042809-9cec1314-7374-482a-92b5-c616e927e2e3.JPG)
![SDFGI_BlackArtifacts04](https://user-images.githubusercontent.com/70243134/177042813-b83e80b0-6256-4db4-af9f-47f0671e9146.JPG)
![SDFGI_BlackArtifacts05](https://user-images.githubusercontent.com/70243134/177042815-b4cae771-a3bf-4d3c-b38a-b5356ae5357d.JPG)



### Steps to reproduce

Should be noticeable in most scenes but is most visible on PBR materials with normal maps.

### Minimal reproduction project
[HERE](https://www.dropbox.com/s/545qr4mgqco58ds/SDFGI_OcclusionArtifacts.zip?dl=0)
Repository: storybook
Issue: Enable Embroider (Ember's new build system)
Labels: feature request,ember

[Embroider](https://github.com/embroider-build/embroider) is ember's new build system.

On a high level overview: Embroider moves ember from its proprietary build system to allow usage of bundlers from the wider js ecosystem (webpack by default - but also vite implementation is being worked on, etc.).

As such, `@storybook/ember` needs an adjustment to load those assets (or maybe `@storybook/ember-cli-storybook`?) to load those new assets.

hokulea/hokulea#114 contains the PR to hokulea which shows the changes need to made for an ember app.
Repository: TypeScript
Issue: Method return type cannot be used as discriminant
Labels: Suggestion,Awaiting More Feedback

# Bug Report

When having objects with methods that return a boolean, the types don't get narrowed when checked, contrary to properties.

### 🔎 Search Terms

type guard, narrowing

### 🕗 Version & Regression Information

- This is the behavior in every version I tried, and I reviewed the FAQ for entries about type narrowing with methods returning strict literals in the types

### ⏯ Playground Link

[Playground link with relevant code](https://www.typescriptlang.org/play?ts=4.8.0-dev.20220703#code/MYGwhgzhAEDKD2BbApgHgCoD5oG8BQ00ADgK4BGIAlsNAE7JgAm8AdiAJ7QBuYIJyALmjoA3AWLkqNYKwgAXWiWBz4tABQ8+g4QEpc4wnIAWlCADpN-aAF5uvfmMIBfPONIVq0UwhRqdQhSscOmQ5EloWaEDkEWgXFzxQSBgAOVZkfUJ3KS8IH2Q-IQAzXggM4PowiOgSkDLY+Nc5diIMgHkiOUpWDGxbfN7oAB9oNJYY10ZkJPpoGRZ5aAAPIQ6unvlaShYAc0wxPEoi6DUls28kAp09fEIzywmnIA)

### 💻 Code

```ts
class Some<T> {
  public readonly value: T;
  public constructor(value: T) {
    this.value = value;
  }

  public isSome(): true { return true; }
}

class None {
  public isSome(): false { return false; }
}

type Option<T> = Some<T> | None;

declare const x: Option<string>;

if (x.isSome()) {
  x.value;
  // Property 'value' does not exist on type 'Option<string>'.
  //   Property 'value' does not exist on type 'None'.(2339)
}
```

### 🙁 Actual behavior

`isSome()` does not narrow the type from `Option<string>` to `Some<string>` unless the return type of `isSome()` in either or both classes are typed as `this is Some<T>`:

| `Some#isSome()`   | `None#isSome()`     | Narrows? |
| :---------------: | :-----------------: | :------: |
| `true`            | `false`             | ❌      |
| `this is Some<T>` | `false`             | ✅      |
| `true`            | `this is Some<any>` | ✅      |
| `this is Some<T>` | `this is Some<any>` | ✅      |

This behaviour is not consistent to the one when typed properties (`public some: true = true`/`public some: false = false`) are used, where the type narrowing system works perfectly fine.

### 🙂 Expected behavior

`isSome()` would be sufficient to narrow `Option<string>` to `Some<string>`, as is the case with regular properties ([Playground link](https://www.typescriptlang.org/play?ts=4.8.0-dev.20220703#code/MYGwhgzhAEDKD2BbApgHgCoD5oG8BQ00ADgK4BGIAlsNAE7JgAm8AdiAJ7QBuYIJyALmjoA3AWLkqNCEkHQALrX7QAvAqXIxhUhWrRgrCIpLB58WgAoefOegCUucYXkALShAB015Wu+bxAL54QXigkDAAcqzIjtqSejIoQgBmvBAxaqkg6WIh8uxEMQDyRPKUrBjYaggoldAAPtBRLP54jMhh9PqG8tAAHkIlZRVGtJQsAOaYYniUydAWfR6JyA74hEt+uUA)). In short, the first case in the aforementioned table should work.