sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: ant-design
Issue: Spin 在暗黑模式还是主题蓝色，看起来不太好
Labels: 💡 Feature Request,Inactive

### Reproduction link

[![Edit on StackBlitz](https://developer.stackblitz.com/img/open_in_stackblitz.svg)](https://stackblitz.com/edit/react-dmhdvy?file=demo.tsx)

### Steps to reproduce

查看 Spin

Tooltip 下的 Spin 还是蓝色
![image](https://github.com/ant-design/ant-design/assets/7971419/a70f6902-f26b-47f9-a760-f1bb35504abf)

暗黑主题也是蓝色

![image](https://github.com/ant-design/ant-design/assets/7971419/d155852f-e274-4ccb-b2c4-eb15fae192fc)


### What is expected?

颜色正常

### What is actually happening?

颜色不对

| Environment | Info |
| --- | --- |
| antd | 5.15.3 |
| React | latest |
| System | mac |
| Browser | chrome |

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: neovim
Issue: diff fold not synced after insert mode
Labels: bug,folds,diff

### Problem

Usually, folds in diff mode is synced with all diffed windows. If a fold is open is one window, the matching fold in the other window should be open too. But after an insert mode edit that changes diff folds, the fold in the other window is not opened accordingly. 


The root cause seems to be that this invocation of `setManualFoldWin` can't find the matching fold in the other window: 
https://github.com/neovim/neovim/blob/2955c921ceaf5764e8d1592a78370d9ca3a268e2/src/nvim/fold.c#L1161-L1174

This seems to be related to the fact that nvim does not update folds in insert mode. In fact, the following patch that allows diff fold update in insert mode fixes the problem:
```diff
diff --git a/src/nvim/fold.c b/src/nvim/fold.c
index be3295c44..dba2a7492 100644
--- a/src/nvim/fold.c
+++ b/src/nvim/fold.c
@@ -777,7 +777,7 @@ void clearFolding(win_T *win)
 /// The changes in lines from top to bot (inclusive).
 void foldUpdate(win_T *wp, linenr_T top, linenr_T bot)
 {
-  if (disable_fold_update || (State & MODE_INSERT && !foldmethodIsIndent(wp))) {
+  if (disable_fold_update || (State & MODE_INSERT && !foldmethodIsIndent(wp) && !foldmethodIsDiff(wp))) {
     return;
   }
```
But some people may find eager fold update in insert mode annoying, which is one of the reason `State & MODE_INSERT` check was introduced to nvim.

An alternative approach is forcing diff update when opening a diff fold, but I'm not sure if this is a good solution.
```diff
diff --git a/src/nvim/fold.c b/src/nvim/fold.c
index be3295c44..b0713aa7f 100644
--- a/src/nvim/fold.c
+++ b/src/nvim/fold.c
@@ -1160,6 +1160,7 @@ static linenr_T setManualFold(pos_T pos, bool opening, bool recurse, int *donep)
 {
   if (foldmethodIsDiff(curwin) && curwin->w_p_scb) {
     linenr_T dlnum;
+    ex_diffupdate(NULL);
 
     // Do the same operation in other windows in diff mode.  Calculate the
     // line number from the diffs.
```

I can make a PR with either approach, but 

### Steps to reproduce

```
nvim --clean -S <(tee << 'EOF'
    call setline(1, range(1,100))
    vnew
    call setline(1, insert(insert(range(1,100), '',  20), '', 80))
    windo diffthis
    20
    normal! o
EOF
)
```
![image](https://github.com/neovim/neovim/assets/19489738/97aa4555-33c1-490f-b07d-11db2332261c)

The right window's fold is open, but not the left's. 

### Expected behavior

In vim, folds in both windows are opened. 
![image](https://github.com/neovim/neovim/assets/19489738/c2d00732-ab46-44cc-9bdb-23fd28f18a9a)


### Neovim version (nvim -v)

0.10 2955c921ceaf5764e8d1592a78370d9ca3a268e2

### Vim (not Nvim) behaves the same?

No. 9.1.181

### Operating system/version

ubuntu 22.04

### Terminal name/version

GNOME Terminal 3.44.0 using VTE 0.68.0 +BIDI +GNUTLS +ICU +SYSTEMD

### $TERM environment variable

tmux-256color

### Installation

build from repo
Repository: PowerToys
Issue: Quick Accent - Pops up Apparently Randomly
Labels: Issue-Bug,Needs-Triage,Product-Quick Accent

### Microsoft PowerToys version

Preview x64 0.77.0

### Installation method

Microsoft Store

### Running as admin

None

### Area(s) with issue?

Quick Accent

### Steps to reproduce

Sorry, not sure what I'm doing to cause the issue, but the Quick Accent bar keeps popping up on my screen at odd times. Perhaps I've accidentally mistyped something, but I'm not aware of activating it. When it DOES show at the top of the screen, I can't get rid of it easily. ESC or clicking off doesn't seem to work. It just goes when it's ready. I've now switched it off, but it would be handy to use it occasionally.

### ✔️ Expected Behavior

See above.

### ❌ Actual Behavior

See above.

### Other Software

_No response_
Repository: pytorch
Issue: Global Response Normalization (GRN)
Labels: module: nn,triaged,needs research

### 🚀 The feature, motivation and pitch

The GRN was described in the [ConvNeXt V2 paper ](https://openaccess.thecvf.com/content/CVPR2023/papers/Woo_ConvNeXt_V2_Co-Designing_and_Scaling_ConvNets_With_Masked_Autoencoders_CVPR_2023_paper.pdf) as an effective normalization technique for preventing feature collapse and diversity. It would therefore be useful to integrate this normalization into existing architectures like ResNet to compare performance differences.

### Alternatives

_No response_

### Additional context
We can build on the [GRN implementation](https://github.com/facebookresearch/ConvNeXt-V2/blob/2553895753323c6fe0b2bf390683f5ea358a42b9/models/utils.py#L105-L116) in the repo for ConvNeXt V2.
 

cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki
Repository: transformers
Issue: About new ClearML Intergrations
Labels: Feature request,Integrations

### Feature request

We need add set / filter metrics that displayed on ClearML plots. It's hard to use it with a tons of metrics that have diffrerent scale on the one plot.

### Motivation

This new implementation ClearML callback's output all metrics from log as multiple series at one plot, that's looks not readable. 
from https://github.com/huggingface/transformers/pull/28559
![image](https://github.com/huggingface/transformers/assets/6096108/614fabc2-0d1c-4320-b4cc-7ae61bbae88d)
For example: runtime and samples_per_seconds has different scale than other metrics.

Previous version report metrics as one metric - one plot.

Any ideas how can we set / filter metrics without code changes?
As temporarily solution I add my own callback for send some metrics to ClearML at other plots.

### Your contribution

Yes, I can.
Repository: rust
Issue: Types and specifically "mentioned items" take up a lot of space in Rust metadata files
Labels: A-metadata,T-compiler,A-const-eval,I-heavy

https://github.com/rust-lang/rust/pull/122568 was a significant size regression for Rust metadata. The extra information that is stored in MIR bodies now is a bunch of `Ty<'tcx>`, so in memory I think this is actually not that much. But it seems like in our metadata format this takes up quite a bit of space. This not only makes the library files bigger, it also accounts for a large fraction (I think even the majority) of the compile-time regression from that PR.

I don't know if there's something that can be done to improve this -- either by storing different information in `mentioned_items` that needs less space on disk, or by representing `Ty<'tcx>` more efficiently on disk. One drastic option would be to "intern" types in the on-disk format, i.e. have one global table of types that everything else just indexes into. That would certainly save space when the same type appears multiple times. I don't know if that is what happens here though.
Repository: rust
Issue: Incorrect argument index highlighting an error for type mismatch on static trait function calls
Labels: A-diagnostics,T-compiler,C-bug,D-incorrect,S-has-mcve

```rs
use std::fmt::Debug;

fn run() {
    let mut not_int = String::new();
    Foo::write_to(123, not_int); // Error span is on the wrong argument here
}

pub trait Foo<W: Debug, Err = ()> {
    fn write_to(self, not_int: W);
}

struct Test;
impl Foo<String> for Test {
    fn write_to(self, not_int: String) {}
}
```

[Playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=849c0a3a5e4de7f7418789a728c98f5b)

Creates the following error:
![image](https://github.com/rust-lang/rust/assets/13347712/4045b730-cf82-4228-85da-11e1037a42c6)

`rustc --version --verbose`:
```
rustc 1.79.0-nightly (85e449a32 2024-03-22)
```



</p>
</details>
Repository: deno
Issue: node:fs `StatWatcher` is not implemented correctly
Labels: bug,node compat,node API

https://github.com/denoland/deno/blob/86cdf3703399367836c89accba3756437d820bb0/ext/node/polyfills/_fs/_fs_watch.ts#L269-L284

It's just setting a delay and comparing `mtimes`. This needs to be implemented using actual file watcher
Repository: godot
Issue: Image.set_pixel(x, y, Color) does not appear to work on Android
Labels: platform:android,needs testing

Edit: Reworked and added additional details

### Tested versions

- Reproduced on v4.1.3.stable.official [f06b6836a] and ~~v4.2.1.stable.official [b09f793f5]~~

### System information

Android 14 - Mobile renderer

### Issue description

I've created an image from a viewport of a 3D model. Within Windows I'm able to change the colors outside of the character model based on the `RenderingServer.get_default_clear_color()`. On Windows the code works as expected, but when I export to Android it's not working. 

Behold the mighty expected behaviour on Windows 👌:
![image](https://github.com/godotengine/godot/assets/5303125/457b26f4-f71c-49c4-81ab-e6a79a089501)

Now gaze upon the ineffectiveness of the code when Mobile renderer takes over on Android 😒:
![Screenshot_20240323-192515](https://github.com/godotengine/godot/assets/5303125/9e4b545b-a9ed-4865-94db-d47e4cef3f29)


Could this be somehow the PNG is processed and saved? 

### Steps to reproduce
1.  Download the MRP4.zip and run the code on Windows to see it work.
2.  Setup Android export to deploy to build for Android
3.  Run it on Android and it will not change color of the PNG produced as it did in Windows

What the project structure looks like:
![image](https://github.com/godotengine/godot/assets/5303125/59ce5d8c-e55f-472f-82a9-5d2cdc6034aa)

This is the offending code. `is_equal_approx` is never true and even if I hardcode the value of the color (as seen here 
```gdscript
func change_color():
	var display_img = Image.load_from_file(image_loc)
	for y in display_img.get_height():
		for x in display_img.get_width():
			var pix_color = display_img.get_pixel(x, y)
			var replace = replace_color
			var is_equal = pix_color.is_equal_approx(replace)
			if is_equal:
				display_img.set_pixel(x, y, new_color)
	display_img.resize(256,256)
	rect_take_image.set_texture(ImageTexture.create_from_image(display_img))
```
> Note: `replace_color` is `RenderingServer.get_default_clear_color()` which it looks the same to me but somehow Godot misreads the PNG color on Android 
### Minimal reproduction project (MRP)
[MRP4.zip](https://github.com/godotengine/godot/files/14733862/MRP4.zip)

Source code below at: https://github.com/godotengine/godot/issues/89800#issuecomment-2016634280
Repository: rust
Issue: Panic while formatting panic message + always_abort leads to stack overflow
Labels: T-compiler,C-bug,T-libs,A-panic

[Example and initial analysis](https://github.com/rust-lang/rust/pull/110975#issuecomment-2016455982) by @correabuscar:
```rust
#![feature(panic_always_abort)]

use std::fmt::{Display, self};

struct MyStruct;

impl Display for MyStruct {
    fn fmt(&self, _: &mut fmt::Formatter<'_>) -> fmt::Result {
        panic!("this is bad: {}", MyStruct);
    }
}

fn main() {
    std::panic::always_abort();
    println!("{}", MyStruct);
}
```

The reason for this is that if both "panic while processing panic" and "panic after `always_abort`" apply, then we use the `AlwaysAbort` code path which *does* format the panic message.

This could be fixed by moving this check further down below the `in_panic_hook` check:

https://github.com/rust-lang/rust/blob/9f25a04498fbe30dcf6a9c764953704c333a0137/library/std/src/panicking.rs#L393-L395

But I don't know if this has other adverse side-effects. Can we even access thread-local variables after `fork` (i.e., when always-abort is set)?
Cc @Amanieu
Repository: godot
Issue: Built-in docs: Method lists' category vertical separation is too small
Labels: discussion,topic:editor,topic:gui

### Tested versions

Godot 4.x

### System information

Windows

### Issue description

Godot 3:
![image](https://github.com/godotengine/godot/assets/76705401/e95a4f5e-82bf-4832-85de-2670c7a30e51)

Godot 4:
![image](https://github.com/godotengine/godot/assets/76705401/6f6118c5-3731-453a-909f-121ba05f73c4)

The clearly defined vertical separation in Godot 3 is visibly present in Godot 4, but way too small, giving the list a wall of text look.

### Steps to reproduce

N/A

### Minimal reproduction project (MRP)

N/A
Repository: rust
Issue: Line numbers in diagnostics for doctests are off by number of preceding hidden lines that aren't `use core;`
Labels: T-rustdoc,A-diagnostics

### Code

```Rust
/// ```
/// # use playground::f;
/// x
/// ```
pub fn f()
{
    todo!()
}
```

Note that the expression `x` occurs on line 3 in the source code.

### Current output

```Shell
error[E0425]: cannot find value `x` in this scope
 --> src/lib.rs:4:1
  |
6 | x
  | ^ help: a function with a similar name exists: `f`
  |
 ::: /playground/src/lib.rs:5:1
  |
5 | pub fn f()
  | ---------- similarly named function `f` defined here
```

Note that the diagnostic refers to line 4.

### Desired output

```Shell
error[E0425]: cannot find value `x` in this scope
 --> src/lib.rs:3:1
  |
6 | x
  | ^ help: a function with a similar name exists: `f`
  |
 ::: /playground/src/lib.rs:5:1
  |
5 | pub fn f()
  | ---------- similarly named function `f` defined here
```


### Rationale and extra context

_No response_

### Other cases

_No response_

### Rust Version

```Shell
$ rustc --version --verbose
rustc 1.77.0 (aedd173a2 2024-03-17)
binary: rustc
commit-hash: aedd173a2c086e558c2b66d3743b344f977621a7
commit-date: 2024-03-17
host: x86_64-unknown-linux-gnu
release: 1.77.0
LLVM version: 17.0.6
```


### Anything else?

This doesn't always seem to happen, for example in the following example it does not:

```rust
/// ```
/// # use core;
/// x
/// ```
pub fn f()
{
}
```

```Shell
error[E0425]: cannot find value `x` in this scope
 --> src/lib.rs:3:1
  |
4 | x
  | ^ not found in this scope
```

I'm not sure what makes the difference. The only difference in the code is that one imports `playground::f` and the other imports `core`.
Repository: rust
Issue: Compiler takes 30 minutes + large (32GB+) amounts of ram to compile code with large amount of arguments + function-within-function
Labels: I-slow,A-macros,I-compilemem,C-bug,E-needs-mcve

I do not have a simple reproducible example since this bug goes over my head, perhaps someone else can find the bug but it seems pretty bad:

This file takes over 30 minutes of time to compile in rustc 1.77.0 (rustc 1.77.0 (aedd173a2 2024-03-17)) and rustc nightly (rustc 1.78.0-nightly (2bf78d12d 2024-02-18)): https://github.com/Anti-Raid/splashtail/blob/74a33ddebe045d2a9fb4acc2d65ef97f75314e84/botv2/src/modules/moderation/cmd.rs [this specific commit triggered the issue of 30 minutes though this was always exponentially slow from the very start]

Don't know why it is, but this seemingly innocent file takes up a full 25-30 minutes of compile time and hogs up over 32GB of ram to the point that I needed to add 128GB of swap in order for Linux's Out Of Memory killer to not SIGKILL rust. In CI, this just leads to a SIGKILL quickly within 20 minutes of compiling. Actual compilation seems to go through without much of an error. Removing ``moderation`` from the module tree reduces compile times from 30 minutes to 5-6 minutes and RAM usage returns to normal

I expected to see this happen: Compile times within 5-6 minutes (which is normal right now, don't know if the 5 minute time comes from the same root cause as this bug though but it could be) and normal RAM usage (<32GB ram)

Instead, this happened: 

warning: struct `ConfigOption` is never constructed
   --> src/silverpelt/config_opt.rs:159:12
    |
159 | pub struct ConfigOption {
    |            ^^^^^^^^^^^^
    |
    = note: `#[warn(dead_code)]` on by default

warning: `botv2` (bin "botv2") generated 1 warning
    Finished release [optimized] target(s) in 30m 27s

[Ignore the warning, thats unrelated]

Linux kernel kills rust with a SIGKILL 9 randomly and Out Of Memory killer activates

### Meta

Tested and reproduced across both Apple M1 and a Dedicated Server (Intel(R) Xeon(R) CPU E3-1240 v3 @ 3.40GHz) on both rust stable and nightly using both LLVM and Cranelift as codegen backends. Switching linkers to ``clang``+``mold``/``ld.lld`` from defaults did not help. Rust versions are given below:

rustc 1.77.0 (aedd173a2 2024-03-17) and rustc 1.78.0-nightly (2bf78d12d 2024-02-18)

No backtrace is available, the compiler does not crash, attempts to compile the code using ``--timing`` for timing information don't seem to even complete in any reasonable timespan. Issue occurs on both ``debug`` and ``release`` builds so this is not an issue of ``release`` build optimizations. Typical options to speed up compile times such as ``opt-level = 1`` do not work in reducing neither the compile times nor the memory usage.  Splitting up the code into multiple crates does not work as long as this file is in the module tree and hence compiled.
Repository: tauri
Issue: [bug] Tauri window theme is not propagated to webview (prefers-color-scheme)
Labels: type: bug,platform: Linux,status: needs triage

### Describe the bug

I have the same issue #5802 but on linux, I use debian gnome 46, I tried tauri 1 and 2 and still doesnt work

### Reproduction

_No response_

### Expected behavior

_No response_

### Full `tauri info` output

```text
[✔] Environment
    - OS: Debian Unknown X64
    ✔ webkit2gtk-4.1: 2.42.5
    ✔ rsvg2: 2.54.7
    ✔ rustc: 1.76.0 (07dca489a 2024-02-04)
    ✔ cargo: 1.76.0 (c84b36747 2024-01-18)
    ✔ rustup: 1.27.0 (bbb9276d2 2024-03-08)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (default)
    - node: 20.10.0
    - pnpm: 8.13.1
    - npm: 10.2.3

[-] Packages
    - tauri [RUST]: 2.0.0-beta.13
    - tauri-build [RUST]: 2.0.0-beta.10
    - wry [RUST]: 0.37.0
    - tao [RUST]: 0.26.1
    - @tauri-apps/api : not installed!
    - @tauri-apps/cli [NPM]: 2.0.0-beta.11

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:3000/invoice
    - framework: Vue.js (Nuxt)
    - bundler: Webpack
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: three.js
Issue: BatchedMesh: add method to check if geometry can be added
Labels: Suggestion

### Description

How should i detect if my BufferGeometry can be added to a BatchedMesh before calling addGeometry?

I know there's `_validateGeometry` - but this method seems not meant to be part of the public API. I'd need a way to detect if calling addGeometry is safe. 


### Solution

Expose `_validateGeometry` - not sure if it should throw however - perhaps it could return an object or string containing a reason for why it can't be added (and then the addGeometry call could still throw) 

### Alternatives

~~Calling `_validateGeometry`~~ (this is very slow) - but an official API method would be preferred

### Additional context

_No response_
Repository: deno
Issue: Bug: `Deno.serve` prefers `gzip` over `br` compression for Chrome 123
Labels: bug,ext/http

Version: Deno 1.41.3

Current Chrome 123.0.6312.59 sends `zstd` as additional accepted encoding, which seems to make `Deno.serve` prefer `gzip` over `br`.
If `zstd` is deactivated via `chrome://flags`, then `br` is preferred as expected.
Repository: three.js
Issue: BatchedMesh: `bufferSubData` causes lag
Labels: Question

### Description

Hi, I'm currently stress testing with 20 instances and ~300.000 vertices each. 
We have LODs generated and I reserve the vertex space of LOD 0 for each instance so the float32 buffer ends up being ~ 9.000.000

When LODs switch and setGeometry is called i noticed quite a few big lags which seem to be coming from the call to bufferSubData with the whole buffer.

My question is if this is currently expected or if I might be doing something wrong here.

![image](https://github.com/mrdoob/three.js/assets/5083203/c1ed0536-938b-4fdb-86c1-1c312b3cfd4e)

![image](https://github.com/mrdoob/three.js/assets/5083203/fd9f3aee-98f3-4148-8e0b-fdbd9e392577)




### Solution
 I would hope this could be optimized by providing the ranges array and the batched mesh could keep track of which ranges have changed. Could this be a possible improvement?

### Alternatives

Clamp the max size of a BatchedMesh (on my side)

### Additional context

https://mastodon.gamedev.place/@marwi/112145459503913620
Repository: vscode
Issue: git conflicts - highlight for the base for diff3 conflict format
Labels: feature-request,merge-conflict

<!-- ⚠️⚠️ 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. -->
I'm using [diff3](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging) for git conflicts. Currently in VSCode, the `Current Change` and `Incoming Change` are highlighted, making it easier to differentiate the two changes. But for the `Base` part of diff3, there is no highlight. See below screenshot:
![image](https://github.com/microsoft/vscode/assets/58911524/617dd21e-3075-4c68-be9b-276d11366bd8)

What I'd like to have is something similar to what is already done for the current/incoming changes for the base. Having a highlight with a small text indicating it's the base.

<details>
<summary>diff3 text example</summary>
<pre>
<<<<<<< ours
  puts 'hola world'
||||||| base
  puts 'hello world'
=======
  puts 'hello mundo'
>>>>>>> theirs
</pre>
</details>

If you think VSCode would benefit from this idea, I can work on the PR.
Repository: godot
Issue: is_action_just_released happens twice in _gui_input()
Labels: discussion,needs testing,topic:input

### Tested versions

v4.2.stable.official [46dc27791] checked only

### System information

windows 7 v4.2.stable Compatable rendering 

### Issue description

i want to clarify that nothing like that happens in `is_action_just_pressed()` and `is_action_pressed()` .  is it ok? maybe i need to do it by 	`if event.is_action("Click") and Input.is_action_just_pressed("Click"):` and it works but its seems like a bug neverless.

### Steps to reproduce

```gdscript
func gui_input(event:InputEvent):
    	if Input.is_action_just_released("Click"):
              print("released")
```

 (with click being left mouse button) and look at console after clicking a mouse once.

### Minimal reproduction project (MRP)

N/A