sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: material-ui
Issue: Cannot override PaginationItem component slots with a button component due to ValidateDOMNesting error.
Labels: package: material-ui,component: pagination,customization: dom

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Steps to reproduce 🕹

Link to live example:
[Codesandbox](https://codesandbox.io/s/elated-night-qs37lt?file=/src/App.tsx)
Steps:

1. Load sandbox
2. See error in console


### Current behavior 😯

The slots inside PaginationItem provide a method for adding your own custom component for previous/next buttons etc. Currently you can do this, but if your custom component is a button, you get a validateDOMNesting error as the slot is for the child of a button component.

### Expected behavior 🤔

I'd have expected that when adding your own custom component for the previous/next slots, it would replace the entire button component instead of just being a child of button.

### Context 🔦

I get that this functionality may have been created to replace the icons for the navigational buttons. However, it makes much more sense to allow the user to add in their own custom button components for these slots. 

### Your environment 🌎

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  System:
    OS: macOS 12.4
  Binaries:
    Node: 14.19.3 - ~/.nvm/versions/node/v14.19.3/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v14.19.3/bin/yarn
    npm: 6.14.17 - ~/.nvm/versions/node/v14.19.3/bin/npm
  Browsers:
    Chrome: 114.0.5735.106
    Edge: 114.0.1823.37
    Firefox: 109.0.1
    Safari: 15.5
  npmPackages:
    @emotion/react: ^11.9.3 => 11.10.6
    @emotion/styled: ^11.9.3 => 11.10.6
    @mui/base:  5.0.0-alpha.119
    @mui/core-downloads-tracker:  5.11.11
    @mui/icons-material: ^5.8.4 => 5.11.11
    @mui/lab:  5.0.0-alpha.134
    @mui/material: ^5.9.2 => 5.11.11
    @mui/private-theming:  5.11.11
    @mui/styled-engine:  5.11.11
    @mui/styles: ^5.9.2 => 5.11.11
    @mui/system:  5.11.11
    @mui/types:  7.2.3
    @mui/utils:  5.11.11
    @types/react: ^18.0.28 => 18.0.28
    react: ^18.2.0 => 18.2.0
    react-dom: ^18.2.0 => 18.2.0
    typescript: ^4.3.4 => 4.9.5
```
</details>
Repository: electron
Issue: [Feature Request]: Consider changing the GPU-process name
Labels: enhancement :sparkles:

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

Guys from Yandex Browser Team found out interesting thing - setting GPU-process name as _"chrome.exe"_ forces video driver to apply some optimizations designed for chromium. During A/B testing they got: GPU-process crashes reduced to 5.5 times, memory usage decreased by 8%, and improved UI responsiveness for AMD users .
Unfortunately, I did not find this confirmation on any English-language resource. I enclose the [original in Russian](https://habr.com/ru/companies/yandex/articles/721374/).

### Proposed Solution

As suggested in the article - setup hook for winapi `GetModuleFilenameA/GetModuleFilenameW` and `GetModuleFilenameExA/GetModuleFilenameExW` and return _"chrome.exe"_ name in case of GPU-process.

### Alternatives Considered

-

### Additional Information

_No response_
Repository: vscode
Issue: Bug (?): auto-trim of trailing whitespace on the cursor line
Labels: feature-request,editor-contrib

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->

With the "Trim Trailing Whitespace" (`files.trimTrailingWhitespace`) option enabled, trailing whitespace is removed even on the cursor line (see below). I consider this to be a bug because in #24601 @alexdima indicated that the intended behavior is for trailing spaces to not be deleted in the cursor line. And also, current behavior is quite annoying and to my knowledge, other editors keep the line under cursor intact in similar situations.

Examples of where this behavior is really annoying:
- I finished writing a portion of the code, hit enter to get to the next line to continue on to the next portion (at this moment, the cursor is at correct indentation), and decide to save at this point. Cursor is then flung back to the beginning of the line and I have to hit tab several times to get back to my indentation.
- I start creating a variable and type `int `, then pause to think of a variable name, instinctively hit cmd+s, my space disappears.

![output](https://github.com/microsoft/vscode/assets/1805832/a2b1e3e7-6d01-4e5b-bdff-7603a7db5ced)

Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.79.1 (`4cb974a7aed77a74c7813bdccd99ee0d04901215`)
- OS Version: macOS Ventura 13.4 (22F66)

Steps to Reproduce:

1. Create/open any file
2. Enter several trailing spaces in any line and leave the cursor where it is
3. Hit Save: the trailing spaces will be removed

Expected behavior: the trailing spaces under the cursor remain and the "save" action does not move the cursor.

It would probably be the least invasive if
a) this is an option (aka a second checkbox "Leave the cursor line as-is"
b) it may be ok to delete trailing whitespace (i.e., keep the current behavior) if the cursor is on the line but not adjacent to the trailing whitespace. I would say that the rule of thumb here should be: **save function should not move the cursor**.

The main point is that saving should not move the cursor and it should not affect or remove things that were _just_ typed.
Repository: kubernetes
Issue: dynamic resource allocation: add e2e (and unit) test to ensure the reuse of the gRPC connection
Labels: area/kubelet,sig/node,priority/important-longterm,lifecycle/rotten,needs-triage

[PR](https://github.com/kubernetes/kubernetes/pull/118619) introduces the reuse of the gRPC connection instead of creating a new one each time `NodePrepareResource` and `NodeUnprepareResource` are called.
This should be covered by e2e (and unit if possible) test
```[tasklist]
### Tasks
- [x] add unit test
- [ ] add e2e test
```
Repository: vscode
Issue: Column Select / Multiple Cursors: Ability to not have cursor inserted in wrapped part of wrapped text, without need to disable line wrap
Labels: bug,editor-multicursor

<!-- ⚠️⚠️ 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. -->
Is this possible?

![MultiCursor](https://github.com/microsoft/vscode/assets/1332009/e2a910eb-480a-4b63-a942-c3b084b6d227)
Repository: TypeScript
Issue: Autoimport: Prefer Secondary Entrypoint
Labels: Suggestion,Awaiting More Feedback,Domain: Auto-import

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

## 🔍 Search Terms

<!--
  💡 Did you know? TypeScript has over 2,000 open suggestions!
  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.
  The "Common Feature Requests" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests

  Replace the text below:
-->

- secondary auto import

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

<!-- A summary of what you'd like to see added or changed -->

When auto importing it would be nice if the importer prefered `secondary` entry points instead of main entry point, as it gets tiresome having to modify or manually write the imports to use a secondary entry point. 

**Note:** It does use the secondary entrypoint if it has already been defined in the file. However, this is for on initial import.

## 📃 Motivating Example

<!--
  If you were announcing this feature in a blog post, what's a short explanation that shows
  a developer why this feature improves the language?
-->

This allows compilers (such as webpack) to tree-shaking. If including the main entry point all modules get included in the build (for libraries that have them all exported in the main entry point) whereas importing secondary entry points only includes (usually) parts of the library.

## 💻 Use Cases

<!--
  What do you want to use this for?
  What shortcomings exist with current approaches?
  What workarounds are you using in the meantime?
-->

Workaround: Manually updating every import every time.
Repository: rust
Issue: Const-eval `InterpError`: error enum variants vs `throw_ub_custom!`
Labels: C-cleanup,T-compiler,A-const-eval

Currently we have dedicated error variants for many interpreter errors in our `InterpError` enum, but for some errors we use `throw_ub_custom!` to directly pick a translatable diagnostic instead of a variant.

The original purpose of these variants was to
- make sure the same error looks the same when raised from multiple locations
- avoid expensive operations such as string formatting when constructing an error, if it is never actually shown to the user (because it is caught again later, e.g. during value validation)

The first point doesn't really apply any more with translatable diagnostics. And the overhead of these error variants is quite significant; they each need an arm in `diagnostic_message` and `add_args`. (And these two things need to be carefully synced, since `diagnostic_message` decides which arguments need to be added later! Would be nice if these could be syntactically together somehow. Right now not only are we using an entirely untyped system here without any checks whether the right arguments are being added, we also have setting the arguments quite far removed from the only place that could potentially tell us which arguments are the right ones. That's pretty bad for maintenance.) That makes it tempting to convert errors to `throw_ub_custom!` and reduce this boilerplate, but I don't know if that is a good idea -- @fee1-dead suggested we should avoid `throw_ub_custom!`.

I also see some `throw_ub_custom!` do expensive work on error creation (such as [this](https://github.com/rust-lang/rust/blob/dbe31bb693b8d7a44a52162132c7e1f4a84cdeb5/compiler/rustc_const_eval/src/interpret/intrinsics.rs#L549-L553)), though under the hood the macro puts this into a thunk so -- if the error is never rendered, does the `format!` ever happen?

Either way, we should come up with some kind of consistent policy here. We have a lot of `throw_ub_custom!` currently (34 to be precise), I don't quite see the point of turning them all into variants -- that would be a lot of work, for which gain?
Repository: flutter
Issue: Improved `Tooltip` accessibility/focus
Labels: framework,f: material design,P2,team-design,triaged-design

There's an improved internal version of the `Tooltip` which handles focus better.

- If you hover and unhover, the tooltip will be dismissed even if it's still in focus.
- If you scroll while the widget is focused, the tooltip does not follow the underlying child.
- If the parent rebuilds, it can cause the tooltip to be dismissed.

Related issue: https://github.com/flutter/flutter/issues/126069

Google issue: b/260200652
Repository: ant-design
Issue: Tree Select loses expansion state after search and select a node when treeDefaultExpandedKeys is present
Labels: Inactive,unconfirmed

### Reproduction link

[https://stackblitz.com/edit/react-ydjxkw?file=demo.tsx](https://stackblitz.com/edit/react-ydjxkw?file=demo.tsx)

### Steps to reproduce

1. Type values in the select box to search
2. Select a node in the tree from the search result
3. Watch the tree blinks for a fraction of a second, then the nodes are collapsed and the expansion state is then lost

### What is expected?

When `treeDefaultExpandedKeys` is present, search and selecting a node from the tree should behave the same way as when it is not present, i.e. preserving the expansion state.

### What is actually happening?

The tree expansion state is only preserved when `treeDefaultExpandedKeys` is not present.

If the tree nodes are selected from expanding the nodes level by level instead of a search, the expansion state is also preserved.

| Environment | Info |
| --- | --- |
| antd | 5.6.1 |
| React | 17 ,18  |
| System | Windows |
| Browser | Chrome 113 |

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: godot
Issue: Area with HeightMapShape collision shape does not detect collisions when Bullet engine is used
Labels: bug,topic:physics,topic:3d

### Godot version

3.5.1.stable.official

### System information

Windows 10

### Issue description

When CollisionShape node with HeightMapShape added to Area, then "body_entered" signal not triggered when some RigidBody passes though that Area.

If I use ConvexPolygon as a collision shape, all works as expected.

If I manually set Physics Engine to Godotengine, it works. So it seems to be a problem with Bullet engine only.

### Steps to reproduce

1. Open project attached
2. Run default scene
3. Right ball will disappear (because area with ConvexPolygon detected collision and code when `queue_free()` is called)
4. Left ball will fall through Area with HeighMapShape

### Minimal reproduction project

[height-map-area-problem.zip](https://github.com/godotengine/godot/files/11747342/height-map-area-problem.zip)
Repository: flutter
Issue: PopupMenu Material 3 tokens
Labels: framework,f: material design,P2,team-design,triaged-design

### 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

https://github.com/flutter/flutter/blob/master/dev/tools/gen_defaults/data/menu.json seems to be incomplete. 

For some reason, I had to hardcode this label style for the popup menu a year ago.
https://github.com/flutter/flutter/blob/40bb615b0c96b2ca2ec2777fe9ea6aa20c815b14/dev/tools/gen_defaults/lib/popup_menu_template.dart#L26


When looking into https://github.com/flutter/flutter/issues/128576, this issue was rediscovered.

https://m3.material.io/components/menus/specs mentions the label large text style. 
However, this isn't available in menu tokens or list item tokens.
![Screenshot 2023-06-14 at 17 59 03](https://github.com/flutter/flutter/assets/48603081/7ff9294b-ea8c-4947-81f5-3085e5093452)


I can see such a token in Compose https://github.com/androidx/androidx/blob/androidx-main/compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/tokens/MenuTokens.kt

### Proposal

If the tokens are missing, add them.

or 

Use the list item label token and update M3 web specs to reflect the same.
Repository: vscode
Issue: "self signed certificate in certificate chain" while attempting to install an extension via command line
Labels: feature-request,proxy

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.79.0
- OS Version: Windows 

Steps to Reproduce:

1. Have a corporate proxy
2. Installing extensions from the UI works
3. Installing extensions using the CLI and `--install-extension publisher.name` fails with "self signed certificate in certificate chain"

Note:

When using the CLI, this engine is used- https://github.com/microsoft/vscode/blob/main/src/vs/platform/request/node/requestService.ts which uses `https.request` from node.

In my case, `getProxyAgent` is returning null. My proxy settings are through Windows and not through environment variables.

When using the UI, this engine is used- https://github.com/microsoft/vscode/blob/main/src/vs/platform/request/common/requestIpc.ts#L49 which uses `net.request` from Electron

This workaround worked for me- https://github.com/microsoft/vscode/issues/144625#issuecomment-1183761594

My `NODE_EXTRA_CA_CERTS` is set correctly.
Repository: flutter
Issue: [Impeller] GLES: Support 16 bit uniform access
Labels: engine,P3,e: impeller,team-engine,triaged-engine

Discussed in https://github.com/flutter/engine/pull/42818#discussion_r1229806263.

Vulkan version of this issue: https://github.com/flutter/flutter/issues/128836

Even if we can't use 16 bit uniforms on GLES 2 devices, we still just enumerate and pull each uniform out of the buffer on the CPU, and so we can emulate it.
Repository: flutter
Issue: [Impeller] Improve scaling of very large images
Labels: engine,a: images,P1,e: impeller,team-engine,triaged-engine,slimpeller

Steps:

- Find a very high resolution image that exceeds the max limits of a texture size, for example https://github.com/zesage/panorama/blob/master/example/assets/panorama.jpg
- Try to load that image (with or without actually rendering it) on an Impeller enabled app.

> [VERBOSE-2:validation.cc(49)] Break on 'ImpellerValidationBreak' to inspect point of failure: Requested texture size (20266, 10134) exceeds maximum supported size of (16384, 16384)
> [VERBOSE-2:validation.cc(49)] Break on 'ImpellerValidationBreak' to inspect point of failure: Could not create multisample color texture.

One option would be to _always_ downscale to at least the max texture size, even if the user did not request downscaling of the image.

It may be worth creating some kind of package that automatically breaks up super large images into tiles for users who really want/need to render very high resolution images at scale.
Repository: flutter
Issue: Check target existence before filing flaky bugs
Labels: team-infra,P3,triaged-infra

Context: https://github.com/flutter/flutter/issues/128399

Three flaky builds were before 05/17:
 https://ci.chromium.org/ui/p/flutter/builders/prod/Windows%20build_tests_2_3/10905/overview
https://ci.chromium.org/ui/p/flutter/builders/prod/Windows%20build_tests_2_3/10904/overview
https://ci.chromium.org/ui/p/flutter/builders/prod/Windows%20build_tests_2_3/10867/overview

A [re-sharding](https://github.com/flutter/flutter/pull/127057) happened on that day from 3 to 4. The flake bot still filed the above flaky bug based on a deprecated shard (2_3) though it has been replaced.

The flake bot should check the existence of the flaky target before filing a flaky bug.
Repository: deno
Issue: Give SharedArrayBuffer a dedicated type
Labels: web,types

See https://github.com/whatwg/webidl/pull/1311.
Repository: rust
Issue: AFIT: strange errors on circular impls
Labels: C-bug,D-confusing,D-incorrect,D-terse,F-async_fn_in_trait,fixed-by-next-solver

case 1 [playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=a1d215ecfe95b80639bc15d8f10a31df):

```rust
pub trait Foo {
    async fn foo(&mut self);
}

impl<T: Foo> Foo for T {
    async fn foo(&mut self) {}
}
```

case 2 [playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=426dd7593e0d6c6953cd4b4a149bb729):

```rust
pub trait Foo {
    async fn foo(&mut self);
}

pub trait Bar: Foo {
    async fn bar(&mut self);
}

impl<T: Bar> Foo for T {
    async fn foo(&mut self) {}
}
```

fails with a strange error. The equivalent without AFIT is accepted, ~~but the impls are considered to apply to no type because they're circular~~ turns out the version with 2 traits does result in usable impls, it's an odd way of doing extension traits: [playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=05dd3d8f103a20562404ee818004a047). So I do think these should compile.

```
error[[E0053]](https://doc.rust-lang.org/nightly/error_codes/E0053.html): method `foo` has an incompatible type for trait
 --> src/lib.rs:8:29
  |
8 |     async fn foo(&mut self) {}
  |                             ^ expected associated type, found future
  |
note: type in trait
 --> src/lib.rs:4:28
  |
4 |     async fn foo(&mut self);
  |                            ^
  = note: expected signature `fn(&mut T) -> impl Future<Output = ()>`
             found signature `fn(&mut T) -> impl Future<Output = ()>`
```

@rustbot label F-async_fn_in_trait