sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Align with another line to bring the diff back in sync
Labels: feature-request,diff-editor

<!-- ⚠️⚠️ 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. -->
Moved from here: https://github.com/microsoft/monaco-editor/issues/3188

The result of the comparer is sometimes insufficient.

In some cases we have an additional and similar code block on one file which leads to the issue that the similar content will be compared and it will not be recognized as additional block. This leads to a diff which is out of sync.

Another case is a differentiation of the order of the file content like shown below.

For both cases I would like to have the option to select a line on each side and start the comparison again from that line. From my understanding this will sync the diff again.

We currently use Beyond Compare and the option "Align With" another line on the other file to achieve that. Our goal is to integration the Monaco Editor as a comparer in our software.

Current result of VS Code is:

<img width="1373" alt="image" src="https://user-images.githubusercontent.com/32816888/180407245-ca27b5b7-8cfe-4877-b3ab-1c8142aa0047.png">

Result of Beyond Compare is this

<img width="1824" alt="image" src="https://user-images.githubusercontent.com/32816888/180410037-1527d58b-df8e-486d-8c0c-0ae6ac13062a.png">

Plus, BC has the feature to align for instance line 36 left with line 24 right and continue the diff from here like so:

<img width="1789" alt="image" src="https://user-images.githubusercontent.com/32816888/180407660-77394f95-6e1e-44a3-a6a1-19e1a2f96634.png">

[files-to-compare.zip](https://github.com/microsoft/vscode/files/9166444/files-to-compare.zip)
Repository: vscode
Issue: Merge editor should react to base, input1, input2 changing or deletion
Labels: under-discussion,merge-editor

related to https://github.com/microsoft/vscode/issues/155933

* git merge something
* open our merge editor
* run `git merge --abort`
* the input1 and input2 slots go empty

We will add special logic to detect this case (empty being the empty string) and will replace the merge editor with the corresponding result editor. However, we need a better solution for this, e.g ignore changes to base, input1, and input2. We could do that by working off copies of the three input files
Repository: terminal
Issue: Support multiple pixel shaders to be applied on the terminal texture buffer
Labels: Help Wanted,Area-Rendering,Product-Terminal,Issue-Task

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

# Allow multiple pixel shaders to be specified

Current configuration allows the user to specify a single pixel shader. It'd be useful if the parameter could be a list of shaders to be applied in order, for instance, distorting the screen to make it match a CRT tube (could be be even specified as two shaders, one for horizontal curvature that, if applied alone, would simulate a Trinitron tube, and other for the vertical curvature) and another to simulate raster artifacts.

# Proposed technical implementation details (optional)

I'd keep the current syntax that accepts a single string for single shaders, and also accept a list of strings for multiple shaders to be applied in order.
Repository: TypeScript
Issue: Attach Documentation to Labeled Tuple Elements
Labels: Suggestion,Help Wanted,Experience Enhancement

# Suggestion

I often find myself describing function params as labeled tuples. A simple example:

```ts
type AddArgs = [a: number, b: number];
function add(...[a, b]: AddArgs): number {
  return a + b;
}
```

Unfortunately, this approach prevents us from attaching tsdocs to the params. The following does not work :/

```ts
type AddArgs = [a: number, b: number];
/**
 * @param a the first number
 * @param b the second number
 */
function add(...[a, b]: AddArgs): number {
  return a + b;
}
```

I propose that one be able to attach tsdocs to labeled tuple elements, just as one does to object keys.

```ts
type AddArgs = [
  /** the first number */
  a: number,
  /** the second number */
  b: number,
];
```

I also propose that––when spread in place of function params––these tsdocs are treated as if they were the result of `@param` annotations on the function declaration.

## 🔍 Search Terms

Documentation, labeled, tuple, elements, tsdocs, signature

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: vscode
Issue: Conflict and change traversal buttons have the same icons in the compare changes view.
Labels: bug,merge-conflict

<!-- ⚠️⚠️ 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.1
- OS Version: MacOS Monterey 12.4 (21F79)

Steps to Reproduce:

1. Open merge conflict.
2. Choose "Compare changes".

<img width="133" alt="Screenshot 2022-07-22 at 13 27 43" src="https://user-images.githubusercontent.com/2445818/180429995-c797616c-a025-4c06-95d3-7aced3665ef2.png">

"Previous Conflict" and "Previous Change" have the same icon. "Next Conflict" and "Next Change" have the same icon. There is no text accompanying the icons so you have to hover the cursor over the icon to be sure how you're traversing the diff.

This is a UX bug.
Repository: animate.css
Issue: Naming mistake in animate.css flippers (X and Y axis)
Labels: bug,v5

### Describe The Bug

I noticed in animate.css that the flipper animations are named incorrectly. 'X axis' is mistaken for 'Y axis.'

*flipInX and flipOutX should flip horizontally on X axis but they flip vertically on Y axis.
*flipInY and flipOutY should flip vertically on the Y axis but they flip horizontally on the X axis.

### Steps To Reproduce

_No response_

### Expected Behavior

_No response_

### Screenshots

_No response_

### Desktop

_No response_

### Smartphone

_No response_

### Additional Context

_No response_
Repository: vscode
Issue: Git - Offer option to set default in branch name picker
Labels: feature-request,git

![image](https://user-images.githubusercontent.com/2931520/180432353-8e5d745d-a49e-4efd-ba0d-93f2c947fa4d.png)

There is a setting to set the default.
It would be nice to somehow link to it here, so that the setting becomes more discoverable.
Repository: rust
Issue: `repr(Rust)` unions (including `MaybeUninit`) do not preserve padding bytes
Labels: A-ABI,T-opsem

The following program isn't detected to have any UB in miri, and doesn't hit the panic, but *does* panic when ran (with or without optimizations) normally (using LLVM)

```rust
use std::mem::MaybeUninit;

unsafe fn print(x: MaybeUninit::<(u16, u8)>) {
    let value: u32 = std::mem::transmute(x);
    if value != 0xaabbccdd {
        panic!("got {value:x}");
    }
}

fn main() {
    let mut x = MaybeUninit::<(u16, u8)>::uninit();
    unsafe {
        x.as_mut_ptr().cast::<u32>().write_unaligned(0xaabbccdd);
        print(x);
    }
}
```

Panics with "`got bbccdd`", so the padding byte, presumably at `aa`, got zeroed.

The LLVM IR for `print` says it passes it as 2 arguments, so it makes sense that the padding is getting zeroed.

`define void @_ZN10playground5print17hfd0afe434a63e3b7E(i16 %x.0, i8 %x.1) unnamed_addr #0 [...]`

We (might?) already promise that MaybeUninit<T> is just a bag of bytes that doesn't zero any padding, but we also promise that it has the ABI of T, and those two seem to be in conflict.

Relates to https://github.com/rust-lang/unsafe-code-guidelines/issues/354#issuecomment-1192567007=
Repository: pytorch
Issue: test_sparse_spdiags_cpu_bool fails on my local working copy
Labels: module: sparse,triaged

### 🐛 Describe the bug

Error looks like

``` ======================================================================                                              
ERROR: test_sparse_spdiags_cpu_bool (__main__.TestSparseCPU)                                                        
----------------------------------------------------------------------                                              
Traceback (most recent call last):                                                                                  
  File "/data/users/ezyang/pytorch-tmp/torch/testing/_internal/common_device_type.py", line 377, in instantiated_tes
t                                                                                                                   
    result = test(self, **param_kwargs)                                                                             
  File "/data/users/ezyang/pytorch-tmp/torch/testing/_internal/common_device_type.py", line 970, in only_fn         
    return fn(slf, *args, **kwargs)                                                                                 
  File "/data/users/ezyang/pytorch-tmp/test/test_sparse.py", line 3632, in test_sparse_spdiags                      
    check_valid(*case)                                                                                              
  File "/data/users/ezyang/pytorch-tmp/test/test_sparse.py", line 3590, in check_valid                              
    ref_out = reference(diags, offsets, shape)                                                                      
  File "/data/users/ezyang/pytorch-tmp/test/test_sparse.py", line 3583, in reference                                
    data = data[off:]                                                                                               
IndexError: slice() cannot be applied to a 0-dim tensor.                                                            
                                                                                                                    
----------------------------------------------------------------------      
```

Not sure why it's only my local copy.

### Versions

master

cc @nikitaved @pearu @cpuhrsch @amjames
Repository: storybook
Issue: The context object is not updated when overriding the MDX docs container
Labels: bug,needs triage

**Describe the bug**

The context object is not updated when overriding the MDX docs container within `.storybook/preview.tsx` following https://github.com/storybookjs/storybook/blob/next/addons/docs/docs/recipes.md#overwriting-docs-container

**To Reproduce**

Reproduction Repo: https://github.com/adambulmer/storybook-docs-container-bug-reproduction

```js
import { DocsContainer } from "@storybook/addon-docs";

export const parameters = {
  actions: { argTypesRegex: "^on[A-Z].*" },
  controls: {
    matchers: {
      color: /(background|color)$/i,
      date: /Date$/,
    },
  },
  docs: {
    container: ({ context, children }) => {
      const { theme } = context.globals;

      console.log("Context Object Stuck", context);
      console.log("theme value stuck ---->", theme);

      return <DocsContainer context={context}>{children}</DocsContainer>;
    },
  },
};

export const globalTypes = {
  theme: {
    name: "Brand",
    description: "Theme selector",
    defaultValue: "default_item",
    toolbar: {
      icon: "eye",
      items: [
        { value: "default_item", title: "Default Item" },
        { value: "item_two", title: "Item Two" },
      ],
      showName: true,
    },
  },
};
```

**System**

```
  System:
    OS: macOS 12.4
    CPU: (8) arm64 Apple M1
  Binaries:
    Node: 16.15.1 - ~/.nvm/versions/node/v16.15.1/bin/node
    Yarn: 1.22.0 - ~/.nvm/versions/node/v16.15.1/bin/yarn
    npm: 8.11.0 - ~/.nvm/versions/node/v16.15.1/bin/npm
  Browsers:
    Chrome: 103.0.5060.134
    Safari: 15.5
  npmPackages:
    @storybook/addon-actions: ^6.5.9 => 6.5.9 
    @storybook/addon-essentials: ^6.5.9 => 6.5.9 
    @storybook/addon-interactions: ^6.5.9 => 6.5.9 
    @storybook/addon-links: ^6.5.9 => 6.5.9 
    @storybook/builder-webpack4: ^6.5.9 => 6.5.9 
    @storybook/manager-webpack4: ^6.5.9 => 6.5.9 
    @storybook/react: ^6.5.9 => 6.5.9 
    @storybook/testing-library: ^0.0.13 => 0.0.13 
```

**Additional context**

https://user-images.githubusercontent.com/58690589/180456460-9a5f5c2b-2d60-4260-923d-0239bc75a901.mp4
Repository: pytorch
Issue: test_sparse_matmul_cpu_complex128 fails on my local copy
Labels: module: sparse,triaged,module: complex

### 🐛 Describe the bug

```
======================================================================
FAIL: test_sparse_matmul_cpu_complex128 (__main__.TestSparseCPU)
This function test `torch.sparse.mm` when both the mat1 and mat2 are sparse tensors.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/raid/ezyang/pytorch-scratch2/torch/testing/_internal/common_device_type.py", line 377, in instantiated_test
    result = test(self, **param_kwargs)
  File "/raid/ezyang/pytorch-scratch2/torch/testing/_internal/common_utils.py", line 978, in wrapper
    fn(*args, **kwargs)
  File "/raid/ezyang/pytorch-scratch2/torch/testing/_internal/common_utils.py", line 3226, in wrapped
    f(self, *args, **kwargs, coalesced=True)
  File "test/test_sparse.py", line 3484, in test_sparse_matmul
    test_sparse_matmul(2, 10, [n, m], [m, p])
  File "test/test_sparse.py", line 3458, in test_sparse_matmul
    grad_with_custom_sparsity_pattern_test_helper(sparse_dims, nnz, shape_a, shape_b)
  File "test/test_sparse.py", line 3428, in grad_with_custom_sparsity_pattern_test_helper
    self.assertEqual(a.grad, a_grad)
  File "/raid/ezyang/pytorch-scratch2/torch/testing/_internal/common_utils.py", line 2364, in assertEqual
    assert_equal(
  File "/raid/ezyang/pytorch-scratch2/torch/testing/_comparison.py", line 1093, in assert_equal
    raise error_metas[0].to_error(msg)
AssertionError: Sparse COO values are not close!

Mismatched elements: 4 / 4 (100.0%)
Greatest absolute difference: 3.3639772140974413 at index (2,) (up to 1e-07 allowed)
Greatest relative difference: 2.0993343823035606 at index (0,) (up to 1e-07 allowed)

----------------------------------------------------------------------
```

This is on a CUDA 11.6 build

### Versions

master

cc @nikitaved @pearu @cpuhrsch @amjames @ezyang @anjali411 @dylanbespalko @mruberry @Lezcano
Repository: godot
Issue: VoxelGI: infinite errors with integrated graphics
Labels: bug,topic:rendering,topic:3d

### Godot version

v4.0.alpha.custom_build [f37990ed7]

### System information

Arch Linux, CPU: i7-8700K, iGPU: Intel UHD 630, dGPU: Nvidia RTX 2080

### Issue description

If I put a VoxelGI in a scene and bake it, the console displays an infinitely growing list of errors. It only happens with the integrated graphics, the Nvidia is fine.
Internal console:
```
Image (binding: 19) should provide one ID referencing a texture (IDs provided: 0).
drivers/vulkan/rendering_device_vulkan.cpp:8162 - Condition "!uniform_set" is true.
Uniforms were never supplied for set (0) at the time of drawing, which are required by the pipeline
```
Console:
```
ERROR: Image (binding: 19) should provide one ID referencing a texture (IDs provided: 0).
   at: uniform_set_create (drivers/vulkan/rendering_device_vulkan.cpp:5922)
ERROR: Condition "!uniform_set" is true.
   at: compute_list_bind_uniform_set (drivers/vulkan/rendering_device_vulkan.cpp:8162)
ERROR: Uniforms were never supplied for set (0) at the time of drawing, which are required by the pipeline
   at: compute_list_dispatch (drivers/vulkan/rendering_device_vulkan.cpp:8361)
```

### Steps to reproduce

1. Create a new project
2. Create e new 3D scene
3. Add a VoxelGI
4. Bake
5. View the output

### Minimal reproduction project

_No response_
Repository: pytorch
Issue: backwards compatibility ALLOWLIST is misused
Labels: module: ci,triaged

### 🐛 Describe the bug

We now check against backwards incompatibility from the base commit (vs the most recent nightly), but the ALLOWLIST has never worked the way it was intended to. My understanding of the ALLOWLIST is that for every function + date we set, we allow the function to be "backwards incompatible" until the date.

What actually happens in CI is that the function is incompatible for at most a day, and we allow it to be incompatible for eternity until someone comes and adds back the lost schema. 

To illustrate:
commit a -> function exists
commit b -> function doesn't exist
.
.
.
commit c -> function doesn't exist

The check will complain at commit b that the function being lost is backwards incompatible as we're comparing the schema of b and a. After some time, the check will compare commits to a newer commit, so commit c will no longer complain about the function being missing (whether the new commit is a new nightly or just a newer commit)! 

## What we can do
1. If we continue letting the bc test in CI currently check for immediate regressions only, we should build some mechanism to create an issue or more permanently warn us when something has introduced incompatibility. Before we implement this, the OSS CI oncall would have to be hyper aware when these errors arise + notify/create an issue. In this case, we can treat the modify the current ALLOWLIST to be a list of schemas we know have regressed + also ensure we track which commit since it has regressed. This way, we can have a system of verifying when something leaves the regression list. 

2. We can also make the bc test on trunk compare against a longer term previous schema/something that represents what we promise to users. Unfortunately, this wouldn't be as easy as pinning it to an old commit, since that commit wouldn't have any new schemas added since then. 

Do people like 1 or 2 better? 

Realization happened in PR description of https://github.com/pytorch/pytorch/pull/81980.

### Versions

CI

cc @seemethere @malfet @pytorch/pytorch-dev-infra
Repository: pytorch
Issue: nn.InstanceNorm and nn.GroupNorm are affected by padding, so they need to masking
Labels: triaged,module: nestedtensor,module: norms and normalization,module: padding,module: masked operators

### 🐛 Describe the bug

For batch_size > 1, variable-length inputs (e.g. speech, text) are padded in order to construct one batch tensor.

**When this tensor goes through nn.InstanceNorm series (nn.InstanceNorm1d, nn.InstanceNorm2d, ...) or nn.GroupNorm,
the calculations of mean and variance take the padded dummies altogether.**

This causes harmful batch inconsistency problem.

**So, nn.InstanceNorm and nn.GroupNorm must be modified to take valid input lengths and to mask out the padded dummies during calculating mean and variance.**

Sorry for not attaching example code.

### Versions

PyTorch version: 1.12.0

cc @ezyang @gchanan @zou3519 @cpuhrsch
Repository: svelte
Issue: Allow specifying non-special bindings as readonly
Labels: feature request,awaiting submitter

### Describe the problem

Currently there appears to be no way to define a components binding as readonly, this is supported on special inbuilt elements, such as `input`, `video` and `audio` (for example, for "read_only_media_attributes") but Svelte currently lacks support for specifying anything outside of inbuilt elements as a readonly binding.

Looking through the source, it looks like the binding type is decided around here, and is conditioned based on the type of element:

https://github.com/sveltejs/svelte/blob/master/src/compiler/compile/nodes/Binding.ts#L88

Sorry if this has already been discussed but I couldn't find an existing issue covering this topic.

### Describe the proposed solution

We should have some way of specifying a readonly binding, for example, by using the reserved `export let $variable` syntax:

Foo.svelte:
```svelte
<script>
  import {onMount} from 'svelte';
  export let $foo = 0;
  
  onMount(() => {
   const t = setTimeout(() => {
     foo++;
   }, 100);
   return (() => {
     clearTimeout(t)
   });
  });
</script>
```

App.svelte
```svelte
<script>
  import Foo from './Foo.svelte';
  let foo;
</script>
<Foo bind:foo />
<h1>{foo}</h1>
```

I'm not aware of if this syntax is intended for something else, someone might be able to chime in and suggest something that might be better suited and fit in better with the general design of Svelte.

### Alternatives considered

We'd like this to warn developers not to write to certain values to components as they won't affect anything, since the component that's providing those bindings is doing some side effect that isn't controllable from the parent component.

If they do, it doesn't directly affect any result (nothing happens), so our alternative solution is just to mark these bindings as readonly in our JSDoc.

### Importance

nice to have
Repository: pytorch
Issue: Unify c10::Event and at::cuda::CUDAEvent
Labels: module: cuda,triaged,better-engineering

### 🐛 Describe the bug

They are two implementations of essentially the same thing. CUDAEvent has a slightly more expansive API, and it also seems to support IPC events which the basic c10::Event doesn't support. It still makes sense to have a c10::cuda::CUDAEvent, but the shared functionality should live only in one place.

cc @ngimel @lw 

### Versions

master