sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: storybook
Issue: [Bug]: element types in story args are not displayed correctly in JSX preview
Labels: bug,react,addon: docs,needs triage,argtypes

### Describe the bug

When a component takes an element type as a prop, and it is passed as an arg to a story, the JSX preview in the docs page canvas for that story does not show the correct value for that prop. 

I'm talking about props that can be specified as `PropTypes.elementType`, but the prop doesn't need to be present in `propTypes` for the bug to appear.

For example, given that
* `Icon` takes a prop, `glyph`, which is of type `elementType` (`<Icon glyph={Key} />`)
* And a story is defined for the icon:

   ```
   export const Example = args => <Icon {...args} />;
   Example.args = {
     glyph: Key
   };
   ```
* **Expected:** I would expect the JSX preview in the Canvas on the docs page to display `<Icon glyph={Key} />`
* **Actual:** It displays `<Icon glyph={() => {}} />`

### To Reproduce

* Clone the reproduction repo: https://github.com/elisehein/storybook-element-type-jsx-preview
* Run storybook

```shell
yarn
yarn storybook
```

* See [Repro/Component](http://localhost:6007/?path=/docs/repro-component--docs) docs page which shows stories for two variants of the same component: one that takes a prop of type `elementType`, and one that takes a prop of type `element`. 
* Observe that the `elementType` type prop is not displayed correctly in the JSX preview. An element of the same type as elementType, but initialised, and passed into a component, is shown correctly in the JSX preview.

<img width="1019" alt="Screenshot 2023-01-01 at 21 29 04" src="https://user-images.githubusercontent.com/604621/210182550-3bf44ecb-bf4f-4ef7-bd36-f124003c3a48.png">

<img width="618" alt="Screenshot 2023-01-02 at 09 04 19" src="https://user-images.githubusercontent.com/604621/210202485-579d20a3-4e76-4c6b-b672-7888b5d00d94.png">

### System

```shell
Environment Info:

  System:
    OS: macOS 12.6
    CPU: (10) arm64 Apple M1 Pro
  Binaries:
    Node: 16.17.1 - /opt/homebrew/bin/node
    Yarn: 3.3.1 - /opt/homebrew/bin/yarn
    npm: 8.15.0 - /opt/homebrew/bin/npm
  Browsers:
    Chrome: 108.0.5359.124
    Firefox: 107.0
    Safari: 15.6.1
  npmPackages:
    @storybook/addon-essentials: ^7.0.0-beta.19 => 7.0.0-beta.19 
    @storybook/addon-interactions: ^7.0.0-beta.19 => 7.0.0-beta.19 
    @storybook/addon-links: ^7.0.0-beta.19 => 7.0.0-beta.19 
    @storybook/blocks: ^7.0.0-beta.19 => 7.0.0-beta.19 
    @storybook/react: ^7.0.0-beta.19 => 7.0.0-beta.19 
    @storybook/react-webpack5: ^7.0.0-beta.19 => 7.0.0-beta.19 
    @storybook/testing-library: ^0.0.13 => 0.0.13
```


### Additional context

Raised on Discord here: https://discord.com/channels/486522875931656193/1054362978104905741
Repository: godot
Issue: Custom project setting of custom type specified in singleton will crash editor
Labels: bug,topic:editor,crash

### Godot version

4.0.dev (57267709e665f1683e79bd5d3432be2be5db6c1d)

### System information

Windows 11

### Issue description

If user creates and sets ProjectSettings value of custom resource type from singleton (didn't try from regular node) editor 100% crashes upon restart from menu or can't load project if started anew until such settings value is removed from `project.godot`. 

I think this happens because tool singletons (or settings per se) start loading from `project.godot` **before** all project types are registered.

Also 2 related bugs to this case (can report them as separate issues if needed):
1. Hint string doesn't understand custom resources correctly. if I specify 'CustomResource' or array of 'CustomResource' types dropdown won't filter types
2. Developer can't specify custom project setting of any Resource type with default value of `null` (because user may want to store configuration in separate file). It happens because `ProjectSettings.set_setting(name, default_value)` has documented side effect. If user sets default value to `null` setting is removed.  There should be explicit `remove_setting` function.  Right now there is a workaround to set default value to `[]`, but it shouldn't work.

### Steps to reproduce

1. Create custom resource type 'CustomResource'
2. Create and register **tool** singleton which registers custom ProjectSettings value of 'CustomResource' type (or array of such resource)
3. Set value of such setting. It doesn't matter it's embedded or resource from file
4. Restart project from menu. Get crash.
5. Restart editor, try to load project. It won't load and tell user incorrect message about no engine version


### Minimal reproduction project

Project contains steps 1 and 2 from steps to reproduce.
[reproduce_project_settings_bug.zip](https://github.com/godotengine/godot/files/10329522/reproduce_project_settings_bug.zip)
Repository: rust
Issue: Semicolon after diverging try operator shouldn't matter
Labels: F-never_type,C-discussion,T-types

<!--
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.
-->

Originally mentioned in this comment: https://github.com/rust-lang/rust/issues/96373#issuecomment-1328631967

Essentially, semicolons after other diverging expressions are allowed. For example:

```rust
fn works() -> Result<bool, i32> {
    return Err(1);
}
```

Here, the compiler is clever enough to note that because `return Err(1)` always diverges, adding a semicolon after doesn't matter. However, the below code which is equivalent to this does not work properly:

```rust
fn breaks() -> Result<bool, i32> {
    Err(1)?;
}
```

Here's a playground link containing the above two examples: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=af894bab48348897a421a9402856b71f

The exact compiler error:

```
error[[E0308]](https://doc.rust-lang.org/nightly/error-index.html#E0308): mismatched types
 --> src/lib.rs:5:16
  |
5 | fn breaks() -> Result<bool, i32> {
  |    ------      ^^^^^^^^^^^^^^^^^ expected enum `Result`, found `()`
  |    |
  |    implicitly returns `()` as its body has no tail or `return` expression
6 |     Err(1)?;
  |            - help: remove this semicolon to return this value
  |
  = note:   expected enum `Result<bool, i32>`
          found unit type `()`

For more information about this error, try `rustc --explain E0308`.
error: could not compile `playground` due to previous error
```
Repository: pytorch
Issue: Add BlockWise Distribution Support to the torch.distributions Package
Labels: module: distributions,triaged

### 🚀 The feature, motivation and pitch

I am requesting the addition of BlockWise distribution support to the torch.distributions package in PyTorch. By "BlockWise distribution", I am referring to distributions for which the event dimensions have separate, distinct and independent distributions.

For example, consider an n-dimensional event space, where each dimension is independently distributed according to a separate distribution. A BlockWise distribution would allow users to specify and sample from this type of distribution using the torch.distributions API.

This type of distribution can be useful in a variety of applications, such as factorizing a complex distribution into a product of simpler distributions, or modeling distributions over high-dimensional event spaces. The particular use case I have in mind is to create separate distributions for a radial and angular coordinate (say a MixtureSameFamily and a Uniform distribution to create multiple rings), then use a Transform (Bijector) to recover cartesian coordinates. 

It would be great if PyTorch could provide support for BlockWise distributions through the torch.distributions package.

Here is how my particular example would look like

```python
import numpy as np
import torch
import torch.distributions as tfd

def rings(modes: int = 4, mode_width: float = 0.1, inner_radius: float = 1., outer_radius = 10.):
    """
    Concentric rings distribution
        :param modes: Number of concentric rings in the mixture
        :param inner_radius: Size of the smallest ring.
        :param outer_radius: Size of the largest ring.
        :param mode_width: Width of the modes (radial coordinate only)
    """
    r = torch.linspace(inner_radius, outer_radius, modes)
    mixture = tfd.Categorical(probs=torch.ones(modes), validate_args=False)
    component = tfd.Normal(loc=r, scale=mode_width, validate_args=False)
    r_distribution = tfd.MixtureSameFamily(mixture, component, validate_args=False)
    theta_distribution = tfd.Uniform(low=-np.pi, high=np.pi, validate_args=False)
    return tfd.TransformedDistribution(
        base_distribution=tfd.BlockWise([r_distribution, theta_distribution]),
        transforms=PolarToCartesianTransform()
    )
``` 

Thank you for considering this feature request!






### Alternatives

_No response_

### Additional context

_No response_

cc @fritzo @neerajprad @alicanb @nikitaved
Repository: PowerToys
Issue: Keyboard Repeat Delay
Labels: Needs-Triage

### Description of the new feature / enhancement

Possibility to enable Keyboard repeat delay similar do NoPing's feature.

### Scenario when this would be used?

For games.

### Supporting information

_No response_
Repository: godot
Issue: TileMap Terrain: preview tiles are wrong relative to the tiles that actually get placed
Labels: bug,topic:editor,topic:2d

### Godot version

4.0.beta10

### System information

Windows 10, NVIDIA GeForce GTX 1060 516.94

### Issue description

Using a Kenney tilemap, I tried to make a TileMap terrain set of single-tile-width river tiles (i.e. no lakes). The terrain is made up of one corner and one straight. That corner and straight have alternatives to cover the four cardinal directions.

When placing these into the TileMap, the **preview** for the tiles are incorrect (the in-game tiles are correct.) For example, preview tile 1 is incorrectly shown as a **lake corner** but the in-game tile is correctly shown as a west-to-north river piece. Preview tile 4 is incorrectly shown as a **lake south shore** but the in-game tile is correctly shown as a north-to-east river piece.

![terrain_bad_preview](https://user-images.githubusercontent.com/2057161/210191857-df8a93f9-2273-480b-92a8-4edb9c90cb71.gif)


### Steps to reproduce

Try the included repro project.

### Minimal reproduction project

[terrain_bad_preview.zip](https://github.com/godotengine/godot/files/10329884/terrain_bad_preview.zip)
Repository: godot
Issue: The exported program conflicts with the build when debugging
Labels: bug,topic:editor,topic:dotnet,topic:export

### Godot version

3.5.1mono

### System information

windows10

### Issue description

See “Steps to reproduce” for details


### Steps to reproduce

Create an empty project
Export it with the project name to the same folder as the project file (.godot extension).
Run it in editor
An get an runtime error
  E 0:00:00.584   _real_load_assembly_from: Failed to open assembly image from memory: 'xxx/Project Name.exe'.
  <C++ 错误>      Condition "status != MONO_IMAGE_OK || !image" is true. Returned: __null
  <C++ 源文件>     modules/mono/mono_gd/gd_mono_assembly.cpp:247 @ _real_load_assembly_from()


### Minimal reproduction project

An empty project
Repository: electron
Issue: [Bug]: Application window does not have border shadow on KDE Plasma desktop environment (or not using mutter)
Labels: platform/linux,bug :beetle:,21-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

21.3.2

### What operating system are you using?

Other Linux

### Operating System Version

openSUSE Tumbleweed 20221228

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

Application window has border shadow on KDE Plasma Desktop

### Actual Behavior

No border shadow when using kwin. The border shadow is visible when using mutter on KDE Plasma Desktop.

### Testcase Gist URL

_No response_

### Additional Information

_No response_
Repository: godot
Issue: Deleting a script attached to a node outside of the Godot editor causes errors
Labels: enhancement,topic:editor

### Godot version

3.5.1mono

### System information

windows10

### Issue description

See "Steps to reproduce" for details

### Steps to reproduce

Create a project
Create a scene
Create a script
Mount the script to any node in the scene
Open System Explore
Delete the script file
Get error with these messages
![image](https://user-images.githubusercontent.com/119792950/210224540-8cf156a1-c30d-49c0-be40-2fc591e13714.png)

---Additional---
I found another way to trigger this error output

Create a project
Trigger a runtime error in a script
Delete the script that trigger the error
Go to the node where the script is mounted
Unmount the script
Run again and you can see the error message is still here

This is an example video
[2023-01-02 22-23-10.zip](https://github.com/godotengine/godot/files/10332134/2023-01-02.22-23-10.zip)

and the error output triggered this way, which comes up repeatedly every time it runs (even if the script has been unmounted in the node) until it is restarted
The minimally compressed item cannot be passed because the error disappears after restarting the editor

### Minimal reproduction project

The error will be reverted after a restart, so the project cannot be made
Repository: vscode
Issue: Scroll speed doubled when screen scaling is enabled
Labels: bug,editor-scrollbar

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes/No

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
Version: 1.73.1
Release: 22314
Commit: 14f2d26367b7e8f03ff2352516ba27d6302dd7b1
Date: 2022-11-10T18:19:13.052Z
Electron: 19.0.17
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Linux x64 6.0.0-6-amd64
Sandboxed: No

Steps to Reproduce:

1.  Run vscode in two different situations: With resolution 1920x1080 and scaling factor 1, and with 4k resolution and scaling factor 2.
2. Open some file, and turn the scroll wheel on the mouse by one notch.

Expected behavior:
It should scroll the same amount.

Actual behavior:
Scrolling is doubled when using screen scaling.
Repository: vscode
Issue: Group Linked Files in One Tab with Dropdown
Labels: feature-request,ux,workbench-tabs

<!-- ⚠️⚠️ 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. -->
![image](https://user-images.githubusercontent.com/21246924/210234395-5d22f708-4960-4f6b-8f4c-3c9fb3f0f3f4.png)
I would like the ability to group 'dependent' files. In the image above, I have 4 files all directly tied to a specific component. This project will constantly have these 4 files for 1 component. Instead of having 4 separate tabs, I feel that it would be amazing to have a single tab with a dropdown containing all related files. This cleans up the top portion of the editor a good bit.
Repository: godot
Issue: An EditorPlugin build callback failed.
Labels: bug,topic:editor,topic:dotnet

### Godot version

3.5.1mono

### System information

windows10

### Issue description

I found another similar issue(https://github.com/godotengine/godot/issues/35897) ,but my situation seems a little different.
Every unsuccessful build is accompanied by this error output
      editor/editor_node.cpp:5532 - An EditorPlugin build callback failed.
For example, this output appears when there is a syntax error displayed in MSBuild at build time. I think this is strange,because it looks as if something went wrong with the editor. I think it would be better to make it clearer (e.g. "Error : Project Build Failed"). Please tell me if my idea is wrong.

### Steps to reproduce

Create a project
Add a C# script with any syntax error
Run it
See the output and get this:
    editor/editor_node.cpp:5532 - An EditorPlugin build callback failed.

### Minimal reproduction project

An empty project
Repository: godot
Issue: Vulkan: Disabling V-Sync on Intel integrated graphics crashes the renderer
Labels: bug,platform:linuxbsd,topic:rendering,topic:thirdparty

### Godot version

4.0 (beta 10)

### System information

Fedora, Intel(R) HD Graphics 5600 (BDW GT2)

### Issue description

I'm developing a PoC for benchmarking the player's hardware and setting the graphic settings accordingly. When running it on a machine without GPU (only an Intel Integrated Graphics), the project renderer crashes on the line where the settings disable the `DisplayServer` VSync (Godot throws an error, and the screen stays black. The project does not close, though).

### Steps to reproduce

This only happens when VSync is set "Enabled" on Project Settings and is set to disabled with `DisplayServer.window_set_vsync_mode()`. I can't reproduce this issue on a machine with GPU.

### Minimal reproduction project

https://github.com/GDQuest/3D-graphics-benchmark-PoC
Repository: angular
Issue: Animations - Adding a Dev warning for wrongly applied `state`s
Labels: area: animations

### Which @angular/* package(s) are relevant/related to the feature request?

animations

### Description

I believe that animation `state`s should only reside on the top level of a `trigger`, elsewhere they have no effect, for example inside a `transition`, as you can see from this [example](https://stackblitz.com/edit/angular-ivy-ubdrrn).

I think that the current implementation is correct, the issue is that (as you can see in the example) no errors/warnings are presented to the developer which can lead to confusion as to why a `state` is not being applied.

This can also worsen, for example `state`s applied in `useAnimation` calls don't correctly handle params, I also think that that is totally fine since `state`s should not be applied and won't work there anyways (since `useAnimations` are called inside `transition` calls), but this in this case generated an unclear/misleading warning for the developer (see https://github.com/angular/angular/issues/48565 for more context)

### Proposed solution

Add a dev mode check during the DSL tree parsing (or if not possible in the animation's execution) so that if a state is encountered when it won't have an effect an appropriate warning is presented to the developer (and if possible also prevent other unrelated/confusing warnings, like the params one mentioned above to show up)

(PS: since the warning would be only in dev mode, for production things would remain mostly the same)

### Alternatives considered

- making the `AnimationStateMetadata` somehow incompatible with `AnimationMetadata` so that errors can surface immediately via static analysis (this would be the optimal solution I think, but since `AnimationMetadata` extends `AnimationMetadata` I am not sure if this is actually possible, and it may require more work, refactoring and possible breakages, so it's probably not worth it to go into this direction)
- making the `state`s work also when applied inside `transition`s, `useAnimation`s, etc... (potentially by making assumptions on what the developer wanted to accomplish). This can result in a slightly better/more convenient DX but a less clean/clear API, it could be rather convenient for example in `useAnimation`s. (It could require quite a bit of refactoring) I also think that this would make the `state`s work in a way they are not supposed to, so I personally wouldn't go with it.
Repository: godot
Issue: Godot v4 editor needs restart to detect inherited method.
Labels: bug,topic:gdscript,topic:editor,needs testing

___

***Bugsquad note:** This issue has been confirmed several times already. No need to confirm it further.*

___

### Godot version

v4.0.beta10.official [d0398f62f]

### System information

Apple M1 Max - macOS Ventura 13.1 (22C65)

### Issue description

_I'm actually not sure when this bug was introduced, or if it exists in v3 too._

Adding a new method on a super class, and then calling it from an extending class, triggers a "not found" error in the editor. The code however can run fine when running the scene.

See attached video:

https://user-images.githubusercontent.com/905216/210248116-f5af4af4-13f1-4755-a9a0-ffb49d571237.mov



### Steps to reproduce

- Create a few classes that inherit from each other. Not sure how many levels of inheritance is needed to trigger this, but it does for me when using 3 or 4 levels. I.e: `ClassA` → `ClassB` → `ClassC` → `ClassD`
- Save
- Define a method at the top-most super class in the inheritance chain, i.e: `ClassA`
- Try to call the method on the last class in the chain, i.e: `ClassD`
- The editor doesn't detect the method.
- Save – It still isn't detected.
- Close Godot and open the project again.
- Now the method is detected.

### Minimal reproduction project

I am sharing the project I created to reproduce some bugs in the editor, but it still requires redoing the steps on your end to trigger this, since restarting the editor fixes the issue.

[Godot Crash Test.zip](https://github.com/godotengine/godot/files/10332205/Godot.Crash.Test.zip)