sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Document with space at end of a comment generates format edit with overlapping ranges
Labels: Bug,Help Wanted,Effort: Moderate,Domain: Formatter,Rescheduled

Type: <b>Bug</b>

Install new instance of VS Code.

Create a .ts (typescript) file with the following:-

```
function noReformat(noReformat:string){
console.log(noReformat)
}

	// function fun(myVariable) {
	// 	let variable = myVariable;	// this line with whitespace at the end stops format document from working 
	// }
```

Open the file and press Shift-Alt-F to reformat.

Expected result: document reformats i.e. inserts some spaces.
Actual result: no reformatting occurs.

Then, remove the space at the end of line 6 (i.e. after the word working) and press Shift-Alt-F to reformat; result reformatting now works correctly.

VS Code version: Code 1.81.1 (6c3e3dba23e8fadc360aed75ce363ba185c49794, 2023-08-09T22:22:42.175Z)
OS version: Windows_NT x64 10.0.19045
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Pentium(R) CPU G2020 @ 2.90GHz (2 x 2900)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: disabled_off<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>multiple_raster_threads: disabled_off<br>opengl: enabled_on<br>rasterization: unavailable_off<br>raw_draw: disabled_off_ok<br>video_decode: enabled<br>video_encode: unavailable_off<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: enabled|
|Load (avg)|undefined|
|Memory (System)|5.70GB (0.53GB free)|
|Process Argv|C:\\Users\\Derek\\Desktop\\Test.ts --crash-reporter-id 0213dfee-3f65-4d85-841a-4c77b6df0f67|
|Screen Reader|no|
|VM|0%|
</details>Extensions: none<details>
<summary>A/B Experiments</summary>

```
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263cf:30335440
vscorecescf:30445987
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
pythonvs932:30410667
vsclangdc:30486549
c4g48928:30535728
dsvsc012cf:30540253
pynewext54:30695312
azure-dev_surveyone:30548225
vsccc:30803844
3biah626:30602489
89544117:30613380
showlangstatbar:30737416
962ge761:30823813
03d35959:30757346
pythonfmttext:30731395
fixshowwlkth:30771522
showindicator:30805244
pythongtdpath:30769146
i26e3531:30792625
pythonnosmt12:30797651
pythonidxpt:30805730
pythonnoceb:30805159
synctok:30821570
dsvsc013:30795093
dsvsc014:30804076
diffeditorv2:30821572
dsvsc015:30823817

```

</details>

<!-- generated by issue reporter -->
Repository: pytorch
Issue: [C++ Frontend] Simple Changes for Cleaner Options
Labels: module: cpp,triaged

### 🚀 The feature, motivation and pitch

The current implementation of many options in the high-level C++ frontend is rather clunky, due to the desire to replicate python's named arguments. I will be using `torch::data::DataLoaderOptions` as an example, but the issue applies to almost all functions. Here is an example from [the official tutorial docs](https://pytorch.org/tutorials/advanced/cpp_frontend.html): 
```c++
auto data_loader = torch::data::make_data_loader(
    std::move(dataset),
    torch::data::DataLoaderOptions().batch_size(kBatchSize).workers(2));
```
The use of naming the entire type, `torch::data::DataLoaderOptions`, makes the code unnecessary long and intimidating. It is more apparent when only on one line:
```c++
auto data_loader = torch::data::make_data_loader(std::move(dataset), torch::data::DataLoaderOptions().batch_size(kBatchSize).workers(2));
```
C++20's [designated initializers] would make this easier, as it allows braced initialization of data structs by naming individual specified members, leaving others default initialized. It is significantly cleaner and more concise, while also better aligning with the python API:
```c++
auto data_loader = torch::data::make_data_loader(std::move(dataset), { .batch_size = kBatchSize, .workers = 2 });
```
`DataLoaderOptions` and other options do not allow for aggregate initialization since it relies on the [`TORCH_ARG`](https://github.com/pytorch/pytorch/blob/main/torch/csrc/api/include/torch/arg.h) macro, which creates the args as private members, and since some have a user-defined constructor (e.g. `DataLoaderOptions(size_t batch_size)`). From what I can tell, creating them as private members has no advantage and is only to conform to a traditional OOP factory paradigm, so this change should be trivial. The other change of removing the constructor may be less favorable, but I believe the benefit to significantly outweigh the costs. Breaking backwards compatibility is a big deal, but even on older language standards, the fix for existing codebases is simply changing `torch::data::DataLoaderOptions(batch_size)` to `torch::data::DataLoaderOptions().batch_size(batch_size)`, which also leads to more readable code.

### Alternatives

_No response_

### Additional context

_No response_

cc @jbschlosser
Repository: terminal
Issue: `til::coalesce<T>` should be able to take a function that returns `T`
Labels: Help Wanted,Product-Meta,Issue-Task,Area-CodeHealth

From a teams chat

### example 1 

```c++
int Foo() {...}
optional<int> whatever { /*...*/ };
...

int a = til::coalese(whatever, Foo)
```

`Foo` only gets called if `whatever` is empty.

### example 2
```c++
class Foo{
  optional<int> _cached;
  int GetThing();
  int _generate();
}

int Foo::GetThing()
{
    _cached = coalesce(_cached, [&](){ return _generate(); });
    return _cached;
}
int Foo::_generate() { /*...*/ }
```

Look ma, now it's easy to implement lazy properties. So easy in fact...

### example 3 - `til::lazy_property<T>`

```c++
class Foo {
  til::lazy_property<int> Thing { { this, &Foo::_generate } }; // same syntax as winrt event handlers
  int _generate();
}

// ...

Foo foo{};
int x = foo.Thing(); // Calls _generate
int y = foo.Thing(); // Doesn't
foo.Thing.invalidate(); 
int z = foo.Thing(); // calls generate again
```

(maybe we don't do this one. Seems like it's potentially footgun-y)

---

This is a truly one of the ideas I had while working on `Profile::EvaluatedIcon` in #15843
Repository: PowerToys
Issue: Remap key shortcut should have precedence over remap key
Labels: Idea-Enhancement,Product-Keyboard Shortcut Manager

### Description of the new feature / enhancement

I want to turn off the left windows key. So I can map that key to nothing

However, I do want to have most common shortcuts from ctrl, mapped to the left windows key:
like cmd-s is ctrl-s (save)
cmd-c is ctrl-c   (copy)
etc etc

But now the moment I turn off the left-win key, none of the left windows key shortcuts work anymore.

So having key shortcuts have precedence would fix it: just tapping left windows key would do nothing, and only certain key shortcuts would be mapped


### Scenario when this would be used?

I want my windows machine to be more like the mac (because I also use this and muscle memory etc etc).
So I mapped most common CTRL shortcuts to left win shortcuts (which is CMD on my mac keyboard).

However, If I only tap left WIN, the start menu pops up. and I never want this, it loses focus of the app I was in.
So if I map left-WIN to nothing, that kills the LeftWIN key, but it also kills all my shortcuts.

So if you could change the precedence of shortcutmappings over key mappings all would be perfect.

downsides:  I don't think there are any

### Supporting information

_No response_
Repository: godot
Issue: X-Server unresponsive while debugging and tooltip pops up
Labels: bug,platform:linuxbsd,topic:porting

### Godot version

v4.1.1.stable.official [bd6af8e0e]

### System information

Godot v4.1.1.stable - Linux Mint 21 (Vanessa) - Vulkan (Compatibility) - NVIDIA GeForce RTX 3060 (nvidia; 535.86.05) - AMD Ryzen 5 2600X Six-Core Processor (12 Threads)

### Issue description

I used Godot4 with a project and run into an error in my gdscript. Then after moving the mouse over the hit line I got a X Server freeze.

After changing with Ctrl-1 to console and back to X and waiting around some seconds X and Godot unfreezes and I could continue.

I searched the bug reports and found some which sound similar:
#41574
#41614
#49973
#49973

### Steps to reproduce

This problem is 100% able to reproduce in my setup.

I could prevent the error with --single-window parameter. 

This is how the debug popup looks in case I start with single window.

![grafik](https://github.com/godotengine/godot/assets/16402165/e26aeb0f-782d-42d8-898d-cb1a65b85859)


### Minimal reproduction project
[TacticsExample.zip](https://github.com/godotengine/godot/files/12552659/TacticsExample.zip)
Repository: deno
Issue: Deno fmt fails (Preact component with comment)
Labels: bug,deno fmt

Executing `deno fmt` for the following example fails. Without line 7, the command executes normally.

```
import { ErrorPageProps } from "$fresh/server.ts";

export default function ErrorPage500(props: ErrorPageProps) {
  return (
    <pre>
      {props.url}
      {/* {props.url} */}
    </pre>
  );
}
```

Here is the output, with the `RUST_BACKTRACE` environment variable set to `full`:

```
============================================================
Deno has panicked. This is a bug in Deno. Please report this
at https://github.com/denoland/deno/issues/new.
If you can reliably reproduce this panic, include the
reproduction steps and re-run with the RUST_BACKTRACE=1 env
var set and include the backtrace in your report.

Platform: macos x86_64
Version: 1.36.3
Args: ["deno", "fmt"]

thread 'tokio-runtime-worker' panicked at 'Formatting not stable. Bailed after 5 tries. This indicates a bug in the formatter where it formats the file (/example/example.tsx) differently each time. As a temporary workaround you can ignore this file.', cli/tools/fmt.rs:456:11
stack backtrace:
   0:        0x10d583238 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h9da7574d41a27793
   1:        0x10c8df37b - core::fmt::write::h30e9018632f2aef2
   2:        0x10d5533e8 - std::io::Write::write_fmt::h56af08ec60343535
   3:        0x10d58888a - std::sys_common::backtrace::print::h4d81fafe758cf4b8
   4:        0x10d588662 - std::panicking::default_hook::{{closure}}::h120f229f25c70a74
   5:        0x10d588391 - std::panicking::default_hook::hceec3dccba707793
   6:        0x10c77403b - deno::setup_panic_hook::{{closure}}::h1b89c2061bf1036f
   7:        0x10d5892d5 - std::panicking::rust_panic_with_hook::h6683bf919d2bf510
   8:        0x10d589074 - std::panicking::begin_panic_handler::{{closure}}::h9ad2a0e8640ca3c3
   9:        0x10d588fd9 - std::sys_common::backtrace::__rust_end_short_backtrace::h1aa11996f1542333
  10:        0x10d588fc2 - _rust_begin_unwind
  11:        0x10e961cd3 - core::panicking::panic_fmt::hb305629a540f8ae6
  12:        0x10c4b44b9 - tokio::runtime::task::raw::poll::h0cf03c2ca89ad127
  13:        0x10d6c9831 - std::sys_common::backtrace::__rust_begin_short_backtrace::hadcf316cdea872e4
  14:        0x10d6c9615 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h8ca767e9ffe00028
  15:        0x10d58c0f9 - std::sys::unix::thread::Thread::new::thread_start::h7feade9417ac5384
  16:     0x7fff6fcea2eb - __pthread_body
  17:     0x7fff6fced249 - __pthread_start
```
Repository: pytorch
Issue: Dynamo Swallowing Exception In Lambda
Labels: triaged,oncall: pt2,module: dynamo,dynamo-must-fix,dynamo-symbolic-analysis

### 🐛 Describe the bug

Steps to reproduce:

- remove `@skipIfTorchInductor("AssertionError: RuntimeError not raised by <lambda>")` from `test_index_add_correctness` in `test_torch.py`
- run PYTORCH_TEST_WITH_INDUCTOR=1 python test/test_torch.py -k test_index_add_correctness, will get error:

```
FAIL: test_index_add_correctness (__main__.TestTorch)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test/test_torch.py", line 6046, in test_index_add_correctness
    self.assertRaises(RuntimeError, lambda: result.index_add_(dim, index, source))
  File "/scratch/eellison/work/pytorch/torch/testing/_internal/common_utils.py", line 3321, in assertRaises
    return super().assertRaises(expected_exception, *args, **kwargs)
AssertionError: RuntimeError not raised by <lambda>
```

Now, if you rewrite the test to just invoke the code which is supposed to throw:

```
diff --git a/test/test_torch.py b/test/test_torch.py 
index ffcf3bfcf07..de340b1500d 100644
--- a/test/test_torch.py
+++ b/test/test_torch.py
@@ -6044,9 +6044,7 @@ class TestTorch(TestCase):
                 result = torch.zeros(1, 512, 256, dtype=dtype)
                 source = torch.ones(1, 512, 256, dtype=dtype)
                 index = torch.ones(257).to(dtype=torch.long)
-                self.assertRaises(RuntimeError, lambda: result.index_add_(dim, index, source))
-                index = (torch.ones(256) * 257).to(dtype=torch.long)
-                self.assertRaises(RuntimeError, lambda: result.index_add_(dim, index, source))
+                result.index_add_(dim, index, source)
```

And re-run the test and an exception is thrown:
> RuntimeError: index_add_(): Number of indices (257) should be equal to source.size(dim): (256), for dim: 2

I think somehow the exception in the lambda is being swallowed within dynamo. I'm not sure of root cause. You can verify that this code snippet throws in a stand alone script:

```
import torch

@torch.compile()
def foo():
    dtype = torch.float
    dim = -1
    result = torch.zeros(1, 512, 256, dtype=dtype)
    source = torch.ones(1, 512, 256, dtype=dtype)
    index = torch.ones(257).to(dtype=torch.long)
    result.index_add_(dim, index, source)
    return result

foo()
```



### Versions

master

cc @ezyang @anijain2305 @chauhang @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @msaroufim @bdhirsh @zou3519 @aakhundov @wconstab @Xia-Weiwen
Repository: go
Issue: compress/zstd: add new package
Labels: Proposal,Proposal-Accepted

Zstandard ([RFC 8878](https://datatracker.ietf.org/doc/html/rfc8878)) is well-positioned to replaced GZIP ([RFC 1952](https://datatracker.ietf.org/doc/html/rfc1952)) as the de-facto compression format.

Zstandard:
* is [faster to compress/decompress](https://facebook.github.io/zstd/#benchmarks) than GZIP,
* has [much better compression ratios](https://github.com/golang/go/issues/62446#issue-1880889127),
* is [well-specified](https://datatracker.ietf.org/doc/html/rfc8878), 
* is [backed by a prominent company](https://github.com/facebook/zstd), and 
* is seeing increased adoption in use with archives and as a [browser content encoding](https://chromestatus.com/feature/6186023867908096).
 
Given the likely ubiquitous place Zstandard is going have in the future, I propose first-class adoption of Zstandard in the stdlib.

Existing Go implementations:
* @klauspost has an excellent Zstandard implementation at [github.com/klauspost/compress/zstd](https://pkg.go.dev/github.com/klauspost/compress/zstd), but the API is a somewhat complex and it makes use of native assembly.
* @ianlancetaylor implemented a Zstandard decompressor in [internal/zstd](https://github.com/golang/go/tree/master/src/internal/zstd) without any use of `unsafe` or assembly.

Some goals for this package:
* The API be simple and similar to existing packages like `compress/gzip`.
* It does not use `unsafe` or assembly similar to the existing compress package.
  * Performance is always nice, but Go community surveys consistently shows security as more important than performance.
  * Users who just need a decently fast enough Zstandard implementation can use `compress/zstd`, while those want the best performance and/or advanced features of Zstandard can use @klauspost's package. Any stdlib packages (e.g., `net/http` that make use of `compress/zstd` should make it possible to swap over to a different `zstd` implementation).
  * Note that the same is already true of `compress/gzip`, which is generally good enough (although there is still room for performance optimizations), but power users can use [github.com/klauspost/compress/gzip](https://pkg.go.dev/github.com/klauspost/compress/gzip), which is much faster (as it makes use of assembly).

We could:
* adopt @klauspost's pure-Go (i.e., no assembly) implementation with a cleaned-up API
* extend @ianlancetaylor's work to support compressing
* do a combination of both

Related issues:
* #62492
* #55107
* #62446
Repository: godot
Issue: Skeleton2D causing spam of errors in editor due to ModificationStack
Labels: bug,topic:editor,topic:animation

### Godot version

4.1.1

### System information

Windows 10

### Issue description

A Skeleton2D with at least one ModificationStack using InverseKinematics or other specific elements causes several errors by default, as the default values of the indexes are -1, something already reported #80012 #76712. Changing the default value to 0 should suffice to stop the initial error spam. 


Adding a scene/entity with a Skeleton2D with one or more problematic modifications to another scene, even if the original ModificationStack is marked as not Enabled, and duplicating the entity will spam the output with the following error:

`Modification stack is not properly setup and therefore cannot execute!`

Changing the editor to look at a different scene will stop the error from spamming. If, however, you head to the scene with the Skeleton2D, the spam will continue. While there, it will only stop if you reset the ModificationStack property. An Undo (CTRL + Z) right afterwards won't cause the errors to show.
In the scene importing the Skeleton, the spam will only stop if you delete all the skeleton scenes.


Another situation that arose: if you import (drag and drop) another copy of the Skeleton2D scene, the error spam will be the following instead:

`Drawing is only allowed inside NOTIFICATION_DRAW, _draw() function or 'draw' signal.`

Once you click and start dragging, as soon as it enters the editor window, it will throw 20-40 lines of the error above, you don't even need to release the mouse button. The error above stops as soon as you delete the lastly imported scene. If you delete the ModificationStack (reset it to empty, default) and save, the error stops on the scene with the import. If, however, you Undo (Ctrl + Z), save, and return to the scene while it still has 2 or more of the Skeleton, the Drawing error spam will return.

Neither of these errors will happen if the skeleton scene has NO ModificationStack (empty)

### Steps to reproduce

Create a scene with a Skeleton2D and at least 2 bones and 1 Node2D to be the IK Target.
Add a ModificationStack to the Skeleton2D.
Add a InverseKinematic to the Stack, set it up properly with the bones and IK Target
Save the Skeleton2D
Create a new scene
Import the saved Skeleton2D

For the first error:
- Duplicate the imported Skeleton2D

For the second error:
- Drag and drop another Skeleton2D in the scene

### Minimal reproduction project

[bone-problem.zip](https://github.com/godotengine/godot/files/12552947/bone-problem.zip)

In the Main.tscn, you can attempt to duplicate the existing skeleton `Duplicate-for-error`, or drag and drop `skelly.tscn` from the resources tree into the scene. Both situations will cause an error.

If you modify `skelly.tscn`, removing the ModificationStack, no errors will occur.
Repository: TypeScript
Issue: Instantiations of constrained generic signatures allow all assignments
Labels: Bug,Domain: Variance Relationships

### 🔎 Search Terms

variance generic signature measurement

### 🕗 Version & Regression Information

This has been our behavior forever as far as I can tell - in fact, I've seen this pattern used once or twice to work around other bugs, even though the behavior is in no way safe.

### ⏯ Playground Link

https://www.typescriptlang.org/play?#code/C4TwDgpgBAYgdgHgCoD4oF4oIKpQgD2AjgBMBnKVACnwC4psBKDNbAbgCgPRIoBhAPZwAxgCcIRAIwYsuAkVIU4AVwC2AIwiiUNekxYNOPaIJHiiAJhk48hYuShlgogJZwA5jroNm6Vpw4AM2URYBchKEDkSQAaSgsdYEl6eGiUOOALFMQkBLjhZP4hMQkIWKhhLKKzUotmAG8OKGaoAHpWvAA3LRBHN3cAG2ghYcCoYAALCDJoAEMyMhd3OFViYAoyCYFlAZI8UVEBUS4W8elMTLY2js3t3f3D0Tj1ZWAoEgFpuAByYCaWzIyJJXdqOLY7PZaR7PV7vT5kH5-f7NAoySqcU6VNGSAKnJLYjEtVEXHEcAC+QA

### 💻 Code

```ts
type Fn<T> = <U extends T>(x: U) => U;

type Concrete1 = <U extends number>(x: U) => U;
type Concrete2 = <U extends string>(x: U) => U;

function f<T1, T2>(t1: Fn<T1>, t2: Fn<T2>, c1: Concrete1, c2: Concrete2) {
    // every single one of these assignments should error

    t1 = t2; // should error, but doesn't
    t2 = t1; // should error, but doesn't

    c1 = c2;
    c2 = c1;

    t1 = c1;
    c1 = t1;
}
```

### 🙁 Actual behavior

Missing two errors on the generic relationships.

### 🙂 Expected behavior

All of the assignments are errors, as the generic relationship should be even stricter than the non-generic one.

### Additional information about the issue

The issue lies in our variance analysis - we currently incorrectly measure `T` as _independent_, which is quite different from the _invariant_ it should adopt (via `U`'s invariant usages). This discrepancy arises because of some oddities in how we do generic signature relationships.
Repository: neovim
Issue: Crash: vim.uv.walk
Labels: bug-crash,event-loop,lua

### Problem

Using `vim.loop.walk` in any way results in nvim crashing with a segmentation fault (same for `vim.uv.walk`).

### Steps to reproduce

```
$ env -i nvim --clean -es +'lua vim.loop.walk(function() print("ohai") end)'
vim: src/loop.c:85: luv_walk_cb: Assertion `data && data->ref < 0x1000000' failed.
Aborted (core dumped)
```

I got that particular message from v0.4.4. Newer versions crash silently (seems worse, to me).

### Expected behavior

Print `ohai` a bunch of times.

### Neovim version (nvim -v)

NVIM v0.10.0-dev-1046+g3afbf4745, NVIM v0.9.1, NVIM v0.4.4

### Vim (not Nvim) behaves the same?

n/a

### Operating system/version

$ uname -a Linux penguin 5.15.117-19679-g172023e664f7 #1 SMP PREEMPT Fri Aug 18 18:07:47 PDT 2023 x86_64 GNU/Linux

### Terminal name/version

hterm

### $TERM environment variable

n/a

### Installation

source, brew, debian (respectively)