sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: material-ui
Issue: [ButtonGroup][Joy] Borders don't work properly with non-matching variants
Labels: component: ButtonGroup,package: joy-ui,enhancement

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Steps to reproduce 🕹

Link to live example: https://codesandbox.io/s/admiring-james-kzmpdk?file=/demo.tsx

Steps:

1. Create a button group
2. Make a button deviate from the button group's variant and/or color


### Current behavior 😯

Using the default props of the button group, the button group will try to apply a border to the button in the groups color, rather than adhering to the styling of the button itself.

The inverse happens when applying a different variant to the button group and adding a outlined button within it, which basically recreates #37574.

![image](https://github.com/mui/material-ui/assets/1693592/494fc589-d156-4a92-95fb-379faec57d32)

The buttons seem to rely on the button group styling where they shouldn't.

### Expected behavior 🤔

The button defines the styles and color applied to it if they are set, and otherwise use the color and/or variant from the button group.

### Context 🔦

Trying to make a button group with spacing where the primary action has a highlighted style.

### Your environment 🌎

_No response_
Repository: opencv
Issue: stitching headers compiler warning
Labels: category: build/install,category: stitching

### System Information

OpenCV version: 4.8.0
Operating System / Platform: Debian 11.6
Compiler & compiler version: GCC 10.2.1

### Detailed description

Including the header of the stitching module yields the following error with OpenCV 4.8.0:

```
In file included from /usr/local/include/opencv4/opencv2/stitching/detail/warpers.hpp:47,
                 from /usr/local/include/opencv4/opencv2/stitching/warpers.hpp:46,
                 from /usr/local/include/opencv4/opencv2/stitching.hpp:48,
                 from stitching_compiler_error.cpp:1:
/usr/local/include/opencv4/opencv2/core/cuda.hpp:580:2: error: extra ‘;’ [-Werror=pedantic]
  580 | };
      |  ^
/usr/local/include/opencv4/opencv2/core/cuda.hpp:591:2: error: extra ‘;’ [-Werror=pedantic]
  591 | };
      |  ^
cc1plus: all warnings being treated as errors
```

### Steps to reproduce

```
#include <opencv2/stitching.hpp>
int main() {}
```

Compile with `g++ -I/usr/local/include/opencv4 -Wpedantic -Werror stitching_compiler_error.cpp`

This error was not present in OpenCV 4.6.0 and prior.

### Issue submission checklist

- [X] I report the issue, it's not a question
- [X] I checked the problem with documentation, FAQ, open issues, forum.opencv.org, Stack Overflow, etc and have not found any solution
- [X] I updated to the latest OpenCV version and the issue is still there
- [X] There is reproducer code and related data files (videos, images, onnx, etc)
Repository: storybook
Issue: [Bug]: Loading chunk failed in Docs with inline:false and multiple stories for a component
Labels: bug,needs triage

### Describe the bug

In storybook 7, when multiple stories are defined for a component and the property    
docs: { story: { inline: false } } is set in preview.js, some stories take a long time to load and then eventually fail with a message: 

![image](https://github.com/storybookjs/storybook/assets/63335068/f4c7f85c-b57a-40ec-9af7-be153e340eac)

The page also becomes very laggy


### To Reproduce

https://github.com/daniel-stoian-lgp/storybook7docs

### System

Environment Info:

  System:                                                    
    OS: Windows 10 10.0.19045                                
    CPU: (12) x64 Intel(R) Core(TM) i7-10810U CPU @ 1.10GHz  
  Binaries:                                                  
    Node: 18.16.0 - C:\Program Files\nodejs\node.EXE         
    Yarn: 1.22.19 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 9.5.1 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Spartan (44.19041.1266.0), Chromium (114.0.1823.67)
  npmPackages:
    @storybook/addon-actions: ^7.0.20 => 7.0.20
    @storybook/addon-controls: ^7.0.20 => 7.0.20
    @storybook/addon-docs: ^7.0.20 => 7.0.20
    @storybook/addon-essentials: ^7.0.20 => 7.0.20
    @storybook/addon-interactions: ^7.0.20 => 7.0.20
    @storybook/addon-links: ^7.0.20 => 7.0.20
    @storybook/addon-toolbars: ^7.0.20 => 7.0.20
    @storybook/blocks: ^7.0.20 => 7.0.20
    @storybook/react: ^7.0.20 => 7.0.20
    @storybook/react-webpack5: ^7.0.20 => 7.0.20
    @storybook/source-loader: 7.0.20 => 7.0.20
    @storybook/theming: ^7.0.20 => 7.0.20


### Additional context

the issue can be easily reproduced on a reproduction app for react 18 with typescript. just add extra stories for the Header component and set this in preview.js, then start the app

docs: {
      story: {
        inline: false,
      },
    }
Repository: godot
Issue: Switching to next script often doesn't switch the focus
Labels: bug,topic:editor,usability

### Godot version

v4.1.rc2.official [46424488e]

### System information

Windows 11

### Issue description

More often than not when using shortcut to switch to **next** script, even though opened script is switched, focus (cursor) is not moved to that file so one has to click to be able to actually work on that script. No problems observed when switching to **previous** script or using history next or history previous shortcuts.

https://github.com/godotengine/godot/assets/15647621/083464d5-9bd3-465a-988f-9d6a5b28cd0a


### Steps to reproduce

1. Open couple of scripts.
2. Use shortcut to switch to next script (default shortcut: `Ctrl+Shift+.`).
**Actual behaviour**
Open file is switched. Writing or navigating with arrows, etc. is not working. There is one line highlighted but there is no blinking cursor there.
**Expected behaviour**
File is switched. Cursor is in the last position it was in that file. Editing and navigation with keyboard is possible immidietly.

### Minimal reproduction project

N/A
Repository: pytorch
Issue: version libcudnn_ops_infer.so.8 not defined in file libcudnn_ops_infer.so.8 with link time reference
Labels: module: cuda,triaged


## Issue description

when I load one torch model ,it works,but when I load two torch models,it shows：
```
Could not load library libcudnn_cnn_infer.so.8. Error: /usr/local/cuda/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8: symbol _ZN5cudnn3ops18GetInternalStreamsEP12cudnnContextiPP11CUstream_st, version libcudnn_ops_infer.so.8 not defined in file libcudnn_ops_infer.so.8 with link time reference
Please make sure libcudnn_cnn_infer.so.8 is in your library path!
```
but I can found libcudnn_cnn_infer.so.8 file in this path:/usr/local/cuda/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8

## Code example
```python
from TTS.api import TTS
from faster_whisper import WhisperModel
tts = TTS(model_name="tts_models/multilingual/multi-dataset/your_tts", progress_bar=True, gpu=True)
tts_clone = TTS(model_name="voice_conversion_models/multilingual/vctk/freevc24", progress_bar=True, gpu=True)
whispter_model = WhisperModel(WHISPER_MODEL_PATH, device="cuda", compute_type="float16")
segments, info = whispter_model.transcribe(audio_file_path, beam_size=5, word_timestamps=True)
```
error information
```
Could not load library libcudnn_cnn_infer.so.8. Error: /usr/local/cuda/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8: symbol _ZN5cudnn3ops18GetInternalStreamsEP12cudnnContextiPP11CUstream_st, version libcudnn_ops_infer.so.8 not defined in file libcudnn_ops_infer.so.8 with link time reference
Please make sure libcudnn_cnn_infer.so.8 is in your library path!
```
then I just load one tts model,it works
```python
from TTS.api import TTS
from faster_whisper import WhisperModel
tts = TTS(model_name="tts_models/multilingual/multi-dataset/your_tts", progress_bar=True, gpu=True)
#tts_clone = TTS(model_name="voice_conversion_models/multilingual/vctk/freevc24", progress_bar=True, gpu=True)
whispter_model = WhisperModel(WHISPER_MODEL_PATH, device="cuda", compute_type="float16")
segments, info = whispter_model.transcribe(audio_file_path, beam_size=5, word_timestamps=True)
```

## System Info
![image](https://github.com/pytorch/pytorch/assets/22809208/8404d6e8-55db-4745-b475-7c76a87a2b97)


cc @ptrblck
Repository: tensorflow
Issue: Functions that limit video memory do not work
Labels: stat:awaiting tensorflower,type:performance,TF 2.12

### Issue type

Performance

### Have you reproduced the bug with TensorFlow Nightly?

No

### Source

binary

### TensorFlow version

tf2.12.0

### Custom code

Yes

### OS platform and distribution

MacOs

### Mobile device

_No response_

### Python version

3.9

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

We have many similar model building and training code files, and train multiple models consecutively through one process. But in this process, we used the memory blank and the restriction function, and neither worked.


### Standalone code to reproduce the issue

```shell
![image](https://github.com/tensorflow/tensorflow/assets/34181680/fbe4f5b6-255b-4583-b108-f476bd639574)
```

### Relevant log output

_No response_
Repository: godot
Issue: EditorFileSystemDirectory::find_file_index is extremely inefficient
Labels: bug,topic:editor,topic:import,performance

### Godot version

4.0.3

### System information

Windows 10

### Issue description

I have a project with ~360k assets. While you might say that this is quite a lot of assets, this is only 30% of the assets I have extracted from a game. When trying to open the project with godot the editor just bugs out completely. Just scanning the directory takes around 4 minutes with ~550us/file due to each file being opened around 5 times which not only causes a lot of kernel calls but also a lot of memory allocations. But the main issue seems to be `EditorFileSystem::_update_scan_actions` in particular `EditorFileSystemDirectory::find_file_index`, which for each file, goes through a vector of all files doing a string comparison on the name. As can be seen in the screenshot of the profiling I did down below, around 95% of the time is spent in `EditorFileSystemDirectory::find_file_index`. It seems to me using a better data structure here like a hash map would greatly increase the performance. Additionally making this multithreaded could also help a lot since most of this should be fairly independent of each other.

I have let this import run for 5h without any significant progress. As it stands I am unable to open the project with that many assets.

![image](https://github.com/godotengine/godot/assets/11277588/b338e938-d35f-46e8-8a94-1c36af96a385)


### Steps to reproduce

Place a ton of assets in the project folder. Open the editor.

### Minimal reproduction project

-
Repository: godot
Issue: 4.1 crashes when copy canvasLayer node (has child nodes)
Labels: bug,topic:editor,needs testing,crash

### Godot version

4.1.rc2

### System information

Godot v4.1.rc2 - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4060 Laptop GPU (NVIDIA; 31.0.15.3114) - AMD Ryzen 9 7940H w/ Radeon 780M Graphics (16 Threads)

### Issue description

pls see the video
https://github.com/godotengine/godot/assets/6269655/d6cda5b8-bf41-4c66-a995-67310f34ab37



### Steps to reproduce

-----
![image](https://github.com/godotengine/godot/assets/6269655/3d8ec3b7-cd57-411b-acde-e499ea568749)


### Minimal reproduction project

sorry project is too big
Repository: TypeScript
Issue: TS4082 occurs when using `composite: true`
Labels: Needs More Info

# Bug Report

### 🔎 Search Terms

TS4082, composite

### 🕗 Version & Regression Information

- I was unable to test this on prior versions because `composite` is a new feature added to typescript (not actually)

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior.
  This should have the same code as the code snippet below, and use whichever settings are relevant to your report.

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
[Playground link with relevant code](https://www.typescriptlang.org/play?ts=5.1.3#code/KYDwDg9gTgLgBAE2AMwIYFcA28AUBYAKAEhU4BeOHASnID44BvQoogSwDsZgo0BjYOAAUoEMAGdGAX2ZEowGOijspcVBOGixzSQBpCNMvQaSA3IUKZ5q8pQNHmHLj1T8hI8VOZyFSlWreahJJAA)

### 💻 Code

<!-- Please post the relevant code sample here as well. This code and the Playground code should be the same, do not use separate examples -->
```ts
// This throws
export default (
	a = () => {
		interface Props {}
		return {} as Props
	},
) => {};

// This works
let a = () => {
	interface Props {}
	return {} as Props
}
```

### 🙁 Actual behavior

When `composite` is enabled, the `export default` statement throws TS4082. And disabling `composite` fixes this issue.

### 🙂 Expected behavior

They should both throw, or both not throw :(

This issue only occurs when using an interface. Using a type alias won't cause this issue.
Repository: next.js
Issue: Default `modularizeImports` breaks lodash/chain in v13.4.8
Labels: Upstream,bug,linear: next

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
      Platform: linux
      Arch: x64
      Version: #22 SMP Tue Jan 10 18:39:00 UTC 2023
    Binaries:
      Node: 16.17.0
      npm: 8.15.0
      Yarn: 1.22.19
      pnpm: 7.1.0
    Relevant Packages:
      next: 13.4.9-canary.1
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 4.9.4
    Next.js Config:
      output: N/A
```


### Which area(s) of Next.js are affected? (leave empty if unsure)

_No response_

### Link to the code that reproduces this issue or a replay of the bug

https://codesandbox.io/p/sandbox/green-wind-524j6n?file=%2Fpages%2Findex.tsx

### To Reproduce

See codesandbox, running `yarn dev` with the simple example using `lodash/chain` will fail at runtime.
The same code runs fine in v13.4.7

There's also currently no way to override the configuration in userland: https://github.com/vercel/next.js/blob/4f75c7993815dac50a6db3e078c51e6ae8d5bbdc/packages/next/src/server/config.ts#L692

### Describe the Bug

The compiled code fails with the error:
```
TypeError: lodash_chain__WEBPACK_IMPORTED_MODULE_1___default(...)(...).filter is not a function
```

### Expected Behavior

The code should work (like in v13.4.7). I also think you should be able to override the default `modularizeImports` configuration in the user configuration, as new versions of libraries could also break this configuration, which would require a new Next.js release to fix.

### Which browser are you using? (if relevant)

N/A

### How are you deploying your application? (if relevant)

N/A

<sub>[NEXT-1401](https://linear.app/vercel/issue/NEXT-1401/default-modularizeimports-breaks-lodashchain-in-v1348)</sub>
Repository: deno
Issue: [Bug] Deno has panicked
Labels: needs info,panic

Hello,

The following app : https://git.kaki87.net/KaKi87/deno-api

Has crashed on my server with the following output :

```
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: linux x86_64
Version: 1.34.1
Args: ["deno", "run", "-A", "./main.js"]                                                  
thread 'main' panicked at 'OS can't spawn worker thread: Resource temporarily unavailable (os error 11)', /home/runner/work/deno/deno/core/task.rs:71:16                            stack backtrace:                                                                             0: rust_begin_unwind
             at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/std/src/panicking.rs:575:5                                                                                     1: core::panicking::panic_fmt
             at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/core/src/panicking.rs:64:14                                                                                    2: <deno_fs::std_fs::RealFs as deno_fs::interface::FileSystem>::read_file_async::{{closure}}                                                                                        3: <futures_util::future::future::Map<Fut,F> as core::future::future::Future>::poll       4: deno_core::runtime::queue_async_op                                                     5: deno_fs::ops::op_fs_read_file_async::v8_fn_ptr                                         6: _ZN2v88internal12_GLOBAL__N_119HandleApiCallHelperILb0EEENS0_11MaybeHandleINS0_6ObjectEEEPNS0_7IsolateENS0_6HandleINS0_10HeapObjectEEENS8_INS0_20FunctionTemplateInfoEEENS8_IS4_EEPmi                                                                                                at ./../../../../v8/src/builtins/builtins-api.cc:113:36
   7: _ZN2v88internal21Builtin_HandleApiCallEiPmPNS0_7IsolateE                                         at ./../../../../v8/src/builtins/builtins-api.cc:135:1                          8: Builtins_CEntry_Return1_ArgvOnStack_BuiltinExit
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
```

Thanks
Repository: stable-diffusion-webui
Issue: [Bug]: tqdm's total value always be 0
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?

when I try to get tqdm's total value via shared.total_tqdm._tqdm.total, it always be 0, therefore I cannot calculate the remaining time using tqdm's total value and rate value.

### Steps to reproduce the problem

1. Go to modules/shared.py
2. print(shared.total_tqdm._tqdm.total)


### What should have happened?

shared.total_tqdm._tqdm.total should be 0

### Version or Commit where the problem happens

v1.2.1

### What Python version are you running on ?

None

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

_No response_

### What device are you running WebUI on?

_No response_

### Cross attention optimization

Automatic

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

_No response_

### Command Line Arguments

```Shell
No
```


### List of extensions

No

### Console logs

```Shell
Null
```


### Additional information

_No response_
Repository: go
Issue: proposal: spec: allow type conversion from generic type to same underlying type
Labels: LanguageChange,Proposal,LanguageChangeReview

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version devel go1.21-f90b4cd655 Fri May 26 03:21:41 2023 +0000 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes
### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on go.dev/play is best.
-->

I compiled [this code](https://go.dev/play/p/tTq_X6I6z6A):

```
type A struct {
	a int
}
type B A

func F[T A | B](x *T) {
	x1 := (*A)(x)
	_ = x1
}
```

### What did you expect to see?

Compilation success. We know that all of the possible types of `*T` can be converted to `*A` so the conversion could be OK.

### What did you see instead?

```
./prog.go:9:13: cannot convert x (variable of type *T) to type *A
```

To work around this, we can use a type switch: https://go.dev/play/p/PfuuWgA4eNG

```
func F[T A | B](x *T) {
	var x1 *A
	switch x := any(x).(type) {
	case *A:
		x1 = x
	case *B:
		x1 = (*A)(x)
	case *string:
		x1 = nil
	}
	_ = x1
}
```

But this is considerably more verbose and also more error-prone, because it fail at run time if one of the types in the type set isn't mentioned in the type switch.
Repository: rust
Issue: Spurious reborrowing errors when returning lifetimes referencing mutable borrows from inside loops
Labels: A-borrow-checker,T-compiler,C-bug,S-has-mcve

<!--
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.
-->

I tried this code:

```rust
struct Foo {
    value: u32,
}

impl Foo {
    pub fn next<'a>(&'a mut self) -> &'a u32 {
        loop {
            self.value = 123;

            let value = &self.value;

            static COND: bool = true;
            if COND {
                return value;
            }
        }
    }
}
```

I expected to see this happen: It to compile successfully, like it does without the loop:

```rust
struct Foo {
    value: u32,
}

impl Foo {
    pub fn next<'a>(&'a mut self) -> &'a u32 {
        self.value = 123;

        let value = &self.value;

        static COND: bool = true;
        if COND {
            return value;
        }

        panic!()
    }
}
```

Instead, this happened:

```
error[E0506]: cannot assign to `self.value` because it is borrowed
  --> <source>:8:13
   |
6  |     pub fn next<'a>(&'a mut self) -> &'a u32 {
   |                 -- lifetime `'a` defined here
7  |         loop {
8  |             self.value = 123;
   |             ^^^^^^^^^^^^^^^^ `self.value` is assigned to here but it was already borrowed
9  |
10 |             let value = &self.value;
   |                         ----------- `self.value` is borrowed here
...
14 |                 return value;
   |                        ----- returning this value requires that `self.value` is borrowed for `'a`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0506`.
```

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.70.0 (90c541806 2023-05-31)
binary: rustc
commit-hash: 90c541806f23a127002de5b4038be731ba1458ca
commit-date: 2023-05-31
host: x86_64-pc-windows-msvc
release: 1.70.0
LLVM version: 16.0.2
```

Also repros on nightly: https://godbolt.org/z/hEdjnz5oE
Repository: flutter
Issue: `LongPressMoveUpdateDetails` does not contain `delta` like  `ScaleUpdateDetails`
Labels: c: new feature,framework,f: gestures,c: proposal,P3,team-framework,triaged-framework

### Is there an existing issue for this?

- [X] I have searched the [existing issues](https://github.com/flutter/flutter/issues)
- [X] I have read the [guide to filing a bug](https://flutter.dev/docs/resources/bug-reports)

### Use case

I want to get the delta `onLongPressMoveUpdate` when moving like what happens `onScaleUpdate` and `DragUpdateDetails`

### Proposal

Just provide `delta` on the `LongPressMoveUpdateDetails`

or suggest another solution so I can calculate the delta from the current provided details
Repository: PowerToys
Issue: Convert Accented Characters to Normal English
Labels: Needs-Triage

### Description of the new feature / enhancement

Convert accented characters to normal English when the text is copied to clipboard. There are many instances where we need to use website to convert accented characters to normal english. Excel also does not support many characters and neither Autohotkey. 

### Scenario when this would be used?

While working on invoices and freelancing

### Supporting information

_No response_