sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Setting custom color for method "emit_particle" not working (GPUParticles3D)
Labels: documentation,topic:particles

### Godot version

4.0.2 stable, 4.1.dev1

### System information

Linux Debian 11, Vulkan, NVIDIA GeForce GTX 1050

### Issue description

Hi,
I have a problem to change the color of manually emitted particles 3D. The particles still have the default color selected in the inspector. Other properties, such as position or velocity, work fine (I also included them in the project).

### Steps to reproduce

Use method "emit_particle" with custom color on GPUParticles3D:
```
emit_particle( Transform3D(), Vector3(), Color( 1.0, 0.0, 0.0 ), Color(), GPUParticles3D.EMIT_FLAG_COLOR )
```

### Minimal reproduction project

[particles.zip](https://github.com/godotengine/godot/files/11303302/particles.zip)
Repository: godot
Issue: When zoomed out, the editor view (sometimes) cannot be panned to the right.
Labels: bug,topic:editor

### Godot version

4.0-stable

### System information

Windows 10, Forward+, Intel HD 620

### Issue description

In large scenes the editor view cannot be dragged freely when zoomed out. Dragging back and forth with the middle mouse button causes the view to get stuck, preventing panning to some parts of the scene. 
Often it gets stuck in a way that limits panning to the right. The center point can't be panned left of the center of the window. So this prevents panning the view to the right.
Other times it gets stuck in other ways, sometime preventing panning up and down.

In general the panning behavior has many "invisible" limits, preventing panning the view past the extent of exisiting nodes.
I suppose that is some kind of design choice.
But this specific issue prevents viewing all parts of the scene. A work around is to zoom in and out, which will center the view around the mouse position.

It seems like there is a panning limit that activates when the view is panned in one direction, and this then prevents the view to be panned back. It's a really strange behavior.


### Steps to reproduce

Open MRP project
Zoom out to see the whole row of icons in the view.
Pan back and forth to move the right most icons off screen.
Try to pan back to show the off screen icons.


### Minimal reproduction project

[MRP_panning.zip](https://github.com/godotengine/godot/files/11303343/MRP_panning.zip)
Repository: puppeteer
Issue: [Feature]: flag to omit sources from coverage entries
Labels: feature

### Feature description

Basically when we have coverage enabled, we build up coverage entries like `{url, ranges, text}`.

In cases where we also retrieve the raw v8 coverage data, we often actually don't care about the `text` (or the `ranges` in fact) since the raw data will be enough for our calculations (e.g. passing through istanbul).

The following call is responsible for populating `text` (ultimately):

https://github.com/puppeteer/puppeteer/blob/e5d686405623488e808b9aaf85083fb24f0894fa/packages/puppeteer-core/src/common/Coverage.ts#L275-L277

this happens for every script we load, basically retrieving the source and storing it in some map.

in large test runs loading many (several hundred, or thousands) scripts, i noticed this call actually results in a lot of lost time waiting for socket communication.

maybe in future it could be a good idea to either:

- have a flag which lets us return the raw coverage data, but not the puppeteer coverage data
- have a flag which lets us disable returning of sources in coverage data

it seems like a really small optimisation, but it does actually add up on large codebases.
Repository: godot
Issue: PackedScene metadata is not saved
Labels: bug,topic:core,confirmed

### Godot version

4.0.2

### System information

Windows 10 x64

### Issue description

```GDScript
var ps = load("res://scene.tscn")
ps.set_meta("test", 1111)
ResourceSaver.save(ps)
```
When you open the file in text editor, there's no trace of what you just assigned.

I get that PackedScene is a special resource, but if it's not going to be supported (although implementing it is possible), it should at least be documented.

### Steps to reproduce

1. Create a scene
2. Run the code above
3. Open tscn file in text editor and look for the meta property

### Minimal reproduction project

N/A
Repository: pytorch
Issue: When backend is nccl, the distribution group type generated by Pytorch 2.0 shoule be ProcessGroupNCCL, but is ProcessGroup
Labels: oncall: distributed

### 🐛 Describe the bug

Hi, I have discovered an issue. The default distribution group type generated by Pytorch 2.0 is ProcessGroup, while in Pytorch version 1.8, it is ProcessGroupNCCL. By debugging the code, it was found that the return values of the code in Pytorch 2.0 and 1.8 are different
Pytorch 2.0
```
import torch
issubclass(torch._C._distributed_c10d.ProcessGroupNCCL, torch._C._distributed_c10d.ProcessGroup)
False
```
Pytorch 1.8
```
import torch
issubclass(torch._C._distributed_c10d.ProcessGroupNCCL, torch._C._distributed_c10d.ProcessGroup)
True
```

The above issue will cause problems with this function “_new_process_group_helper”:
```
        if issubclass(type(backend_class), ProcessGroup):
            pg = backend_class
            break
```


cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu
Repository: stable-diffusion-webui
Issue: [Bug]: I use webui in a iframe , when I need max the image, console print error imageviewer.js?1682053205.0:174 Uncaught TypeError: Cannot read properties of null (reading 'classList')     at modalZoomSet (imageviewer.js?1682053205.0:174:20)     at HTMLImageElement.<anonymous> (imageviewer.js?1682053205.0:161:25)
Labels: bug-report

### Is there an existing issue for this?

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

### What happened?

imageviewer.js?1682053205.0:174 Uncaught TypeError: Cannot read properties of null (reading 'classList')
    at modalZoomSet (imageviewer.js?1682053205.0:174:20)
    at HTMLImageElement.<anonymous> (imageviewer.js?1682053205.0:161:25)

### Steps to reproduce the problem

in a iframe open the webui

imageviewer.js?1682053205.0:174 Uncaught TypeError: Cannot read properties of null (reading 'classList')
    at modalZoomSet (imageviewer.js?1682053205.0:174:20)
    at HTMLImageElement.<anonymous> (imageviewer.js?1682053205.0:161:25)

### What should have happened?

imageviewer.js?1682053205.0:174 Uncaught TypeError: Cannot read properties of null (reading 'classList')
    at modalZoomSet (imageviewer.js?1682053205.0:174:20)
    at HTMLImageElement.<anonymous> (imageviewer.js?1682053205.0:161:25)

### Commit where the problem happens

imageviewer.js?1682053205.0:174 Uncaught TypeError: Cannot read properties of null (reading 'classList')     at modalZoomSet (imageviewer.js?1682053205.0:174:20)     at HTMLImageElement.<anonymous> (imageviewer.js?1682053205.0:161:25)

### What platforms do you use to access the UI ?

_No response_

### What browsers do you use to access the UI ?

_No response_

### Command Line Arguments

```Shell
imageviewer.js?1682053205.0:174 Uncaught TypeError: Cannot read properties of null (reading 'classList')
    at modalZoomSet (imageviewer.js?1682053205.0:174:20)
    at HTMLImageElement.<anonymous> (imageviewer.js?1682053205.0:161:25)
```


### List of extensions

imageviewer.js?1682053205.0:174 Uncaught TypeError: Cannot read properties of null (reading 'classList')
    at modalZoomSet (imageviewer.js?1682053205.0:174:20)
    at HTMLImageElement.<anonymous> (imageviewer.js?1682053205.0:161:25)

### Console logs

```Shell
imageviewer.js?1682053205.0:174 Uncaught TypeError: Cannot read properties of null (reading 'classList')
    at modalZoomSet (imageviewer.js?1682053205.0:174:20)
    at HTMLImageElement.<anonymous> (imageviewer.js?1682053205.0:161:25)
```


### Additional information

imageviewer.js?1682053205.0:174 Uncaught TypeError: Cannot read properties of null (reading 'classList')
    at modalZoomSet (imageviewer.js?1682053205.0:174:20)
    at HTMLImageElement.<anonymous> (imageviewer.js?1682053205.0:161:25)
Repository: neovim
Issue: LSP: high cpu usage with huge number of files with `workspace/didChangeWatchedFiles` enabled
Labels: bug,performance,lsp

### Problem

Noticed this because I have some huge directories in one of my repos for testing, which probably isn't very common. Excluding files not in the patterns sent by the LSP server could possibly help. Rust-analyzer sends `root_dir/**/*.rs`, `root_dir/**/Cargo.toml`, `root_dir/**/Cargo.lock`.

### Steps to reproduce using "nvim -u minimal_init.lua"

steps:
```sh
cargo new repro --bin && cd repro
mkdir test && printf '%s\n' test/{0..60000} | xargs touch
nvim -u init.lua src/main.rs
```

init.lua:
```lua
local pattern = 'rust'
local cmd = {'rust-analyzer'}
local root_markers = {'Cargo.toml'}
local settings = vim.empty_dict()
local capabilities = vim.lsp.protocol.make_client_capabilities()
-- uncommenting this solves the stutter
--capabilities.workspace.didChangeWatchedFiles.dynamicRegistration = false
vim.api.nvim_create_autocmd('FileType', {
	pattern = pattern,
	callback = function(args)
		local match = vim.fs.find(root_markers, { path = args.file, upward = true })[1]
		local root_dir = match and vim.fn.fnamemodify(match, ':p:h') or nil
		vim.lsp.start({
			name = 'rust-analyzer',
			cmd = cmd,
			root_dir = root_dir,
			settings = settings,
			capabilities = capabilities,
		})
	end
})
```


### Expected behavior

_No response_

### Neovim version (nvim -v)

NVIM v0.10.0-dev-169+ge3f36377c

### Language server name/version

rust-analyzer 1.69.0 (84c898d 2023-04-16)

### Operating system/version

arch linux

### Log file

_No response_
Repository: PowerToys
Issue: PowerRename - pre/append sting to filename regardless of search string location
Labels: Needs-Triage

### Description of the new feature / enhancement

Allow insertion of text to a filename in relation to the filename itself, not the location of the search criteria, while leaving the search string unmodified.

Ex: For all files containing "foobar" prepend "NSFW"

this_is_so_foobar.jpg
foobar_code_error.txt
OMFGfoobarsofunny.png

NSFW this_is_so_foobar.jpg
NSFW foobar_code_error.txt
NSFW OMFGfoobarsofunny.png



### Scenario when this would be used?

Use case scenarios : for working with files that contain a string _somewhere_ in the filename and making modifications based on the full filename, regardless of the search string's location within the file name.  

There are plenty of situations where a subsection of a string identifies the files you want to rename, but messing with the string as a whole isn't an option.  You want all files associated with a specific manufacturer based on MAC addresses; all UPS packages from a certain shipper or to a specific recipient, etc.

For example, I work with scanned physical documents with generated filenames. Often the generated cnames are not descriptive enough to allow a user to identify or differentiate the files, forcing them to rely on the numeric identifiers or open each file to find the correct one.  This is particularly troublesome for items that are serial in nature where the cname is identical except for a volume/date/issue designation, which is frequently truncated from the file cname.

Here there are multiple different documents and derivative documents, but by looking at the names, you can't easily tell which is associated with which: 
![image](https://user-images.githubusercontent.com/42596224/233842894-56a722b6-efc4-4ecf-be03-2429972368f6.png)

There is a numeric identifier which contains a UUID, but it's location in the file name isn't always consistent, and the UUID is only part of the identifier, which isn't always the same length.

For the earlier files, what I want is to add detail to the front of the file name, giving me this:
![image](https://user-images.githubusercontent.com/42596224/233843159-375ef6bf-3bf6-4148-a9cf-4155f3b63007.png)


### Supporting information

Sure, I can use File Explorer to search for the UUID, then select files from the search results, then open PowerRename, then search for something like the examples in the help documents: 
`^(.{n})(.*)`  or `^(.*)(.{n})$`
...and then do it _all over again_ for _each_ UUID.

But wouldn't it be nice if I could both search _and_ insert/prepend/append/trim filenames without having to do it to ALL of the files selected?

Making use of the existing search features (and ease of modifying search parameters such as subfolders!) of PowerRename would significantly reduce the time required for bulk renaming of files in cases where the search term itself is only for identification and is not the desired target for modification.
Repository: godot
Issue: [4.x] Key event not triggered in running game
Labels: bug,topic:input

### Godot version

v4.0.2.stable.arch_linux

### System information

Endeavor OS (Arch Linux), Kernel: 6.1.25-1-lts

### Issue description

I am able to register a key mapping by pressing it inside the editor input mapping tool but it won't trigger while the game is running. The key is a special key (F32) and is only registered as a Physical Key. 

![image](https://user-images.githubusercontent.com/104794884/233851706-c4322444-6e4b-4fdb-9a65-8359909856e6.png)
![image](https://user-images.githubusercontent.com/104794884/233851871-eb3efd2d-6247-4edf-a32a-c5d77feee562.png)


### Steps to reproduce

Add key in Input Map
Use it inside code (`Input.is_action_pressed("key")`)

### Minimal reproduction project

N/A
Repository: rust
Issue: Tracking Issue for `AllocErrorPanicPayload`
Labels: T-libs-api,C-tracking-issue

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(alloc_oom_payload)]`

This is a tracking issue for the `AllocErrorPanicPayload` type which is passed as a payload to the panic handler (and thus can be caught with `catch_unwind`) when `handle_alloc_error` is called. This provides access to the `Layout` that caused the allocation failure.

<!--
Include a short description of the feature.
-->

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

```rust
// alloc::alloc

/// Payload passed to the panic handler when `handle_alloc_error` is called.
pub struct AllocErrorPanicPayload;

impl AllocErrorPanicPayload {
     /// Returns the [`Layout`] of the allocation attempt that caused the error.
    pub fn layout(&self) -> Layout;
}
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [x] Implementation: #109507
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilization PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- [ ] Should this be in `core` instead of `alloc`?
  - This payload is only generated by `alloc::alloc::handle_alloc_error`, but it may still be useful in core-only panic handlers.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: rust
Issue: ExactSizeIterator seems to generate worse assembly if mutated before collected into `Vec`
Labels: A-codegen,C-bug,I-heavy,C-optimization

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

Godbolt link https://godbolt.org/z/cMdx6v1G9

```rust
pub fn exact_size(){
    let it = std::hint::black_box(vec![1,2,3].into_iter());
    let v = it.collect::<Vec<_>>();
    std::hint::black_box(v);
}


pub fn var_size(){
    let it = std::hint::black_box(vec![1,2,3].into_iter()).filter(|x| true);
    let v = it.collect::<Vec<_>>();
    std::hint::black_box(v);
}
```

I expected to see this happen: `exact_size` to generate better assembly than `var_size`

Instead, this happened: 
1. `var_size` generates way shorter assembly (~90) than `exact size` (>200) with zero call to allocate `Vec`
2. It seems to me `var_size` is trying to allocate the `Vec` on stack. This optimization did not happen on `exact_size` (Excuse me if I misintepreted the assembly).


The key to trigger this deoptimization seems to be mutating the iterator before collecting. This example is a reduction of a real-world code where the first few elements are processed differently and the rest of the elements is collected into `Vec` then consumed locally. 

Godbolt link for a more realistic example: https://godbolt.org/z/sccdTcvh6
```rust
#[inline(never)]
pub fn example<I: Iterator>(mut it: I){
    // .... read and process a few elements
    let Some(first_elem) = it.next() else {return;};
    // let mut it = it.filter(|x| true); // <------ This causes different optimization if ExactSizeIterator
    let v = it.collect::<Vec<_>>();
    for elem in v {
        // Different processing on rest of the elements.
    }
}

pub fn call_example() {
    example(vec![1,2,3].into_iter())
}
```
---
Edit: Include a more realistic example
Repository: tauri
Issue: [bug] App not working if OS sleeps multiple times (with no panics/error messages)
Labels: type: bug,platform: Linux,status: needs triage

### Describe the bug

Turn Ubuntu 22 into sleep mode. Turn the OS back on, app works fine. Do this again for some random times (I don't know how many) and the main thread (not the front-end thread) stops working with no messages. I must kill the process.

### Reproduction

_No response_

### Expected behavior

_No response_

### Platform and versions

```text
Environment
  › OS: Ubuntu 22.04 X64
  › Node.js: 18.16.0
  › npm: 9.5.1
  › pnpm: Not installed!
  › yarn: 1.22.19
  › rustup: 1.25.2
  › rustc: 1.67.1
  › cargo: 1.67.1
  › Rust toolchain: stable-x86_64-unknown-linux-gnu 

Packages
  › @tauri-apps/cli [NPM]: 1.2.3
  › @tauri-apps/api [NPM]: 1.2.0
  › tauri [RUST]: 1.2.4,
  › tauri-build [RUST]: 1.2.1,
  › tao [RUST]: 0.15.8,
  › wry [RUST]: 0.23.4,

App
  › framework: React
  › bundler: Vite

App directory structure
  ├─ dist
  ├─ .git
  ├─ src-tauri
  ├─ node_modules
  └─ src
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: stable-diffusion-webui
Issue: xformers dependency problem
Labels: bug-report

So the current newest clean version is running on 
Python 3.10.6, and Torch 1.13.1+cu117

But if we just pip install xformers in stable diffusion folder
It will install xformers version 0.0.16rc425

Which gives us this warning (actually it should be an error)
Warning: caught exception 'Torch not compiled with CUDA enabled', memory monitor disabled
WARNING[XFORMERS]: xFormers can't load C++/CUDA extensions. xFormers was built for:
    PyTorch 1.13.1+cu117 with CUDA 1107 (you have 1.13.1+cpu)
    Python  3.10.9 (you have 3.10.6)
  Please reinstall xformers (see https://github.com/facebookresearch/xformers#installing-xformers)
  Memory-efficient attention, SwiGLU, sparse and more won't be available.
Repository: rust
Issue: Match blocks generate inefficient assembly compared to if/else chain since rust 1.65.0
Labels: I-slow,A-codegen,P-medium,T-compiler,regression-from-stable-to-stable,C-bug

I would assume that the following two snippets of code would compile to identical assembly

```rust
pub fn convert_hex(d: char) -> Option<u32> {
    if ('0'..='9').contains(&d) {
        Some(u32::from(d) - u32::from('0'))
    } else if ('A'..='Z').contains(&d) {
        Some(10 + u32::from(d) - u32::from('A'))
    } else {
        None
    }
}

pub fn convert_hex2(c: char) -> Option<u32> {
    match c {
        '0'..='9' => Some(u32::from(c) - u32::from('0')),
        'A'..='Z' => Some(10 + u32::from(c) - u32::from('A')),
        _ => None,
    }
}
```

However, as of rustc 1.65.0 `convert_hex2` with the `match` blocks generates suboptimal code that is approximately 30% slower in a microbenchmark. [Godbolt link showing asm comparison between 1.64.0 vs 1.69.0](https://rust.godbolt.org/z/WPPWYff5v).

I don't think it's an LLVM regression since the emitted IR differs between 1.64 and 1.65: https://rust.godbolt.org/z/7b3EbGfj3

### Version it worked on

It most recently worked on: 1.64.0

### Version with regression

```
1.65.0 - nightly (as of 1.69.0)
```

@rustbot modify labels: +regression-from-stable-to-stable -regression-untriaged +A-codegen  +C-bug +T-compiler +I-slow

I'll try to bisect the commit behind the change.
Repository: pytorch
Issue: NTK notebook calculates wrong object - wrong output dimensions
Labels: triaged,module: functorch

### 📚 The doc issue

The notebook given in https://pytorch.org/functorch/stable/notebooks/neural_tangent_kernels.html does not calculate the NTK - the output depends on the size of the input tensors instead of the size of the network's input. The NTK should be a n_in x n_in x n_out x n_out matrix (https://en.wikipedia.org/wiki/Neural_tangent_kernel), where n_in/n_out are the sizes of the network's inputs/outputs. 

### Suggest a potential alternative/fix

_No response_

cc @zou3519 @Chillee @samdow @soumith @kshitij12345 @janeyx99