sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: material-ui
Issue: Accordion: disable separator
Labels: component: accordion,enhancement,customization: css

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Summary 💡

I'd like a prop to disable the separator between accordions. Right now there exists a grey line between each two accordions that I haven't asked for. It's too late now to only render them when a hypothetical `enableSeparators` prop is included, so we could now provide a `disableSeparators` prop instead.

Only workaround atm is to set `content: none` via a `styleOverrides`, which always feels kind of hacky. I mean, what if MUI in the future decides to draw this line using any other line drawing method? Then this override will no longer have any effect.

### Examples 🌈

These lines I'd like to remove:
![image](https://user-images.githubusercontent.com/152227/234275617-75e0c8e5-0152-439b-be49-5c14cc7109e1.png)

This has already applied default props in the theme:
```
MuiAccordion: {
  defaultProps: {
    disableGutters: true,
    square: true,
    elevation: 0,
  },
}
```

Now the line above an expanded accordion disappears because it is moved to `top: -1px` which is weird on its own, but I'm sure there's a reason behind doing it that way. More importantly, I want them all gone, all the time.

### Motivation 🔦

Motivation is, well, design I guess? Our designer wants them gone, that's all 😀
Repository: kubernetes
Issue: kube-apiserver: whether need to check  listGVKs slice is empty in registerResourceHandler functions?
Labels: kind/bug,sig/api-machinery,triage/accepted

### What happened?

`ListGVKs`, `getOptionsInternalKind` and `connectOptionsInternalKinds` slice may be empty in `registerResourceHandler` function.


### What did you expect to happen?

We need to check `listGVKs`, `getOptionsInternalKind` and `connectOptionsInternalKinds` slice is empty?

### How can we reproduce it (as minimally and precisely as possible)?

Look at the `registerResourceHandler` function:

reference:
- https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/endpoints/installer.go#L355
- https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/endpoints/installer.go#L411
- https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/endpoints/installer.go#L445

### Anything else we need to know?

_No response_

### Kubernetes version

<details>

```console
$ kubectl version
# paste output here
```

</details>


### Cloud provider

<details>

</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>
Repository: yt-dlp
Issue: dates for playlist: `playlist_upload_date` , `playlist_release_date` , ...
Labels: enhancement,triage,core:extractor

### DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

- [X] I understand that I will be **blocked** if I *intentionally* remove or skip any mandatory\* field

### Checklist

- [X] I'm requesting a feature unrelated to a specific site
- [X] I've looked through the [README](https://github.com/yt-dlp/yt-dlp#readme)
- [X] I've verified that I'm running yt-dlp version **2023.03.04** ([update instructions](https://github.com/yt-dlp/yt-dlp#update)) or later (specify commit)
- [X] I've searched [known issues](https://github.com/yt-dlp/yt-dlp/issues/3766) and the [bugtracker](https://github.com/yt-dlp/yt-dlp/issues?q=) for similar issues **including closed ones**. DO NOT post duplicates
- [X] I've read the [guidelines for opening an issue](https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#opening-an-issue)

### Provide a description that is worded well enough to be understood

The available date fields (`timestamp`, `upload_date`, `release_date`, `modified_date`, etc.) all refer to the playlist items (or the single video in case of a single download).

Can any date for the playlist be retrieved ?
If so, I would like to request this as a feature:
something like `playlist_upload_date` , `playlist_release_date` etc.

### Provide verbose output that clearly demonstrates the problem

- [ ] Run **your** yt-dlp command with **-vU** flag added (`yt-dlp -vU <your command line>`)
- [ ] If using API, add `'verbose': True` to `YoutubeDL` params instead
- [ ] Copy the WHOLE output (starting with `[debug] Command-line config`) and insert it below

### Complete Verbose Output

_No response_
Repository: pytorch
Issue: torch.cuda.is_available() crashes python in systems with disabled gpu
Labels: module: crash,module: cuda,triaged,module: edge cases

### 🐛 Describe the bug

Recently, whenever I call torch.cuda.is_available(), my python interpreter suddenly crashes. However, this only happens when using it in the "wild", when calling it in PyCharm, everything works fine.

It might be because of the laptop I'm using, which disables the nvidia gpu when in battery mode, however, it worked before. _This crash only happens in battery mode with the disabled gpu._ 
**Although this might be a strangely unusual setup, this call should still not crash the entire interpreter.**

This happened in torch 1.13 as well as in 2.0.0.
I updated the python interpreter as well as all packages, but it did not help so far.
I'm using python 3.10.11 in a venv with CUDA 11.7.1 on Win11.

I also tried surrounding the call with try-except, to catch possible uncaught exceptions, however with no success.

Whenever I execute the file containing the cuda-check, or type it directly into the interpreter, the process crashes and exits, without any further message, except for the exit code: -1073740791 (0xC0000409).

```
import torch.cuda
torch.cuda.is_available()
```

### Versions

```
PyTorch version: 2.0.0+cu117
Is debug build: False
CUDA used to build PyTorch: 11.7
ROCM used to build PyTorch: N/A

OS: Microsoft Windows 11 Home
GCC version: Could not collect
Clang version: Could not collect
CMake version: version 3.24.0
Libc version: N/A

Python version: 3.10.11 (tags/v3.10.11:7d4cc5a, Apr  5 2023, 00:38:17) [MSC v.1929 64 bit (AMD64)] (64-bit runtime)
Python platform: Windows-10-10.0.22621-SP0
Is CUDA available: True
CUDA runtime version: 11.7.99
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration: GPU 0: NVIDIA GeForce GTX 1650 with Max-Q Design
Nvidia driver version: 531.61
cuDNN version: C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.7\bin\cudnn_ops_train64_8.dll
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Architecture=9
CurrentClockSpeed=3201
DeviceID=CPU0
Family=107
L2CacheSize=4096
L2CacheSpeed=
Manufacturer=AuthenticAMD
MaxClockSpeed=3201
Name=AMD Ryzen 7 5800HS with Radeon Graphics
ProcessorType=3
Revision=20480

Versions of relevant libraries:
[pip3] numpy==1.24.3
[pip3] torch==2.0.0+cu117
[pip3] torchvision==0.15.1+cu117
[conda] Could not collect


```

cc @ngimel
Repository: vscode
Issue: SCM - highlight repositories with uncommitted changes
Labels: feature-request,ux,scm

<!-- ⚠️⚠️ 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 work on many repositories at the same time.
In the source control view, apart from the little star, it's 
not clear if there are changes in any of the repositories.

I see there are 8 changes somewhere but need to find the repo with the *.
Maybe a different font color would help?

![image](https://user-images.githubusercontent.com/5886651/234282951-ae44ec77-7b3a-4e51-bd11-030727a0f8a2.png)
Repository: opencv
Issue: Test for LSTM with hidden states as inputs fail on CUDA 
Labels: bug,category: dnn

### System Information

With CUDA skip flag switched off some tests for LSTM fail.
CUDA implementation for LSTM with hidden states needs to be updated.
To be updated later!!

### Detailed description

Error log 


```bash
[  FAILED  ] Test_ONNX_layers.LSTM_init_h0_c0/0, where GetParam() = CUDA/CUDA
[  FAILED  ] Test_ONNX_layers.LSTM_init_h0_c0/1, where GetParam() = CUDA/CUDA_FP16
```

### Steps to reproduce

```bash 
cd build/bin
./opencv_test_dnn
```

### 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: go
Issue: runtime: support TLS slot indices over 64 on Windows
Labels: OS-Windows,NeedsInvestigation,compiler/runtime

Since go 1.20, the Go runtime allocates the TLS slot in the [TEB](https://learn.microsoft.com/en-us/windows/win32/api/winternl/ns-winternl-teb) TlsSlots instead of using the [TEB arbitrary pointer](https://devblogs.microsoft.com/oldnewthing/20190418-00/?p=102428). See [CL 431775](https://go.dev/cl/431775) for more context.

The problem is that the static TEB TlsSlots array only has capacity for 64 indices, when more slots are required [TlsAlloc](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-tlsalloc) allocates them on a heap-allocated array. [TlsGetValue](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-tlsgetvalue) abstracts this implementation detail, but we don't use `TlsGetValue` and our logic to retrieve the TLS value does not currently support retrieving the value from TlsSlots or the heap depending on the index.

For now I've submitted [CL 486816](https://go-review.googlesource.com/c/go/+/486816) to fallback to the old behavior (TEB arbitrary pointer) in case the TLS index is higher than 64. This solution is temporal, as we should rely on the TEB arbitrary pointer.

This issue should track the effort (small or big, still don't know) to implement a solution that supported TLS indices higher than 64.
Repository: go
Issue: proposal: crypto/tls: new option for mTLS servers to not advertise acceptable certificate_authorities
Labels: Proposal,Proposal-Crypto

## Problem

A Golang mTLS server includes a list of Distinguished Names of acceptable CAs in the TLS handshake. In some threat models, the name of the CAs the server accepts may represent an information leak. Especially, if the CA is use-case specific and contains information about the customer; like this example from the Google space: https://buganizer.corp.google.com/issues/187209748

Currently, the tls/crypto package does not provide a way to not populate `certificate_authorities`, even though it is not mandatory part of the handshake.

## Solution

This could be addressed by adding a new boolean field (something like `DontAdvertiseClientCAs bool`) in `tls.Config` to disable this behavior optionally.
Servers that prefer not advertising the CA names could opt-out by flipping this new setting.
Repository: vscode
Issue: [Feature Request] Add predefined variable with separator for environment variable PATH (also PYTHONPATH, CLASSPATH etc.)
Labels: feature-request,variable-resolving

<!-- ⚠️⚠️ 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 would like to request a new [predefined variable](https://code.visualstudio.com/docs/editor/variables-reference), e.g. `${pathListSeparator}`, that would be substituted with the separator used in the operating system's `PATH` environment variable, e.g. `:` for POSIX or `;` for Windows.

Similarly to [this feature request regarding `${pathSeparator}`](https://github.com/microsoft/vscode/issues/180827), I would also like it to have a shorter alias for improved readability, e.g. `${:}`.

The variable could be used for modifications of not only the OS's `PATH` but also other environment variables that follow the same convention, e.g. [Python's `PYTHONPATH`](https://docs.python.org/3/using/cmdline.html#envvar-PYTHONPATH), [Java's `CLASSPATH`](https://docs.oracle.com/javase/8/docs/technotes/tools/windows/classpath.html), etc.
Repository: go
Issue: x/pkgsite: links in README.md are having the #anchor stripped so don't link to a subsection of the external doc
Labels: NeedsInvestigation,pkgsite

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What is the URL of the page with the issue?

https://pkg.go.dev/github.com/speakeasy-api/speakeasy-client-sdk-go#section-readme


### What is your user agent?

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36

### Screenshot

![image](https://user-images.githubusercontent.com/108070248/234317290-91693589-cd93-4429-9229-4d203def1652.png)

### What did you do?

Clicking any of the links in the render Readme section of the pkg.go.dev page for a module, will take you to a link for example https://github.com/speakeasy-api/speakeasy-client-sdk-go/blob/v1.15.1/docs/apiendpoints/README.md which is missing the anchor that was originally in the README.md ie https://github.com/speakeasy-api/speakeasy-client-sdk-go/blob/v1.15.1/docs/apiendpoints/README.md#findapiendpoint

### What did you expect to see?

That anchor's are retained when rendering the links in the readme section.


### What did you see instead?

The anchors are removed and there for the links don't link to the same place as the original markdown links
Repository: go
Issue: cmd/compile: generic code behaves differently from non-generic code
Labels: NeedsInvestigation,compiler/runtime

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.20.3 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes

### What did you do?

```Go
package main

type I interface {
	M(int)
	P()
}

type V int

func (v V) P()       { println(v) }
func (v *V) M(n int) { *v = V(n) }

type S struct{ *V }

func F[T I](x T) {
	defer x.P()
	x.M(9)
}

func G(x *S) {
	defer x.P()
	x.M(9)
}

func main() {
	{
		var s = S{V: new(V)}
		F(&s) // 9
	}
	{
		var s = S{V: new(V)}
		G(&s) // 0
	}
}
```

### What did you expect to see?

Same behavior.

### What did you see instead?

Different behavior.
Repository: go
Issue: proposal: x/playground: support SVG images in output
Labels: Proposal

The Go playground currently supports displaying images if your output consists of the string "IMAGE:" followed by a base64-encoded PNG (or, presumably because browsers are permissive, GIF).

It would be nice to support SVG images too. The patch is very small: in fact, I created a change (in the wrong place!), but @dmitshur suggested a discussion here would be appropriate. The necessary diff can be seen [here](https://go-review.googlesource.com/c/tools/+/382249/1/godoc/static/playground.js).
Repository: storybook
Issue: [Bug]: Full Changelog URL going to "next" branch
Labels: bug,needs triage

### Describe the bug

The URL of the full changelog is pointing to the `next` branch instead of https://github.com/storybookjs/storybook/blob/main/CHANGELOG.md

Spotted this small detail in 2 places

- CLI
```
A new version (7.0.7) is available!

Upgrade now: npx storybook@latest upgrade

Read full changelog: https://github.com/storybookjs/storybook/blob/next/CHANGELOG.md
```

- about page (http://localhost:6006/?path=/settings/about)

![changelog-link](https://user-images.githubusercontent.com/5560784/234326629-e34f8b59-bf7f-4a20-828e-784d918baf31.jpg)


### To Reproduce

Visible on any storybook

### System

_No response_

### Additional context

_No response_
Repository: rust
Issue: Enum variants containing Vec not formatted in WinDbg
Labels: A-debuginfo,O-windows-msvc,C-bug

```rust
fn main() {
    let foo = Some(vec![1, 2, 3]);
}
```

Breaking after `let foo ...` and using `dv` does not print the enum variant name for `foo`. Then, examining `foo` with `dx` only gives `    [<Raw View>]     [Type: enum2$<core::option::Option<alloc::vec::Vec<i32,alloc::alloc::Global> > >]` with no further data.

### Meta

Rust stable 1.69.0:
```
rustc 1.69.0 (84c898d65 2023-04-16)
binary: rustc
commit-hash: 84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc
commit-date: 2023-04-16
host: x86_64-pc-windows-msvc
release: 1.69.0
LLVM version: 15.0.7
```

Also on Rust nightly:
```
rustc 1.71.0-nightly (f5559e338 2023-04-24)
binary: rustc
commit-hash: f5559e338256f17ada6d82b429acc2dbd8facc9c
commit-date: 2023-04-24
host: x86_64-pc-windows-msvc
release: 1.71.0-nightly
LLVM version: 16.0.2
```
Repository: rust
Issue: Slow enum printing in WinDbg
Labels: O-windows,A-debuginfo,T-compiler,C-bug,WG-debugging

In a minimal case like:
```Rust
fn main() {
    let foo = vec![Some(1), Some(2), Some(3)];
}
```
Examining `foo` with `dx` takes around a second to print each member of the Vec, which is already pretty slow, but it can get slower based on something seemingly related to the debugee program as a whole, possibly the amount of code or the size of the pdb.

For example, putting `let foo = vec![Some(1), Some(2), Some(3)];` at the start of `main` in a ~2210 LoC program with a 10.1 MB pdb and examining that with WinDbg, it takes around 20 seconds for each member in the Vec.

Extracting out 1 module (a not correct solution for AoC 2022 day 13 part 1) from the previously mentioned program for ~108 LoC and a 2.35 MB pdb, then examining the same `foo` at the start of the program results in around 3 seconds for each member in the Vec.

Rust version:
```
rustc 1.69.0 (84c898d65 2023-04-16)
binary: rustc
commit-hash: 84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc
commit-date: 2023-04-16
host: x86_64-pc-windows-msvc
release: 1.69.0
LLVM version: 15.0.7
```

WinDbg version: 10.0.14321.1024
OS: Windows 10 Pro 22H2 19045.2846
CPU: Ryzen 5 3600
Repository: go
Issue: net: TestBuffers_WriteTo failures
Labels: NeedsInvestigation

```
#!watchflakes
post <- pkg == "net" && test == "TestBuffers_WriteTo"
```

Issue created automatically to collect these failures.

Example ([log](https://build.golang.org/log/57da3f5aa13a101a12972cc1d02011351ecfeead)):

    --- FAIL: TestBuffers_WriteTo (38.65s)
        --- FAIL: TestBuffers_WriteTo/WriteTo/0 (25.92s)
            writev_test.go:120: dial tcp 127.0.0.1:50922: connect: operation timed out


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: vscode
Issue: VS Code crashes when opening a window on Ubuntu
Labels: upstream,freeze-slow-crash-leak,linux,upstream-issue-linked,chromium

1. Run `code --disable-gpu --disable-extensions` (repros both with and without these flags)
2. See a VS Code window appear briefly then crash

[vscode-crash.zip](https://github.com/microsoft/vscode/files/11324771/vscode-crash.zip)

This happens on Ubuntu 22.04, but not my other Ubuntu 18.04 VM.
Repository: flutter
Issue: ☂️ Umbrella issue for replace deprecated `[UIScreen mainScreen]` in iOS 16
Labels: platform-ios,engine,P2,c: tech-debt,team-ios,triaged-ios

One instance was introduced in https://github.com/flutter/engine/pull/41460

### Use Case
`UIScreen mainScreen` is deprecated in iOS 16 per https://developer.apple.com/documentation/uikit/uiscreen/deprecated_symbols. We should use the recommended replacement `UiWindowScene` which was added in iOS 13 to support multiple windows and provide a fallback for iOS 11 & 12.

### Proposal
There are several places where the deprecated `UIScreen mainScreen` is used and should be replaced:
| File Name | Tracking Issue |
| ---------- | -------------- |
| `FlutterViewController.mm` &amp; `FlutterViewControllerTest.mm` | <ul/><li>[x] https://github.com/flutter/flutter/issues/128260</li></ul> |
| `FlutterPlatformViews_Internal.mm` | <ul/><li>[ ] https://github.com/flutter/flutter/issues/130825</li></ul> |
| `FlutterDartProject.mm` &amp;  `FlutterDartProjectTest.mm` | <ul/><li>[ ] https://github.com/flutter/flutter/issues/130826</li></ul> |
| `FlutterView.mm` | <ul/><li>[x] https://github.com/flutter/flutter/issues/130828</li></ul> |
| `vsync_waiter_ios.mm` | <ul/><li>[ ] https://github.com/flutter/flutter/issues/130829</li></ul> |
| `SemanticsObject.mm` | <ul/><li>[ ] https://github.com/flutter/flutter/issues/130830</li></ul> |
| `FlutterPlatformViews.mm` &amp; `FlutterPlatformViewsTest.mm` | <ul/><li>[ ] https://github.com/flutter/flutter/issues/130832</li></ul> |
| `AppDelegate.m` | <ul/><li>[ ] https://github.com/flutter/flutter/issues/130833</li></ul> |

### Out of Scope
Currently, most Flutter behavior is built and tested for the single window. The simple replacement proposed in this issue may not address all multi-window scenario cases.
Repository: rust
Issue: Incorrect "ambiguous associated type" report
Labels: A-diagnostics,T-compiler

### Code

```Rust
struct Foo {}

impl Foo {
    const fn foo(&self) -> &'static str {
        "hello"
    }
}

struct Bar {}

impl Bar {
    const FOO:Foo = Foo {};
}

fn main() {
    println!("{}", Bar::FOO::foo());
}
```


### Current output

```Shell
Compiling playground v0.0.1 (/playground)
error[E0223]: ambiguous associated type
  --> src/main.rs:16:20
   |
16 |     println!("{}", Bar::FOO::foo());
   |                    ^^^^^^^^
   |
help: if there were a trait named `Example` with associated type `FOO` implemented for `Bar`, you could use the fully-qualified path
   |
16 |     println!("{}", <Bar as Example>::FOO::foo());
   |                    ~~~~~~~~~~~~~~~~~~~~~

For more information about this error, try `rustc --explain E0223`.
error: could not compile `playground` due to previous error
```


### Desired output

```Shell
TBD, but the error is `FOO::foo()` instead of `FOO.foo()`
```


### Rationale and extra context

_No response_

### Other cases

_No response_

### Anything else?

_No response_
Repository: TypeScript
Issue: tsc utility freezes 
Labels: Needs Investigation

# Bug Report

### ⏯ Playground Link

[Playground link with relevant code](https://codesandbox.io/p/sandbox/frosty-mcnulty-ci2jrk?file=%2Fsrc%2Ftest.tsx&selection=%5B%7B%22endColumn%22%3A49%2C%22endLineNumber%22%3A20%2C%22startColumn%22%3A49%2C%22startLineNumber%22%3A20%7D%5D)

### 🙁 Actual behavior

I have a project using graphql. Together with him I use a package for code generation. A large file with types is generated. Based on one of the types, I want to make a form in react-hook-form. It works great until you need to extend this type.
If you comment out the 12th line in the src/test file, then tsc will work, otherwise it freeze

when logs are turned on, the problem disappears
![telegram-cloud-photo-size-2-5352541729682737455-x](https://user-images.githubusercontent.com/12747633/234500903-9d22b64b-df23-4d2d-b306-c181541ff48d.jpg)


### 🙂 Expected behavior

tsc not freezes :)