sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: animate.css
Issue: --animate-delay for each element?
Labels: to be verified

### Describe The Bug

From the docs, we can set 
`--animate-duration: 0.7s;`
per each element, but let me know if we able to do the same for 
`--animate-delay: 10s;`
right now it only works for :root

### Steps To Reproduce

Try to set for you single animated element this
```
--animate-duration: 0.7s;
--animate-delay: 10s;
```

### Expected Behavior

Animation will start in 10 seconds.

### Screenshots

![image](https://user-images.githubusercontent.com/4230282/170808691-824df78c-6635-4165-a20a-4e69e3fb2f56.png)


### Desktop

- iOs
- Chrome

### Smartphone

_No response_

### Additional Context

_No response_
Repository: storybook
Issue: Web components template should be using web components not lit-html
Labels: bug,cli,web-components

**Describe the bug**

When you try to create a web components storybook, I was surprised to see `lit-html` in there. While I do understand `lit-html` helps you in making web components, my expectation would be vanilla web components. Even svelte, and other libs can make web components, but thats not the expectation.

```
web components !== lit-html
```

And I don't want to be pulling in `lit-html` into my project when I am trying to use `web components`. I would rather expect a separate `lit` template for such a thing, which makes sense if your project is already using `lit`.

**To Reproduce**

Create a storybook project with type `web component` using storybook version 6.5

**System**

```
System:
    OS: macOS 12.3.1
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
  Binaries:
    Node: 16.14.0 - /usr/local/bin/node
    npm: 8.3.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 101.0.4951.64
    Firefox: 100.0.1
    Safari: 15.4
  npmPackages:
    @storybook/addon-actions: ^6.5.5 => 6.5.5 
    @storybook/addon-essentials: ^6.5.5 => 6.5.5 
    @storybook/addon-links: ^6.5.5 => 6.5.5 
    @storybook/builder-webpack5: ^6.5.5 => 6.5.5 
    @storybook/manager-webpack5: ^6.5.5 => 6.5.5 
    @storybook/web-components: ^6.5.5 => 6.5.5 
   
```

**Additional context**
Please use `HTMLElement` for `web component` template, thats the standard way of making web components
Repository: electron
Issue: [Bug]: macOS cannot open more than one fullscreen window on a display
Labels: platform/macOS,bug :beetle:,status/confirmed,has-repro-comment,17-x-y

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

17.4.4

### What operating system are you using?

macOS

### Operating System Version

12.4

### What arch are you using?

arm64 (including Apple Silicon)

### Last Known Working Electron version

_No response_

### Expected Behavior

Passing `fullscreen: true` to a window, opens the window as fullscreen.

### Actual Behavior

Fullscreen option is ignored for any window after the first window.

### Testcase Gist URL

_No response_

### Additional Information

Used the following `main.js` code:

```js
// Modules to control application life and create native browser window
const {app, BrowserWindow} = require('electron')
const path = require('path')

function createWindow () {
  // Create the browser window.
  const mainWindow = new BrowserWindow({
    width: 800,
    height: 600,
    fullscreen: true,
    webPreferences: {
      preload: path.join(__dirname, 'preload.js')
    }
  })

  // and load the index.html of the app.
  mainWindow.loadFile('index.html')

  const mainWindow2 = new BrowserWindow({
    width: 800,
    height: 600,
    fullscreen: true,
    webPreferences: {
      preload: path.join(__dirname, 'preload.js')
    }
  })

  // and load the index.html of the app.
  mainWindow2.loadFile('index.html')

  // Open the DevTools.
  // mainWindow.webContents.openDevTools()
}

// This method will be called when Electron has finished
// initialization and is ready to create browser windows.
// Some APIs can only be used after this event occurs.
app.whenReady().then(() => {
  createWindow()

  app.on('activate', function () {
    // On macOS it's common to re-create a window in the app when the
    // dock icon is clicked and there are no other windows open.
    if (BrowserWindow.getAllWindows().length === 0) createWindow()
  })
})

// Quit when all windows are closed, except on macOS. There, it's common
// for applications and their menu bar to stay active until the user quits
// explicitly with Cmd + Q.
app.on('window-all-closed', function () {
  if (process.platform !== 'darwin') app.quit()
})

// In this file you can include the rest of your app's specific main process
// code. You can also put them in separate files and require them here.
```
Repository: rust
Issue: Constant gets evaluated despite unsatisfied where clauses
Labels: I-ICE,T-compiler,A-const-eval,A-const-generics,F-generic_const_exprs,S-bug-has-test,requires-incomplete-features,WG-const-eval

This is the rustc side of https://github.com/rust-lang/project-const-generics/issues/37.
Repository: pytorch
Issue: Softmax, LogSoftmax are over parameterized
Labels: module: nn,triaged

### 🚀 The feature, motivation and pitch

The current implementation of Softmax and LogSoftmax for a K class output involves an [NxK] input tensor. This is over parameterized and leads to issues of identifiability. It would be worthwhile to include an implementation that only requires an input tensor [NX(K-1)] dimensionality.

### Alternatives

_No response_

### Additional context

_No response_

cc @albanD @mruberry @jbschlosser @walterddr @kshitij12345
Repository: rust
Issue: `x.py dist` followed by `x.py build compiler/rustc` causes rustc to be rebuilt
Labels: T-bootstrap,C-bug

Observed behavior:

```
$ ./x.py dist --stage 1
Updating only changed submodules
  Submodules updated in 0.00 seconds
Building rustbuild
    Finished dev [unoptimized] target(s) in 0.09s
Generating unstable book md files (x86_64-unknown-linux-gnu)
Building stage0 tool unstable-book-gen (x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.09s
Building stage0 tool rustbook (x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.11s
Rustbook (x86_64-unknown-linux-gnu) - unstable-book
Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.09s
Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage0 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.14s
Copying stage0 rustc from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Assembling stage1 compiler (x86_64-unknown-linux-gnu)
Documenting standalone (x86_64-unknown-linux-gnu)
Building rustdoc for stage1 (x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.10s
Documenting book redirect pages (x86_64-unknown-linux-gnu)
Documenting stage1 std (x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.15s
    Finished release [optimized] target(s) in 0.13s
    Finished release [optimized] target(s) in 0.16s
    Finished release [optimized] target(s) in 0.12s
    Finished release [optimized] target(s) in 0.12s
Documenting error index (x86_64-unknown-linux-gnu)
Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.09s
Copying stage1 std from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage1 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.13s
Copying stage1 rustc from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)

[...]

Build completed successfully in 0:04:52


$ ./x.py build --stage 1 compiler/rustc
Updating only changed submodules
  Submodules updated in 0.01 seconds
Building rustbuild
    Finished dev [unoptimized] target(s) in 0.09s
Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.09s
Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage0 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
   Compiling jemalloc-sys v0.5.0+5.3.0
^C  Building [=======================> ] 239/242: jemalloc-sys(build)          
```

Expected behavior: The build should use the cached artifacts 

Tested on b97bfc3b38a
Repository: TypeScript
Issue: Request: Narrow autocomplete suggestions of enum members to possible values only
Labels: Suggestion,Domain: Completion Lists,Awaiting More Feedback

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

## 🔍 Search Terms

<!--
  💡 Did you know? TypeScript has over 2,000 open suggestions!
  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.
  The "Common Feature Requests" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests

  Replace the text below:
-->

enum member autocomplete

## ⭐ Suggestion

Enum autocomplete only suggests compatible members when the expected type can be inferred

e.g. `obj.type === Enum.` only suggests members of `Enum` that are assignable to `typeof obj.type`

## 📃 Motivation

<!--
  If you were announcing this feature in a blog post, what's a short explanation that shows
  a developer why this feature improves the language?
-->

Using large enums involves wasting a lot of time typing out switch blocks and absurdly long `... === ... ||` chains

Now enums are very useful to quickly narrow object types by comparing them through `type: Enum;` properties, 
`obj.type === Enum.Foo` is a great shortcut to boilerplate `obj as Foo` casts or `obj is Foo` type narrowing functions

The issue is that often, `obj.type` is not just any of the 250 possible members of the Enum
sometimes `obj` is just `type MyNodes` which is an alias for `Foo | Bar | Leet`

Unfortunately when typing `obj.type === Enum.`, autocomplete shows all 250 Enum members.

Here the user must remember or lookup what the alias `type MyNodes` actually corresponds to before he is able to pick one of the 250 suggestions

Hence narrowing suggested members to the 3/250 compatible instead would greatly enhance workflow.

## 💻 Example

This would be oh so useful when writing AST programs, I am in the process of writing one and constantly bump into this:

[Playground Link](https://www.typescriptlang.org/play?#code/KYOwrgtgBAcg9gE2AFQJ4AdhQN4CgCQAggC7EBOAlgEZjFYC8UADADQEDKcEw8SAjFEZ82+ACJwAxgGEu3EMUFQATCM7dewAMyLNImRDkLGAFlVceiYADZFAVjPrLAdkVWHFpAA5FT9xoCcip5sAL64uEgSADYAhmRYAG5xUCCWAFxQBAA+OCmWaJgZGgXAAHQk5NS0WGH4Odh5SCVF+Rhl+oZQtfWNKG0tTW2l4tKyoAohANzhuADOAO4UxBIAFlAAFKlIpVt9mACUOAQSMbNYxUO4IUA)

```ts
enum NodeType {
	Attribute = 1,
	DocComment = 2,
	Comment = 3,
	SomeNode4 = 4,
	SomeNode5 = 5,
	SomeNode6 = 6,
	SomeNode7 = 7,
	SomeNode8 = 8,
	SomeNode9 = 9,
}

declare var node: 
	| { nodeType: NodeType.Attribute }
	| { nodeType: NodeType.Comment }
	| { nodeType: NodeType.DocComment };


switch (node.nodeType) {
	case NodeType.
}
```

My suggestion here is to only show the 3/9 `NodeType` members compatible with `node.nodeType`

<img width="458" alt="chrome_2022-05-28_12-47-06" src="https://user-images.githubusercontent.com/30108880/170822127-c3a4c50e-ebee-454d-b299-212cff862193.png">
Repository: godot
Issue: GDScript 2.0: Stack overflow regression
Labels: bug,topic:gdscript,needs testing,regression

### Godot version

4.0 dev (7b8c574401b3b3a211fd478eaa3fbb99b6dbb798) nightly after 30th of April

### System information

Arch Linux, KDE Plasma, Radeon RX580, amdgpu driver, Vulkan

### Issue description

After testing my game in nightly builds of Godot 4.0 dev, starting with commit `7b8c574401b3b3a211fd478eaa3fbb99b6dbb798` (not strictly bisected) I am experiencing a Stack Overflow error, while previously it wasn't there, even though nothing in the game's code has changed:

![Clipboard - May 22, 2022 6_00 PM](https://user-images.githubusercontent.com/491704/170822901-8b63e0a9-2fdd-49c2-a3d6-712531a81478.png)

This error was first noticed in a dev build from commit 7b8c574401b3b3a211fd478eaa3fbb99b6dbb798
The last known working Godot 4.0 dev commit is 8adf04804

A regression must have been introduced somewhere between these two  commits.

### Steps to reproduce

1. Clone and my project Liblast from this specific commit: https://codeberg.org/unfa/Liblast/src/commit/31aefa29dcd62e637dcd203e77602f051a68c320 (the project uses LFS, so make sure you clone that as well - if in doubt please refer to [this section of project's README](https://codeberg.org/unfa/Liblast/src/commit/31aefa29dcd62e637dcd203e77602f051a68c320#_gnulinux))
3. Open the scene `Game/Assets/Tests/Characer Test.tscn`
4. Hit `F6` to play the curent scene.
5. Observe a stack overflow error.






### Minimal reproduction project

_No response_
Repository: godot
Issue: Detect 3D at import-time treats normal/AO/height maps as roughness maps, but does not treat roughness maps as such
Labels: bug,topic:import,topic:3d

### Godot version

4.0.alpha8

### System information

Fedora 36, GeForce GTX 1080 (NVIDIA 510.68.02)

### Issue description

When configuring textures in a StandardMaterial3D, normal map, ambient occlusion map and height maps are all detected to be used as a roughness map, which is incorrect. The roughness map is not detected as being used as a roughness map.

I haven't checked behavior with ORMMaterial3D, but it's likely affected too.

### Steps to reproduce

- Ensure `.godot/` folder is not present within the project folder, and ensure `*.import` *files* are not present next to files. This forces 3D detection to happen again, which is important in case you're looking into fixing this.
- Open the minimal reproduction project in the editor (`.godot/` and `*.import` files were already removed from it).
- Look at textures' import flags by selecting them in the FileSystem dock, then looking at the Import dock.

### Minimal reproduction project

[test_material_detect_3d.zip](https://github.com/godotengine/godot/files/8791210/test_material_detect_3d.zip)
Repository: neovim
Issue: vim.ui.inputsecret
Labels: enhancement,lua

### Feature already in Vim?

_No response_

### Feature description

it would be great if vim.ui.input would allow to input secrets, like the vim builtin `inputsecret` -- meaning a text input, but * gets displayed instead of real characters when you type.

I'm using nvim neogit to work with git, and the first time I need to use git, I must enter my git passphrase. neogit asks through vim.inputsecret -- there is no other option that I know of -- and I many times don't notice the prompt at the bottom of the screen. With a hypothetical vim.ui.inputsecret and a library like dressing.nvim, the issue would be solved, since dressing.nvim is a lot more "in your face".
Probably it should be a new call vim.ui.inputsecret rather than a flag to vim.ui.input, because if libraries that reimplement the UI like dressing.nvim don't have support for the flag at first, it could be a security issue.

Anyway, just an idea, feel free to close ofc.
Repository: next.js
Issue: Image component does not generate accurate srcsets
Labels: bug,Image (next/image)

### Verify canary release

- [X] I verified that the issue exists in Next.js canary release

### Provide environment information

Let's say I want to display an image on my website. The image is to be displayed as 24px, but I want to provide a 48px version via a @2x srcset for Retina users.

I add a 48x48px png of the image to my files. Then I create an image like:

`<Image src={author.avatar} width={24} height={24} layout="raw" />`

The HTML produced by NextJS becomes the following:

```html
<img src="/_next/image?url=%2Fimages%2Favatar-small.jpg&amp;w=400&amp;q=75"
height="24" width="24" decoding="async" data-nimg="raw"
style="aspect-ratio:24 / 24"
srcset="/_next/image?url=%2Fimages%2Favatar-small.jpg&amp;w=400&amp;q=75 1x">
```


As you can see, the image is fetched with the argument `w=400` and only in 1x size. Inspecting the resource, I can see that NextJS is generating the asset in a size as close to `400px` as possible, which in this case becomes 96px (asset size * 2).

<img width="408" alt="Screenshot 2022-05-28 at 16 33 33" src="https://user-images.githubusercontent.com/1417019/170829904-a07907bd-ca64-4b3d-aae4-ff89365ef9f0.png">

According to the documentation, the only way to accurately represent the image the way I want (accurate srcset dimensions) is to add the image size to my `imageSizes` in my `next.config.js`. Indeed, if I add `imageSizes: [24, 48]` to my config and restart my server, the HTML output now becomes:


```html
<img src="/_next/image?url=%2Fimages%avatar-small.jpg&amp;w=48&amp;q=75"
height="24" width="24" decoding="async" data-nimg="raw"
style="aspect-ratio:24 / 24"
srcset="/_next/image?url=%2Fimages%2avatar-small.jpg&amp;w=24&amp;q=75 1x,
/_next/image?url=%2Fimages%2Fcindori-avatar-small.jpg&amp;w=48&amp;q=75 2x">
```

<img width="568" alt="Screenshot 2022-05-28 at 16 43 56" src="https://user-images.githubusercontent.com/1417019/170830353-0b51b158-0131-4ffd-b379-84588b38b6be.png">


Which is exactly what I want, a 1x srcset at `w=24px` and a 2x srcset at `w=48px`. No fidelity loss and no data wasted.

The problem is that **I must do this for every single image in my whole website for this to work**. Adding 1x and 2x image widths to the `imageSize` array in the config is not only extremely cumbersome, it is actually not even a viable solution because NextJS caps the array to 25 entries.

Why is the Image component, with all its bells and whistles, not built to handle such a basic requirement?
Am I missing something fundamental here? Is there any efforts being made to adress this massive shortcoming?

### What browser are you using? (if relevant)

Safari 15.4

### How are you deploying your application? (if relevant)

Vercel

### Describe the Bug

The NextJS Image component is unable to generate accurate 1x and 2x image srcsets for custom image sizes.

### Expected Behavior

The NextJS Image component should be able to generate accurate 1x and 2x image sizes without any custom configuration.

### To Reproduce

See description.
Repository: flutter
Issue: [GoRouter Feature Request] add option to specify initial location as name (not path)
Labels: c: new feature,package,c: proposal,P2,p: go_router,team-go_router,triaged-go_router

It would be nice to allow a route's name to be assigned as the initial location when instantiating a `GoRouter` instance.

At the moment, only a path can be assigned to the parameter `initialLocation`, which defaults to `"/"`.

I suggest to add a parameter `initialLocationInferedByRouteName`, that if not `null` makes `GoRouter` prioritize  `initialLocationInferedByRouteName` over `iniitalLocation`.
Repository: rust
Issue: Mundane HRTB causes constraint satisfaction failure
Labels: C-bug,T-types,A-GATs,A-higher-ranked

I'm trying to understand an error I'm seeing with some project code, which I've minimised down to a test case that I'm trying to get my head around.

The following two snippets build perfectly fine, as I would expect:

```rust
trait A {
    type X;
}

trait B: A<X = u32> {
    /* ... */
}

impl<T> A for T where T: B {
    type X = u32;
}
```

(https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=052cefcd91b153d1958b8452a9ddbfe7)

```rust
trait A {
    type X;
}

trait B: for<'a> A {
    /* ... */
}

impl<T> A for T where T: B {
    type X = u32;
}
```

(https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=302cd29650a304e40d8ca65bb9d7521d)

However, this third snippet, which combines both the mundane HRTB and the associated type requirement, fails with an obscure error:

```rust
trait A {
    type X;
}

trait B: for<'a> A<X = u32> {
    /* ... */
}

impl<T> A for T where T: B {
    type X = u32;
}
```

(https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=56ad9194355f412f7b22c121ff6479d3)

Giving:

```
error[[E0284]](https://doc.rust-lang.org/nightly/error-index.html#E0284): type annotations needed: cannot satisfy `<T as A>::X == _`
  --> src/lib.rs:10:14
   |
10 |     type X = u32;
   |              ^^^ cannot satisfy `<T as A>::X == _`

For more information about this error, try `rustc --explain E0284`.
error: could not compile `playground` due to previous error
```

What is it about the HRTB that causes the compiler to suddenly become unable to determine that the type of X must be u32? Am I fundamentally misunderstanding HRTBs?

I ran into this because I needed to `impl` a supertrait with GATs on a type with an existing `impl` of the sub-trait, a la:

```rust
#![feature(generic_associated_types)]

trait A {
    type X<'a>;
}

trait B: for<'a> A<X<'a> = Self::Y<'a>> {
    type Y<'a>;
}

impl<T> A for T where T: B {
    type X<'a> = T::Y<'a>;
}
```

(https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=74172d3948e66032f917f18fc8cfaf2a)
Repository: godot
Issue: `warp_mouse()` function does not trigger `mouse_entered` signal on Controls on macOS
Labels: bug,platform:macos,topic:input

### Godot version

v3.4.1.stable.official

### System information

MacBook Air

### Issue description

I was working on making a controller/joystick-compatible cursor for my game to add controller support. I ended up using the function `get_viewport().warp_mouse(pos)` which correctly warps the mouse to the given position.

When I was testing this out though, I noticed that buttons did not seem to respond when the mouse was moved over them. I then tried using the function `Input.warp_mouse_position(pos)` to move the mouse instead, but the same problem reoccured.

In fact, no `Control` nodes seem to detect when the mouse is moved over them.

### Steps to reproduce

1. Open a Godot project
2. Add a `Control` node to the scene
3. Add a `Button` node to the scene and scale it so that it's easy to click on
4. Add a script to the `Control` node
5. Copy and paste the following code into the `Control` node:

>extends Control
>
>var mouse: Vector2
>
>func _input(event):
>if event is InputEventMouseMotion:
>mouse = event.position
>elif InputEventKey and event.scancode == KEY_SHIFT:
>mouse.y -= 10
>get_viewport().warp_mouse(mouse)

_indent the code as needed_

6. Save and run the scene
7. Move the mouse under the `Button` and press the shift key repeatedly
8. When the mouse reaches the`Button`, the hover animation for the `Button` shouldn't play
9. Click on the `Button` and the press animation should play, but if you continue to press the shift key, the mouse will go past the `Button` without the hover animation stopping


### Minimal reproduction project

[MouseWarpBug.zip](https://github.com/godotengine/godot/files/8791414/MouseWarpBug.zip)