sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: `RawVec` sets capacity incorrectly, causing potentially many bugs
Labels: A-allocators,A-collections,T-libs,A-slice

There are two "capacity"s for any successful allocation: the requested capacity and the returned capacity. The `Allocator` trait explicitly allows these to [not be the same](https://github.com/rust-lang/rust/blob/cdddcd3bea35049dab56888d4391cb9b5b1b4491/library/core/src/alloc/mod.rs#L114). However, it appears that `RawVec` assumes they are the same.

Everywhere `RawVec` request an allocation, it then sets its internal `cap` field for the capacity to be equal to the requested capacity, not the returned capacity The canonical example of this is [here](https://github.com/rust-lang/rust/blob/cdddcd3bea35049dab56888d4391cb9b5b1b4491/library/alloc/src/raw_vec.rs#L192), when a new `RawVec` is constructed with a given capacity (though the same behaviour also applies when growing allocation). The comment even states

> // Allocators currently return a `NonNull<[u8]>` whose length
> // matches the size requested. If that ever changes, the capacity
> // here should change to `ptr.len() / mem::size_of::<T>()`.

which directly contradicts the docs for the `Allocator` trait.

In principle, we could design `RawVec` to only store and report the requested capacity and that could be an entirely sound design. However, I worry that the assumption embodied by this comment has wormed its way throughout the standard library and probably the ecosystem. For example, if breaking apart a `Vec`-based structure to send for FFI, the docs until recently strongly suggested that `Vec::capacity` would return the allocated capacity (which is only true if the allocator always returns the requested capacity). In #99790 the docs are currently being updated to reflect that this isn't the case. 

Another example of where this is problematic is [`Vec::to_raw_parts`](https://github.com/rust-lang/rust/blob/cdddcd3bea35049dab56888d4391cb9b5b1b4491/library/alloc/src/vec/mod.rs#L820) which clearly assumes that `RawVec::cap` is the allocator returned capacity. I worry that this assumption is implicitly present through a lot of code.

I suggest therefore
1. Fix `RawVec`s allocation methods to store the capacity returned from the allocator, unfortunately requiring an extra division to do so
2. Review the documentation of `RawVec` and structures that use it to ensure that it is clear that `capacity()` may return more than what was requested, and associated methods
3. Looking forward: discuss whether we should guarantee that `capacity()` returns exactly the allocator returned capacity, and for which datastructures.

The alternative that I see is to instead commit to `RawVec::cap` being the requested capacity. In which case, it would be good to review where this may have been assumed elsewhere and what might need to be fixed. Happy to hear views on whether people think this would be a better path.
Repository: PowerToys
Issue: Where is Plus (numpad)?
Labels: Product-Keyboard Shortcut Manager,Needs-Triage

### Description of the new feature / enhancement

When I try to make this mapping I cannot see `+ (numpad)` in the list of keys to remap.

### Scenario when this would be used?

I want to map another key combination (something completely unused like alt-F12) to Ctrl-Plus (numpad), as that autosizes columns, as my laptop doesn't have a numeric keypad.

### Supporting information

https://www.howtogeek.com/28734/how-to-resize-all-window-columns-with-a-single-keystroke/
Repository: godot
Issue: VisibleOnScreenEnabler causes error when used with NavigationAgent Avoidance
Labels: topic:physics

### Godot version

v4.1.2.stable.official [399c9dc39]

### System information

Windows 11, Vulkan

### Issue description

When a VisibleOnScreenEnabler2D is paired with a CharacterBody2D using avoidance on a NavigationAgent2D the velocity_computed signal generates and error if attempting to set the velocity and call move_and_slide.

The error is:
```
E 0:00:00:0481   agent.gd:5 @ _on_navigation_agent_2d_velocity_computed(): Condition "!body->get_space()" is true. Returning: false
  <C++ Source>   servers/physics_2d/godot_physics_server_2d.cpp:997 @ body_test_motion()
  <Stack Trace>  agent.gd:5 @ _on_navigation_agent_2d_velocity_computed()
```

In the attached minimal reproduction project this error occurs only once, however in a different project this error happens every frame if more than 1 of the same agent is in the scene.

### Steps to reproduce

1. Create a CharacterBody2D
2. Add CollisionShape2D, VisibleOnScreenEnabler2D, and NavigationAgent2D nodes to the CharacterBody2D
3. Connect the velocity_computed signal of the NavigationAgent2D node to the CharacterBody2D
4. In the signal callback function add:
```
	velocity = safe_velocity
	move_and_slide()
```
5. Add the CharacterBody2D to a Node2D scene
6. Run the scene
7. Observe the error


### Minimal reproduction project

[NavAgentSafeVelocity.zip](https://github.com/godotengine/godot/files/12850824/NavAgentSafeVelocity.zip)
Repository: vscode
Issue: Crashes when pasting file name
Labels: bug,freeze-slow-crash-leak,linux,workbench-os-integration,editor-clipboard,confirmed

Type: <b>Bug</b>

1. With an open file, go to File > Save As. 
2. In the Save As window, copy the file name. Close the window without saving. 
3. In another file, paste. Code freezes and has to be force-closed. 

Bug does not happen when copying/pasting file contents. In other words, within the file editor. 

VS Code version: Code 1.83.0 (e7e037083ff4455cf320e344325dacb480062c3c, 2023-10-03T16:11:49.843Z)
OS version: Linux x64 6.2.0-34-generic
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz (8 x 4100)|
|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: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>video_decode: enabled<br>video_encode: disabled_software<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: disabled_off|
|Load (avg)|3, 2, 2|
|Memory (System)|15.41GB (3.43GB free)|
|Process Argv|--crash-reporter-directory /tmp/crashreport|
|Screen Reader|no|
|VM|0%|
|DESKTOP_SESSION|plasma|
|XDG_CURRENT_DESKTOP|KDE|
|XDG_SESSION_DESKTOP|KDE|
|XDG_SESSION_TYPE|x11|
</details><details><summary>Extensions (10)</summary>

Extension|Author (truncated)|Version
---|---|---
aws-toolkit-vscode|ama|1.92.0
vscode-diff|fab|1.4.2
terraform|has|2.28.1
python|ms-|2023.18.0
vscode-pylance|ms-|2023.10.10
autodocstring|njp|0.6.1
intellicode-api-usage-examples|Vis|0.2.8
vscodeintellicode|Vis|1.2.30
gitblame|wad|10.5.1
markdown-editor|zaa|0.1.10


</details><details>
<summary>A/B Experiments</summary>

```
vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstes627cf:30244335
vslsvsres303:30308271
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263cf:30335440
vscoreces:30445986
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
pythonvs932:30410667
py29gd2263cf:30856253
vscaac:30438847
vsclangdf:30486550
c4g48928:30535728
dsvsc012:30540252
pynewext54:30695312
azure-dev_surveyone:30548225
282f8724:30602487
f6dab269:30613381
vscrp:30673768
showlangstatbar:30737416
962ge761:30841074
03d35959:30757346
pythonfmttext:30731395
fixshowwlkth:30771522
showindicator:30805244
pythongtdpath:30769146
i26e3531:30792625
pythonnosmt12:30797651
pythonidxpt:30805730
pythonnoceb:30805159
copilotsettingc:30839828
dsvsc013:30795093
dsvsc014:30804076
diffeditorv2:30821572
dsvsc015:30845448

```

</details>

<!-- generated by issue reporter -->

![image](https://github.com/microsoft/vscode/assets/83093777/c64e0cf2-f6dc-4fd1-a864-0860db629966)

![image](https://github.com/microsoft/vscode/assets/83093777/1a1c188b-5877-4011-92b0-6f5546733c52)
Repository: PowerToys
Issue: Automatically initialize PT Run with currently selected text
Labels: Product-PowerToys Run,Needs-Triage,Needs-Team-Response

### Description of the new feature / enhancement

It would be very handy to automatically initialize PT Run with currently selected text at the moment of pressing Alt+Space (at least as an option disabled by default but ideally — as the default one)

### Scenario when this would be used?

It would save an enormous amount of `Ctrl+C; Ctrl+V`s

### Supporting information

_No response_
Repository: deno
Issue: `deno fmt` exclusions shouldn't apply for explicitly named files
Labels: feat,deno fmt

For example `deno fmt vendor/path/to/file.ts` should work, even though `vendor` is auto-excluded.
Repository: node
Issue: Document the deterministic aspects of setTimeout execution order
Labels: doc

### Affected URL(s)

https://nodejs.org/api/timers.html#settimeoutcallback-delay-args

### Description of the problem

Most of the context of this request can be found here: https://github.com/nodejs/node/issues/13579

Note https://github.com/nodejs/node/issues/13579#issuecomment-308209286 by @sam-github :

> some effort has been made to make sure timers on the same list fire in the sequence of the setTimeout() calls (all other things being equal), but we have not yet been comfortable documenting this

And https://github.com/nodejs/node/issues/13579#issuecomment-308471240 by @Fishrock123 :

> I think we could probably document (2). More than just "some" effort has been put in to that. It may however require documenting more internal structure and not be worth it? Honestly, most good timers algos guarantee this, so I don't think that is a big risk or anything.

At this time, [the documentation](https://nodejs.org/api/timers.html#settimeoutcallback-delay-args) says, "Node.js makes no guarantees about the exact timing of when callbacks will fire, nor of their ordering." Could this be changed to include @sam-github 's note?

I also have an additional question I'd like to see answered:

```js
setTimeout(a, n);
setTimeout(b, n + 1);
/* or */
setTimeout(b, n + 1);
setTimeout(a, n);
```

Is `a` guaranteed to be called before `b`? IMO, the documentation leaves this open to interpretation.
Repository: godot
Issue: Trying to manually load new scenes to toggle back and forth between two scenes fails
Labels: bug,discussion,topic:core,topic:gdscript

### Godot version

v4.1.1.stable.mono.official [bd6af8e0e]

### System information

v4.1.1.stable.mono.official [bd6af8e0e]

### Issue description

I tried to make two menu scenes, where I could go from one scene to another and back (a "MainMenu" that loads the "Level" and the "Level" can return back to the "MainMenu")
I tried to use manual scene switching, where the new packed scenes are instantiated and added, and the old scene is removed (was doing this because I was hoping to eventually make the old scene animate out while the new scene is animating in)
I tried to make the references to the packed scenes be by a packed scene reference (@export'd var of type PackedScene) editable in the editor (I did this so that I could, at some point, move around my files and have the references still be connected)
When I did that, when the "Level" scene got loaded from the "MainMenu", the instantiated level lost it's assigned reference to the "MainMenu", so it couldn't return to main menu. If I make the "Level" the main scene, then it can load "MainMenu" using it's reference, but "MainMenu" then loses it's reference

So I tried doing it instead with hardcoded paths to the PackedScenes in preloads, and then when I toggle back and forth a few times, it fails with some kind of circular reference error

Finally, if I try to reopen the project, for some reason the editor claims Level.tscn is invalid/corrupt, when it is not. I can still run everything (with the same bad behavior) it's just the editor refuses to edit Level.tscn

So the 3 problems are:
1. script vars of "@export var target_scene : PackedScene" are lost when I "target_scene.instantiate()" a PackedScene reference which itself has one of these vars
2. Going back and forth between scenes with scripts with have "var preloadedScene : PackedScene = preload("path")" references to each other eventually errors out with a circular reference error
3. Having two scenes with scripts with "@export var exportedMenu : PackedScene" where assigned to each other makes one (or both) of them considered invalid by the editor, on re-opening the project

### Steps to reproduce

Open the attached project. Notice how it claims Level.tscn is invalid, but the file format is fine

Run the project, which takes you to the main menu. Click the top button to go to the Level scene (which loads fine now, despite the editor saying it's invalid), and now inspect the scene remote'ly and see that it doesn't have the reference to MainMenu.tscn in it's "exportedMenu" variable, despite the packed scene file having the reference, so the top button to return to the main menu doesn't work

Run the project again, which takes you to the main menu. Use the bottom buttons to go back and forth between MainMenu and Level, and notice after a few times, it fails with an error about a circular reference

### Minimal reproduction project

[SceneToggleErrors.zip](https://github.com/godotengine/godot/files/12851372/SceneToggleErrors.zip)
Repository: transformers
Issue: Add an option to decide whether to store the checkpoint and rng_state.
Labels: Feature request

**Motivation:**
Currently, when using the Transformers library in combination with DeepSpeed for training large language models like LLMs, checkpoints (e.g. `bf16_zero_pp_rank_0_mp_rank_00_optim_states.pt`) are automatically saved along with the `rng_state`, which can lead to significant disk space usage. In scenarios where multiple GPUs are employed for training, this can quickly become a storage bottleneck, especially when shared by a team. Sometimes we just want to keep the bin file (e.g. `pytorch_model-00001-of-00002.bin`) as it's enough for load again.

**Feature Request:**
I propose adding a configurable option to decide whether to store the checkpoint and `rng_state` during training. This will give users the flexibility to choose when to save checkpoints and reduce the disk space required.

**Proposed Solution:**

1. Add a new parameter, such as `save_checkpoint_enabled`, to the DeepSpeed configuration file. Users can set this parameter to `True` or `False` to control whether checkpoints and `rng_state` should be saved during training.

2. Modify the `trainer.py` script in the Transformers library to include a condition for `self.save_checkpoint_enabled` in the `_save_checkpoint` function. Here's a code snippet illustrating the change:

   ```python
   if self.is_deepspeed_enabled and self.save_checkpoint_enabled:
       # Save the checkpoint
   ```

This change will allow users to save disk space by not storing checkpoints when not needed, and it can help alleviate the storage challenges associated with large-scale language model training.

I have already submitted this issue to the DeepSpeed library #https://github.com/microsoft/DeepSpeed/issues/4403#issue-1913025248 , as this feature may require collaboration between both libraries.
Repository: rust
Issue: A confusing inferred type for the function followed by `?`
Labels: A-diagnostics,T-compiler

### Code

```Rust
struct A;
impl A{
    fn new()->Result<Self,std::num::ParseIntError>{
        let c = "1".parse()?; 
        Ok(A)
    }
}
fn main() {

}
```


### Current output

```Shell
the trait bound (): FromStr is not satisfied
```


### Desired output

```Shell
type annotations needed
```


### Rationale and extra context

If we desugar the above code to
````rust
struct A;
impl A{
    fn new()->Result<Self,std::num::ParseIntError>{
        let c = match "1".parse(){
            Ok(v)=>{v}
            Err(e)=>{
                return Err(e.into());
            }
        };
        Ok(A)
    }
}
fn main() {

}
````
we will get the expected diagnosis. 

### Other cases

```Rust
Seems a general issue for type inference in this context(i.e. `?`)
`
struct E;
trait MyTrait{
    fn my_parse<F:Default>(&self)->Result<F,E>;
}
impl MyTrait for i32{
    fn my_parse<F:Default>(&self)->Result<F,E>{
        Ok(F::default())
    }
}
fn show()->Result<i32,E>{
    let d = 0i32.my_parse()? + 1;   // inferred type for `my_parse` is `()`
    Ok(1)
}

fn foo<F:Default>()->Result<F,E>{
    Ok(F::default())
}
fn caller()->Result<i32,E>{
    let d = foo()? + 1;  // inferred type for `foo` is `()`
    Ok(0)
}
fn main() {

}

`

All these cases have the same issue.
```


### Anything else?

_No response_
Repository: pytorch
Issue: The NCCL kernel did not start as expected
Labels: oncall: distributed

### 🐛 Describe the bug

Hello, I apologize for the interruption. I've encountered a puzzling issue. I initiated an asynchronous batch_send_recv communication as per the code below, but when observing on nsys, the kernel launch doesn't entirely align with my expectations. In some loops, both batch_send_recv and matmul are perfectly initiated simultaneously, but in others, the communication is significantly delayed. This unpredictable behavior is not what I intended. Is there a way to ensure that the kernels are launched concurrently?
The nsys graph is here.
<img width="1444" alt="image" src="https://github.com/pytorch/pytorch/assets/29300150/6d5f31dd-14fa-457a-8052-430bc4570e48">

``` python
for idx, t in enumerate(cal_index):
        start = t * micro_size
        end = start + micro_size
        # slice and calculate matmul
        yi = torch.matmul(x[:,start:end,:], weight)
        
        # xi = torch.slice_copy(x, dim=-2, start=start, end=end)
        # yi = torch.matmul(xi, weight)
        # we need to sync and get received
        if idx > 0:
            for req in reqs:
                req.wait()
            yi_send = yi + yi_recv
        else:
            yi_send = yi
        # launch async send and recv
        if idx < mp_ranks-1:
            if mp_rank % 2 == 0:
                send_op = torch.distributed.P2POp(dist.isend, yi_send, (mp_rank + 1) % mp_ranks, group=parallel_state.ALL_SMP_GROUP)
            else:
                yi_recv = torch.empty_like(yi)
                recv_op = torch.distributed.P2POp(dist.irecv, yi_recv, (mp_rank - 1 + mp_ranks) % mp_ranks, group=parallel_state.ALL_SMP_GROUP)

            if mp_rank % 2 == 0:
                yi_recv = torch.empty_like(yi)
                recv_op = torch.distributed.P2POp(dist.irecv, yi_recv, (mp_rank - 1 + mp_ranks) % mp_ranks, group=parallel_state.ALL_SMP_GROUP)
            else:
                send_op = torch.distributed.P2POp(dist.isend, yi_send, (mp_rank + 1) % mp_ranks, group=parallel_state.ALL_SMP_GROUP)
            reqs = torch.distributed.batch_isend_irecv([send_op,recv_op])
```

### Versions

torch  Version :2.1.0a0+4136153

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu
Repository: stable-diffusion-webui
Issue: [Feature Request]:How to reload specific extension quickly? 
Labels: enhancement

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

I am a webUI extension developer and often need to restart to verify whether the developed features meet the expected requirements. Is there a way to quickly load only the changes in the plugin portion?
Reloading the entire webUI is really slow and significantly affects the development efficiency.

### Proposed workflow

1. Update the code of the specific extension;
2. Provide a "Reload" button on the "Extensions" tab;
3. Simply reload the specific extension to improve the extension development process.


### Additional information

_No response_
Repository: godot
Issue: Rigidbody3D does not emit NOTIFICATION_TRANSFORM_CHANGED (2000)
Labels: bug,topic:physics

### Godot version

v4.1.stable.mono.official [970459615]

### System information

Godot v4.1.stable.mono - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4070 (NVIDIA; 31.0.15.3640) - AMD Ryzen 7 7700X 8-Core Processor (16 Threads)

### Issue description

I have attached the following script in the attached reproduction, and you can see that the notification method is only triggered a single time at the beginning of execution, despite the cube falling into the void. I would expect transform notifications to be triggered whenever the position of the body changes, as is the case with CharacterBody3D.

Also note that despite my engine version (mono) this occurs when using gdscript as well, the reproduction project is written in gdscript.


```
extends RigidBody3D

# Called when the node enters the scene tree for the first time.
func _ready():
    set_notify_transform(true);

func _notification(what):
    if what == NOTIFICATION_TRANSFORM_CHANGED:
        print(what);

```

### Steps to reproduce

- Open the minimal reproduction project 
- Run the main scene
- Note that the cube is falling, and we only receive the notification a single time

### Minimal reproduction project

[BugReport.zip](https://github.com/godotengine/godot/files/12852834/BugReport.zip)
Repository: rust
Issue: Tracking Issue for `no-jump-tables`
Labels: T-compiler,C-tracking-issue

This is a tracking issue for the `-Zno-jump-tables` compiler flag

### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

### Steps
<!--
Include each step required to complete the feature. Typically this is a PR
implementing a feature, followed by a PR that stabilises the feature. However
for larger features an implementation could be broken up into multiple PRs.
-->

- [ ] Implement the RFC https://github.com/rust-lang/rust/pull/105812
- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide])
  - [ ] Unstable docs: https://github.com/rust-lang/rust/pull/116593
- [ ] Formatting for new syntax has been added to the [Style Guide] ([nightly-style-procedure])
- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide])

[stabilization-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs
[nightly-style-procedure]: https://github.com/rust-lang/style-team/blob/master/nightly-style-procedure.md 
[Style Guide]: https://github.com/rust-lang/rust/tree/master/src/doc/style-guide

### Unresolved Questions
<!--
Include any open questions that need to be answered before the feature can be
stabilised.
-->

None known

### Implementation history

- Implementation: https://github.com/rust-lang/rust/pull/105812