sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Vulkan: TAA does not make the editor redraw until it has fully converged
Labels: bug,topic:rendering,topic:editor,confirmed,topic:3d

*Related to https://github.com/godotengine/godot/issues/54892, https://github.com/godotengine/godot/issues/54893 and https://github.com/godotengine/godot/issues/56723.*

### Godot version

4.0.alpha11, 4.3.dev4

### System information

Fedora 36, GeForce GTX 1080 (NVIDIA 510.68.02)

### Issue description

Temporal antialiasing (TAA) does not make the editor redraw until it has fully converged. This means that when toggling TAA or changing a setting that causes it to regenerate (such as resizing the editor viewport), it will have partially-converged appearance until you move the 3D camera around a bit (or cause the editor viewport to update somehow, e.g. by hovering controls).

We should resolve this by forcing the engine to redraw for 16 frames every time something is updated when both TAA and low processor mode are enabled.[^1] (16 frames is the duration of the Halton jitter sequence used by TAA.)

[^1]: We shouldn't just do this when the camera moves, as other objects being updated (such as a mesh's visibility being toggled) also requires the TAA to fully converge to look good – even if the camera doesn't move.

### Steps to reproduce

- Add some MeshInstance3Ds with BoxMeshes.
- Enable **Use TAA** in the Project Settings. Don't move the 3D editor camera for now. Notice the boxes' edges being aliased.
- Start moving the 3D editor camera *slowly* (use mouse wheel or hold <kbd>Alt</kbd> while using freelook). Notice how boxes' edges are smooth, at least until you stop moving.
- Enable **Update Continuously** in the Editor Settings to force the editor to redraw every frame. Notice how edges are smooth.

### Minimal reproduction project

N/A
Repository: TypeScript
Issue: Conditional type inside function resolves differently than at top-level
Labels: Needs Investigation,Rescheduled,Cursed?

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

regression conditional type inside function behaves difference

### 🕗 Version & Regression Information
- This changed between versions 4.2.3 and 4.3.5

### ⏯ Playground Link
[Playground link](https://www.typescriptlang.org/play?ts=4.3.5#code/N4WAUABBAuCeAOBTCBBCBeCAlRBjA9gE4AmAPAM7SECWAdgOYA0EtArgLYBGihAfBOChwkEAEIZseImQDkAQxkQAPhBmcZzNlx79BEArUoQAHgC5UERMeiJaxcmIgB+GIVbJzAMzkAbcskxvP0QAbggAenCIfABrcABfcHBPVlpcaGp8WhhESgAKAEoIUEgYBGQ0TBwCEgoqOiYWDm4+AVLhZHEqqVr5RRU1DSbtVr0DIzMLKxs7B3EXKncIL19-CSD-MMjLQkIiBKA)

### 💻 Code
```ts
{
  type A = Record<string, number> 
  type B = Record<'a' | 'b', number> 
  const x: A extends B ? true : false = false; // ok
}

function test() {
  type A = Record<string, number> 
  type B = Record<'a' | 'b', number> 
  const x: A extends B ? true : false = false; // error
}
```

### 🙁 Actual behavior

The conditional type resolves differently in global vs local scope.

### 🙂 Expected behavior

Both should resolve the same way, preferably `false` in both cases. 

### Additional Details

This seems to have something to do with the way typescript compares aliases, wrapping one of the `Record` types in `Omit<Record<...>, never>` causes the comparison to behave normally

[Playground Link](https://www.typescriptlang.org/play?ts=4.3.5&ssl=23&ssc=2&pln=1&pc=1#code/GYVwdgxgLglg9mABFApgZygCgJSIN4CwAUIsgJ4AOKiAgogLyIBKKEcATgCYA8G7MYAOYAaRGBABbAEYp2APkTFSUStQBCDZqw48A5AENdiAD6JdU3aPHTZCpYjZgMiAB4AuWohQvUYTmkQNAH5kdhBqD2B9ABs0akYo2JQAbkQAejSvdnYOYgBfYmJQSFgEZHQoACYcfHsVKk9GAHkJGChuFjYuXih+IStJGXkrFAA3WzrVQM1OnW4DI1NzSzFB20USBwRnd09vX39pkN7wxEiYuM1EuNSMxDgAa3zComLoeCRUDABmGsJN+rUOiMWbdPgCESrGzyZKTBoaZqtdqgvSGExmCwDaFyEbjeT2Rw7Dx0fYoPwBYKhU7nJJXC4pdKZR7PIhFcDvMpfKAAFj+cKBmhabQ62jBvQhWKGOLEY1ssIBUwRiCFyNFqMWGJW1iluImm0JUFcxK8PjJh0pJwiiGu8Wt9NumVkOXY+SAA)
```ts
function test() {
  type A = Record<string, number> 
  type B = Record<'a' | 'b', number> 
  const x: A extends B ? true : false = false; // error
}

function test2() {
  type A = Omit<Record<string, number>, never>
  type B = Record<'a' | 'b', number> 
  const x: A extends B ? true : false = false; // ok
}

function test3() {
  type A = Record<string, number>;
  type B = Omit<Record<'a' | 'b', number>, never>
  const x: A extends B ? true : false = false; // ok
}

function test4() {
  type A = Omit<Record<string, number>, never>;
  type B = Omit<Record<'a' | 'b', number>, never>
  const x: A extends B ? true : false = false; // error
}
```
Repository: godot
Issue: Switching to RAW mode and then to RGB will change slider max value until refreshed
Labels: bug,confirmed,usability,topic:gui

### Godot version

4.0 d26442e / 3.5

### System information

Windows 10 x64

### Issue description

When you change to RAW color mode, you can set a slider to some very big value. When you then switch to RGB, that slider will have a different max value. That value will stay until you change color mode again. I think it should switch back to 0-255 range as soon as you change the value to something within that range.
![Z5sEZ3qfr0](https://user-images.githubusercontent.com/2223172/178157048-3e72e7c8-c87d-4d7f-9b6c-5a6163dee756.gif)
(the GIF is from older build)

### Steps to reproduce

1. Have some ColorPicker
2. Change to RAW color mode
3. Set e.g. R to 100
4. Switch back to RGB
5. Set R to 0
6. You can still set R beyond 255

### Minimal reproduction project

_No response_
Repository: pytorch
Issue: grad not preserved during copying or pickling
Labels: triaged,module: python frontend

### 🐛 Describe the bug

I would like to (cloud-)pickle some Tensors. However, their `grad` attribute is lost during pickling. The following snippet 

```python
import cloudpickle
import copy
import torch

def square(x):
    return x*x

x = torch.tensor([2.0], requires_grad=True)
loss = square(x)
loss.backward()
print (type(x), x, x.grad)
y = copy.copy(x)
print (type(y), y, y.grad)

y = cloudpickle.loads(cloudpickle.dumps(x))
print (type(y), y, y.grad)

```
yields the following output:
```
<class 'torch.Tensor'> tensor([2.], requires_grad=True) tensor([4.])
<class 'torch.Tensor'> tensor([2.], requires_grad=True) None
<class 'torch.Tensor'> tensor([2.], requires_grad=True) None

```

I can work around this using a custom reduction function for `torch.Tensor` like
```python

import copyreg
def reconstruct_tensor(val, requires_grad, grad, device):
    t = torch.tensor(val, device=device, requires_grad=requires_grad)
    if grad:
        t.grad = torch.from_numpy(grad)
    return t
    
def reduce_tensor(t):
    if t.requires_grad:
        return reconstruct_tensor, (t.detach().numpy(), True, t.grad.numpy(), t.device.type)
    else:
        return reconstruct_tensor, (t.numpy(), False, None, t.device.type)

copyreg.pickle(torch.Tensor, reduce_tensor)
# Include previous snippet here
```
which yields the expected output
```
<class 'torch.Tensor'> tensor([2.], requires_grad=True) tensor([4.])
<class 'torch.Tensor'> tensor([2.], requires_grad=True) tensor([4.])
<class 'torch.Tensor'> tensor([2.], requires_grad=True) tensor([4.])

```
This is basically what [Dask does](https://github.com/dask/distributed/blob/main/distributed/protocol/torch.py). But a better place to fix this would seem to be in [`Tensor.__reduce_ex__`](https://github.com/pytorch/pytorch/blob/3c2199b159b6ec57af3f7ea22d61ace9ce5cf5bc/torch/_tensor.py#L208)

### Versions

PyTorch version: 1.12.0+cpu
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Fedora Linux 35 (Container Image) (x86_64)
GCC version: (GCC) 11.2.1 20220127 (Red Hat 11.2.1-9)
Clang version: Could not collect
CMake version: Could not collect
Libc version: glibc-2.34

Python version: 3.8.13 (default, Mar 28 2022, 11:38:47)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.18.9-200.fc36.x86_64-x86_64-with-glibc2.17
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.23.0
[pip3] torch==1.12.0+cpu
[pip3] torchaudio==0.12.0+cpu
[pip3] torchvision==0.13.0+cpu
[conda] numpy                     1.23.0                   pypi_0    pypi
[conda] torch                     1.12.0+cpu               pypi_0    pypi
[conda] torchaudio                0.12.0+cpu               pypi_0    pypi
[conda] torchvision               0.13.0+cpu               pypi_0    pypi
Repository: svelte
Issue: Parameter to control the state of transitions without necessarily using If.
Labels: transition/animation

### Describe the problem

Sometimes it is not necessary to place an If to control transitions, in specific cases the layout may break.

### Describe the proposed solution

`<div transition:fade={{ show: true }}>`

### Alternatives considered

Set a parameter to control the state of the transition.

### Importance

nice to have
Repository: pytorch
Issue: torch._weight_norm with specified dim returns wrong output
Labels: module: nn,module: error checking,triaged,module: regression,module: norms and normalization

### 🐛 Describe the bug

# Problem
`torch._weight_norm` outputs wrong result from torch 1.12

Though `torch._weight_norm` is an undocumented API, I report this issue since the API is made public.

#### torch 1.11 and before
```python3
$ python3
Python 3.8.10 (default, Mar 15 2022, 12:22:08) 
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
>>> a = torch.Tensor([[1,2],[3,4]])
>>> b = torch.Tensor([[5],[6]])
>>> torch._weight_norm(a,b,dim=1)
tensor([[1.5811, 2.2361],
        [5.6921, 5.3666]])
```


#### torch 1.12
```python3
$ python3
Python 3.8.10 (default, Mar 15 2022, 12:22:08) 
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
>>> a = torch.Tensor([[1,2],[3,4]])
>>> b = torch.Tensor([[5],[6]])
>>> torch._weight_norm(a,b,dim=1)
tensor([[1.5811, 2.6833],
        [4.7434, 5.3666]])
```

#### manual computation
```python3
>>> def weight_norm_dim1(a, b):
...     norm = a.norm(2, [0], True)
...     return a * b / norm
... 
>>> weight_norm_dim1(a, b)
tensor([[1.5811, 2.2361],
        [5.6921, 5.3666]])
```

### Versions

```
Collecting environment information...
PyTorch version: N/A
Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.4 LTS (x86_64)
GCC version: (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0
Clang version: Could not collect
CMake version: version 3.22.2
Libc version: glibc-2.31

Python version: 3.8.10 (default, Mar 15 2022, 12:22:08)  [GCC 9.4.0] (64-bit runtime)
Python platform: Linux-5.4.0-100-generic-x86_64-with-glibc2.2.5
Is CUDA available: N/A
CUDA runtime version: Could not collect
GPU models and configuration: 
GPU 0: Tesla V100-SXM2-16GB
GPU 1: Tesla V100-SXM2-16GB
GPU 2: Tesla V100-SXM2-16GB
GPU 3: Tesla V100-SXM2-16GB
GPU 4: Tesla V100-SXM2-16GB
GPU 5: Tesla V100-SXM2-16GB
GPU 6: Tesla V100-SXM2-16GB
GPU 7: Tesla V100-SXM2-16GB

Nvidia driver version: 470.103.01
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.0.5
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A

Versions of relevant libraries:
[pip3] numpy==1.18.4
[pip3] torch==1.12.0
[pip3] torchvision==0.13.0
[conda] Could not collect
```

cc @ezyang @gchanan @zou3519 @albanD @mruberry @jbschlosser @walterddr @kshitij12345 @saketh-are
Repository: next.js
Issue: Multiple shallow route changes trigger `Route Cancelled` error
Labels: bug

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

    Operating System:
      Platform: linux
      Arch: x64
      Version: #1 SMP Wed Mar 2 00:30:59 UTC 2022
    Binaries:
      Node: 16.15.1
      npm: 8.11.0
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 12.2.2-canary.0
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0

### What browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

_No response_

### Describe the Bug

When using the router to do shallow route changes with `router.push`, the `routeChangeError` handler gets called on every one of the `router.push` calls after the first one. The event handler always receives the `Route Cancelled` error.

This seems to have been introduced in 12.2.0, as it does not happen in 12.1.6.


### Expected Behavior

The route change seemingly completes fine, so I don't see the reason why it should call `routeChangeError`.

### Link to reproduction

https://codesandbox.io/p/sandbox/dreamy-cannon-nkrkn6

### To Reproduce

- Run the linked app (dev or start does not matter)
- Click the `Test` button
- Click the button again
- The second time the event handler should fire and the error should be displayed in an alert and the dev console
Repository: pytorch
Issue: DISABLED test_trace_dependencies (test_analyze.TestAnalyze)
Labels: triaged,module: flaky-tests,skipped,module: deploy,oncall: package/deploy,imported

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_trace_dependencies&suite=test_analyze.TestAnalyze&file=package/test_analyze.py) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/7275940320).

Over the past 3 hours, it has been determined flaky in 1 workflow(s) with 1 red and 1 green.

cc @wconstab @bdhirsh @ezyang
Repository: flutter
Issue: The logic to set 'subtree_can_inherit_opacity' in 'DisplayListRasterCacheItem' doesn't look correct.
Labels: engine,P2,team-engine,triaged-engine

Before the PR https://github.com/flutter/engine/pull/31892 landed , `DisplayListLayer` will set `PrerollContext.subtree_can_inherit_opacity` to `true` when `DisplayList` being rasterized to a `SkImage`. 
https://github.com/flutter/engine/blob/3818fccc88e21f00f51acc1e9b98fa262ade11f7/flow/layers/display_list_layer.cc#L101-L103
```
if (cache->Prepare(context, disp_list, is_complex_, will_change_, matrix,
                   offset_)) {
  context->subtree_can_inherit_opacity = true;
}
```

But after the PR landed, there may be cases where `PrerollContext.subtree_can_inherit_opacity` is set to `true`, but the `DisplayList` is not rasterized to a `SkImage` finally. 

For example, suppose a new frame was originally intended to rasterize 4 `DisplayList`s to `SkImage`s, but we will only rasterize at most 3 of them in one frame, so the fourth `DisplayList` will not be rasterized, but `PrerollContext.subtree_can_inherit_opacity` has been set to `true`.

c.f.
https://github.com/flutter/engine/blob/557655b7f552804da2e6f45d0c863737c6be8a82/flow/layers/display_list_raster_cache_item.cc#L117
https://github.com/flutter/engine/blob/557655b7f552804da2e6f45d0c863737c6be8a82/flow/layers/display_list_raster_cache_item.cc#L156-L159

From the code logic point of view, the wrong setting of `subtree_can_inherit_opacity` may cause the rendering result of `OpacityLayer` and its subtrees to be incorrect in some scenarios. Please let me know if I missed something.

cc @flar @JsouLiang
Repository: pytorch
Issue: torch.fx.node.map_aggregate and torch.utils._pytree.tree_map do the same thing
Labels: triaged,module: fx,module: pytree

### 🐛 Describe the bug

Should deduplicate the implementations somehow

### Versions

master

cc @ezyang @SherlockNoMad @zou3519
Repository: angular
Issue: Clarify IE11 support state for `zone.js` / and clean-up zone.js code/tests for IE11-specific logic
Labels: area: zones,P3

### Which @angular/* package(s) are the source of the bug?

Don't known / other

### Is this a regression?

No

### Description

Angular no longer supports IE11, but it's not quite clear from the documentation whether `zone.js` is included in the angular.io browser guarantees, or if Zone has its own browser guarantees (given it also being versioned differently etc.)

If IE11 is no longer supported in ZoneJS either, ZoneJS tests and logic should be cleaned up to not contain any IE11 specific code. There are some IE11-specific tests for example though (these don't even run at this point anymore -- worth mentioning)
Repository: storybook
Issue: Message "applyDecorators was not supported :( !" on console.log
Labels: bug

**Describe the bug**
After upgrading Storybook to version 6.5, the following message appeared in the console:
`applyDecorators was not supported :( !`
Analyzing through the console itself, it was possible to see the code that sent the `console.log()`:
```js
// previous code

Object.keys(config).forEach(function (key) {
    var value = config[key];

    // others case statements

    case '__namedExportsOrder':
    case 'decorateStory':
    case 'renderToDOM':
      {
        return null; // This key is not handled directly in v6 mode.
      }

    default:
      {
        // eslint-disable-next-line prefer-template
        return console.log(key + ' was not supported :( !'); // HERE
      }
}
```
Locating the file that exports this function,  we can see that an alias named "applyDecorators" is applied to the "decorateStory" function:
```js
// @storybook/vue/dist/esm/client/preview/config.js

export { render, renderToDOM } from './render';
export { decorateStory as applyDecorators } from './decorateStory';
export var parameters = {
  framework: 'vue'
};
```
The problem: in the "switch" mentioned above, the code expects to receive a function named "decorateStory" for its correct treatment, but it is being exported as "applyDecorators", thus generating the console.log().

**System**
  OS: Linux 5.15 Ubuntu 22.04 LTS 22.04 LTS (Jammy Jellyfish)
  CPU: (8) x64 Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
  Binaries:
    Node: 14.19.3 - ~/.nvm/versions/node/v14.19.3/bin/node
    Yarn: 1.22.19 - /snap/bin/yarn
    npm: 6.14.17 - ~/.nvm/versions/node/v14.19.3/bin/npm
  Browsers:
    Chrome: 103.0.5060.114
Repository: storybook
Issue: ArgTypes configuration for array of objects
Labels: feature request,addon: controls

### Discussed in https://github.com/storybookjs/storybook/discussions/18680

<div type='discussions-op-text'>

<sup>Originally posted by **alexandermirzoyan** July 11, 2022</sup>
Hi all,
I have a web component which accepts an array of objects with a custom scheme. Is there any way how can I configure the pattern.
I want that icon property would accept only a select control.

Current config that I use.
```
argTypes: {
    options: {
      control: { type: 'array' },
      title: { control: 'text' },
      icon: { control: 'select', options: ICONS },
      action: { control: 'text' },
      link: { control: 'text' },
    },
  },
```
![image](https://user-images.githubusercontent.com/48055294/178282666-1caba584-e9f7-495d-9cfd-ab8b87d2d3b5.png)
</div>
Repository: vscode
Issue: Git - VS Code does not respect the diff flag in .gitattributes
Labels: bug,git

<!-- ⚠️⚠️ 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

<!-- 🪓 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. -->
- VS Code Version: 1.69.0
- OS Version: Windows 10.0.1.19044

**Steps to Reproduce:**

1. Open a local git repository in vscode
2. Make changes to a file `1.txt`, and then add this simple `.gitattributes` file:

        *.txt -diff

3. Confirm output of `git diff` on the terminal: `Binary files a/1.txt and b/1.txt differ`
4. View the diff from VS Code Source Control panel.

**Expected output:**

VS Code source control panel shows "No preview available, binary files a/1.txt and b/1.txt differ" or a similar message.

**Actual output:**

VS Code shows the plaintext diff.

![](https://i.stack.imgur.com/rZVOp.png)

**Context:** I intend to unset the diff flag for certain large auto-generated files in my project. If I accidentally open their diff on the VS Code Source Control, currently, there is a noticeable lag (less than a second) and the rendered diff itself is unusable anyway. So, I'd prefer if VS Code just didn't attempt to display the diff in the first place.

Cross-ref: [SO post](https://stackoverflow.com/questions/72760803/how-to-make-vs-code-respect-the-diff-flag-in-gitattributes) that I made two weeks ago about the same issue.
Repository: vscode
Issue: Commit split button divider causes loss of selection
Labels: bug,ux,polish,scm

Some things I noticed today was that the commit split button divider is a lot stronger than the other split buttons in the product. I also noticed when I hovered over the split buttons divider that I would then not have either portions of the buttons selected and instead be selecting the parent container.

<img width="293" alt="image" src="https://user-images.githubusercontent.com/4544166/178293148-590ca9a5-237b-4748-bdaa-476ada7daf2d.png">
Repository: flutter
Issue: [in_app_purchase][android] Add in-app messaging
Labels: c: new feature,platform-android,p: in_app_purchase,package,c: proposal,P3,team-android,triaged-android

As this plugin is migrated to the latest billing library version in recent commits it must add the in-app messaging feature introduced in version 4.1

Here is the link to the release notes https://developer.android.com/google/play/billing/release-notes#4-1

It describes a new feature "Added `BillingClient.showInAppMessages()`". 

In the migration to version 5.0 of `in_app_purchase` plugin it is missing the implementation of this feature.