sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: material-ui
Issue: [Menu] MenuItem improperly inherits from Reacts Button type when it shouldn't especially when used in Select
Labels: bug 🐛,component: menu,typescript,package: material-ui

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Steps to reproduce 🕹

Steps:

1. Attempt to use an object array in Select component with MenuItem value being a single object.


### Current behavior 😯

This error on MenuItem when trying to assign an Object to the value
```
Overload 3 of 3, '(props: DefaultComponentProps<ExtendButtonBaseTypeMap<MenuItemTypeMap<{}, "li">>>): Element', gave the following error.
    Type 'AT' is not assignable to type 'string | number | string[]'.
```

### Expected behavior 🤔

Not give me a typescript error about the value not conforming to React's button value typing when the component is not a value.


### Context 🔦

I am attempting to use an array of objects for my select list. I am attempting to set the value to an object.

Setting the value to `as any` gets rid of the problem which to me means there is a bug with the way the component is typed. 

In my example codeSandbox you will see a button being used with a proper error of an object being used for the value which it is true you cannot do this. https://github.com/facebook/react/issues/25311

While on the MenuItem I can and it works so the types are wrong.

Here is a link to the codeSandbox. https://codesandbox.io/s/kind-pateu-pdfin6?file=/src/index.tsx

Add in `as any` on the value and the error goes away.

### Your environment 🌎

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.
```
</details>
Repository: flutter
Issue: [iOS] Migrate to embedder API
Labels: platform-ios,engine,P2,team-ios,triaged-ios

Migrate iOS embedder to use the [embedder API](https://github.com/flutter/engine/blob/main/shell/platform/embedder/embedder.h)

The current planned steps are: (Check marked items are in flutter/main)

- [x] Setup a runtime flag to enable and disable Embedder api during the migration.
- [x] https://github.com/flutter/flutter/issues/137801
- [ ] Initialize the FlutterEngineProcTable& embedderAPI property, with callbacks left as TODOs.
- [ ] Implementing features. This can be separated to smaller patches, enable tests along the way if possible
- [ ] Run all the tests with the embedder API, make sure there are no meaningless regressions.
- [ ] Remove legacy code and make embedder API stable.

In step 3 above, some features are non-trivial. They are listed are listed below: (Check marked items are in flutter/main)

- [ ] Initialize FlutterEngine with EmbedderAPI.
- [ ] Render content on FlutterView.
- [ ] Background  Platform Channel message
- [ ] Touch events.
- [ ] Keyboard Events.
- [ ] External View Embedder (PlatformView)
- [ ] SemanticsUpdate
- [ ] VsyncWaiter

Additional graphics-related work

- [ ] Impeller integration
- [ ] Swapchain integration
- [ ] Wide gamut
- [ ] Hook up graphics debugger

A draft PR that contains the full migration is maintained here: https://github.com/flutter/engine/pull/39988 as a reference while working on individual patches. 

Below is a list of completed features in the draft PR. (Check marked items are the ones completed in the https://github.com/flutter/engine/pull/39988)

- [x] Initialize FlutterEngine with EmbedderAPI.
- [x] Render content on FlutterView.
- [x] Background  Platform Channel message. (Workaround)
- [ ] Background  Platform Channel message. 
- [x] Touch events.
- [ ] Keyboard Events.
- [ ] External View Embedder (PlatformView) (In progress)
- [ ] SemanticsUpdate
- [ ] VsyncWaiter

~Currently, the embedder API doesn't support impeller. https://github.com/flutter/flutter/issues/112230 is required to enable iOS to use impeller by default after the migration.~
Repository: flutter
Issue: Flutter garbage collection does not allow out of order children to be collected
Labels: framework,c: performance,f: scrolling,perf: memory,P3,team-framework,triaged-framework

It currently expects children to be collected in sequential order.
While developing the dynamic_layouts package in flutter/packages, @DavBot02 and @snat-s created grid layout patterns that allowed children to deviate from sequential order.

This did not allow for proper efficient garbage collection of leading children as their layouts were used to create more and more complex layouts.

Because of this, the leading children are not currently collected there in order to maintain the layout.

We should consider:
- updating the dynamic_layouts package to cache the layout of preceding tiles, so some of them can be garbage collected. That way as user's scroll back up, the tiles can be replaced where they belong
- or, consider a new garbage collection option to pick children ad hoc.
Repository: rust
Issue: GAT with bound on another GAT fails despite fulfilling the bound
Labels: T-compiler,C-bug,T-types,A-GATs

<!--
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 HasGeneric<T>(T);

trait GatFoo {
    type Foo<T>: GatBar<Bar<()> = Self::Foo<()>>;
}

trait GatBar {
    type Bar<T>;
}

impl<U> GatBar for HasGeneric<U> {
    type Bar<T> = HasGeneric<T>;
}

impl<U> GatFoo for HasGeneric<U> {
    type Foo<T> = HasGeneric<T>;
}
```

I expected to see this happen: This compiles successfully, as the bound is true - `GatBar::Bar<()> == HasGeneric<()>`.

Instead, this happened: The compile fails with E0271, type mismatch during resolution

### 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.
-->

Tested on the playground with:

```
1.65.0-beta.1
(2022-09-19 2a65764f21cf10b7e03c)
```
and
```
1.66.0-nightly
(2022-09-21 9062b780b32d2eab060b)
```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Backtrace</summary>
<p>

```
Compiling playground v0.0.1 (/playground)
error[[E0271]](https://doc.rust-lang.org/beta/error-index.html#E0271): type mismatch resolving `<HasGeneric<T> as GatBar>::Bar<()> == HasGeneric<T>`
  --> src/lib.rs:17:19
   |
17 |     type Foo<T> = HasGeneric<T>;
   |              -    ^^^^^^^^^^^^^ type mismatch resolving `<HasGeneric<T> as GatBar>::Bar<()> == HasGeneric<T>`
   |              |
   |              this type parameter
   |
note: expected this to be `HasGeneric<T>`
  --> src/lib.rs:13:19
   |
13 |     type Bar<T> = HasGeneric<T>;
   |                   ^^^^^^^^^^^^^
   = note: expected struct `HasGeneric<T>`
              found struct `HasGeneric<()>`
note: required by a bound in `GatFoo::Foo`
  --> src/lib.rs:5:25
   |
5  |     type Foo<T>: GatBar<Bar<()> = Self::Foo<()>>;
   |                         ^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `GatFoo::Foo`

For more information about this error, try `rustc --explain E0271`.
error: could not compile `playground` due to previous error
```

</p>
</details>
Repository: node
Issue: Unhandled TLSSocket error - internal Node error
Labels: tls,net

### Version

18.9.0, 17.1.0

### Platform

Bodhi Linux (Ubuntu like) - VM guest on Windows 10 host

### Subsystem

_No response_

### What steps will reproduce the bug?

I am running my Node based peer-to-peer application in test automation mode that creates persistent sockets as TLS websockets.  One the first test automation run, initiated from the windows host machine, everything is fine.  The application instance on the VMs continues to run so that I can frequently run test automation instances without ever touching the VMs.  When I attempt to run test automation a second time only 1 of my 4 VM application instances fails.

This appears to be a node defect.  The error message mentions an unhandled error event but I have extensive error handling on just about everything in my application, most especially my socket management.  The stack trace also does not indicate any code from my application.

### How often does it reproduce? Is there a required condition?

100% reproducible.  I am running 4 virtual machines each with a nearly identical install.  This problem only occurs on one of those 4 VMs.

### What is the expected behavior?

Socket not crashing.

### What do you see instead?

```
node:events:491
      throw er; // Unhandled 'error' event

Error: read ECONNRESET
    at TLSWrap.onStreamRead (node:internal/stream_base_commons:217:20)
Emitted 'error' event on TLSSocket instance at:
    at emitErrorNT (node:internal/streams/destroy:151:8)
    at emitErrorCloseNT (node:internal/streams/destroy:116:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
  errno: -104,
  code: 'ECONNRESET',
  syscall: 'read'
}

Node.js v18.9.0
```

### Additional information

_No response_
Repository: TypeScript
Issue: define properties with getters and setters on namespaces
Labels: Suggestion,Awaiting More Feedback

# Suggestion

I'm hoping to revisit https://github.com/microsoft/TypeScript/issues/16478 but narrowed to *only namespaces*, not modules. I agree with the reasoning for not considering this features for ES modules, but I think the feature still makes a lot of sense for namespaces.

I work at Netflix (so we are [basically coworkers](https://about.netflix.com/en/news/netflix-partners-with-microsoft) :smile:) and my TS code runs on TVs and other devices in a custom JS environment. I want to use a namespace to describe platform-provided, globally scoped, custom objects. These objects can include properties with getters and setters (which are typed differently) and currently there's no syntax available to describe that.

I can think of a few ways to implement this:

* `export get x(): T;` as suggested in the linked proposal. Pro: it feels like a very natural syntax. Con: namespaces would support a feature that modules do not.
* Namespace declarations define an implicit interface, similar to classes, which can be added to in a subsequent interface declaration:

```ts
declare namespace MyNamespace {}

interface MyNamespace {
    get myValue(): number;
}
```

Pro: no new syntax. Con: potential name collision - currently you can have an interface with the same name as a namespace, and the interface will win. With this change the two would be merged.
* A utility type: `export const myValue: Accessor<GetType, SetType>`

This feature would be really valuable to me, so I wanted to see if this idea is objectionable to the core team or not - if it's acceptable but niche or wouldn't be a priority, I'm willing to get my hands dirty and submit a PR.

## ✅ 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).
Repository: godot
Issue: Sky strange effect when using shader with SSR enabled and z far is 250000+
Labels: bug,topic:rendering,topic:3d

### Godot version

4.0.dev(62792ee)

### System information

Windows 10, RTX 3060, Vulkan

### Issue description

Sky strange effect when using shader and z far is 250000+

When i create new shader in scene, all normal. But when i use that shader in SubViewport Sky, or reload shader in scene WorldEnvironment, bug shows again

![gdskyfail](https://user-images.githubusercontent.com/12541333/191870272-5ea964ee-cec0-409f-abe1-e5e2a595d16c.png)


### Steps to reproduce

set z-far 250000+
create warld environment with sky and shader
Save  shader (or sky) and reload it or use in another scene with z-far 250000+

### Minimal reproduction project

_No response_
Repository: pytorch
Issue: Implement `rand_like` ref and implement nvfuser_impl for `uniform` prim
Labels: triaged,module: nvfuser

### 🐛 Describe the bug

In the TorchDynamo+AOT_Autograd+Primtorch stack, Dropout is currently implemented as a decomposition when traced by AOT_Autograd.  The decomposition calls `rand_like` to provide the randomization.  Currently, `rand_like` is neither implemented as a Primtorch Ref and the only randomization implemented in the prims is `uniform` which nvFuser does not implement, yet.

As a work around, nvFuser will add an nvprim for `rand_like`.  #85077 

The real solution is to add a ref for `rand_like` that calls the prim `uniform`.  In order for this to work, nvFuser needs to also implement `uniform`.

nvFuser has an implementation of `uniform` that is waiting to be checked into upstream.  [nvFuser Dev Fork PR 1986](https://github.com/csarofeen/pytorch/pull/1986)

### Versions

TOT
Repository: flutter
Issue: Codesign and upload new ios-usb-dependencies binary
Labels: platform-ios,P2,team-release,triaged-release

Codesign the binaries in `flutter_infra_release/ios-usb-dependencies/unsigned/` from https://ci.chromium.org/p/flutter/builders/prod/ios-usb-dependencies/5 and upload to the `signed` bucket.  

https://docs.google.com/document/d/1ukmoITOt7rixsp8dw7Da95-3WFkKzPMnwzcvd-0UqqU (internal link) says:
```
./codesign.py --ios-deploy $IOS_DEPLOY_REVISION
```
I'm not sure if this still works after the recipe change https://flutter-review.googlesource.com/c/recipes/+/32660/

See also https://docs.google.com/document/d/1LZ4k65Xf5wcMD7ProYL6zXRcoBlCkWB67Mu_Uzs-gjU/ (internal link)

Blocking https://github.com/flutter/flutter/issues/111988

@XilaiZhang
Repository: godot
Issue: On Android DoubleClick is not consumed by Button and TextureButton. So its detected by _unhandled_input too.
Labels: platform:android,topic:input

### Godot version

3.5 Stable
(I have the pc version of Godot, Im not working on Android. I just export to Android)

### System information

Windows 7, Gles2, Nvidia 1060

### Issue description

I have made _unhandled_input to detect Double Clicks and Single clicks and it works fine on PC, there is a Texture Button that when you press it the input is consumed, so you have to press outside of the button for _unhandled_input to detect signal  . On Android the TextureButton or Button consumes only the single click. It doesnt consume the double click , so if you press the Texture Button fast enough the signal will pass to  _unhandled_input function too.

(I have the mouse filter to stop, on the Texture Button and I have  Emulate Touch and Emulate Mouse checked in Project Settings)

### Steps to reproduce

-A TextureButton to print something (with Mouse filter: to stop the signal).
-In unhandled_input you have to check for event.doubleclick  

-so when you press the TextureButton twice quickly it will print twice but it will also activate double click too

(export on Android, on PC it works fine, the issue is only on Android)

### Minimal reproduction project

So, on the project bellow if you export on Android and press the Texturebutton quickly twice it will detect doubleclick. While the Texturebutton has Filter:Stop and should consume the signal. 
[Doubleclick issue.zip](https://github.com/godotengine/godot/files/9631824/Doubleclick.issue.zip)
…]()
Tested on Godot_v3.5 and Godot_v3.4.4
Repository: TypeScript
Issue: Module names in declaration files mismatch with keys in dependencies
Labels: Bug,Help Wanted

# Bug Report

### 🔎 Search Terms

- declaration files
- module names
- dependencies
- moduleResolution
- nodenext

### 🕗 Version & Regression Information

- Typescript version: v4.8.3

### 💻 Code

File structure:

```txt
├── package1
│   ├── index.d.ts
│   └── package.json
└── package2
    ├── baz.ts
    ├── index.ts
    └── package.json
```

TS files:

```ts
// package1/index.d.ts
export interface FOO {}

// package2/baz.ts
export const BAZ = {
  foo: {} as Partial<import("pkg1").FOO>,
};

// package2/index.ts
import * as baz from "./baz";
export const BAZ = baz.BAZ;
```

Generated declaration files:

```ts
// package2/dist/baz.d.ts
export declare const BAZ: {
  foo: Partial<import("pkg1").FOO>;
};

// package2/dist/index.d.ts
export declare const BAZ: {
  // Why use the name specified in `package1/name`,
  // instead of the key in `package2/dependencies`?
  foo: Partial<import("package1").FOO>;
};
```

`package.json`:

```jsonc
// package1/package.json
{
  "name": "package1",
  "version": "1.0.0",
  "main": "index.js",
  "types": "index.d.ts",
  "exports": {
    ".": {
      "default": "./index.js",
      "types": "./index.d.ts"
    }
  }
}

// package2/package.json
{
  "name": "package2",
  "version": "1.0.0",
  "main": "index.js",
  "types": "index.d.ts",
  "devDependencies": {
    "typescript": "^4.8.3"
  },
  "dependencies": {
    "pkg1": "file:../package1"
  }
}
```

`tsconfig.json`

```jsonc
{
  "compilerOptions": {
    "declaration": true,
    "moduleResolution": "nodenext",
    "outDir": "dist"
  }
}
```

### 🙁 Actual behavior

```ts
// package2/dist/index.d.ts
export declare const BAZ: {
  foo: Partial<import("package1").FOO>;
};
```

### 🙂 Expected behavior

```ts
// package2/dist/index.d.ts
export declare const BAZ: {
  foo: Partial<import("pkg1").FOO>;
};
```
Repository: rust
Issue: Tracking Issue for Implementing Future for Arc and Rc
Labels: T-libs-api,C-tracking-issue

Feature gate: `#![feature(arc_rc_impl_future)]`

This is a tracking issue for implementing `Future` for `Arc` and `Rc`, much like the `Box` implementation (copied below for convenience), differing where it's only implemented if `Future` is implemented for an immutable reference to the contained type.

```rust
impl<F: ?Sized + Future + Unpin, A: Allocator> Future for Box<F, A>
where
    A: 'static,
{
    type Output = F::Output;

    fn poll(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
        F::poll(Pin::new(&mut *self), cx)
    }
}
```

### Public API

```rust
impl<'a, F: ?Sized + Unpin + 'a> Future for Arc<F>
where
    &'a F: Future
{
    type Output = F::Output;

    fn poll(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
        F::poll(Pin::new(&mut &*self), cx)
    }
}
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [ ] Implementation: #...
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilzation PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- None yet.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: vscode
Issue: Merge editor dialogs feedback
Labels: polish,merge-editor

Testing the new experience, some minor feedback on the dialogs I noticed.

This is a nice dialog: uses capital casing for buttons, has a short main message (in bold) and some details (in non bold):

<img width="289" alt="image" src="https://user-images.githubusercontent.com/900690/191903930-8f79a39b-68ee-4f32-87a9-53f761ca7d9c.png">

This dialog has quite a long main button, no capital casing and maybe could have a shorter main message and some details for more explanation?

<img width="313" alt="image" src="https://user-images.githubusercontent.com/900690/191904000-a5caf371-b09e-4f76-9034-d7a4fc83f4ef.png">

This dialog is 👍 

<img width="298" alt="image" src="https://user-images.githubusercontent.com/900690/191904154-9bca0558-9883-41cc-832b-1ae3bcddd4eb.png">
Repository: rust
Issue: Compile diagnostic for Option<T>::cloned() is bad when T is not &T
Labels: A-diagnostics,T-compiler

<!--
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.

If you cannot produce a minimal reproduction case (something that would work in
isolation), please provide the steps or even link to a repository that causes
the problematic output to occur.
-->

Given the following code: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=7d47c342ac883621074947e507c8ca86

```rust
fn take_opt(opt: Option<String>) {
    let _ = opt.cloned();
}
```

The current output is:

```
error[[E0599]](https://doc.rust-lang.org/stable/error-index.html#E0599): `Option<String>` is not an iterator
 --> src/lib.rs:2:17
  |
2 |     let _ = opt.cloned();
  |                 ^^^^^^ `Option<String>` is not an iterator
  |
  = note: the following trait bounds were not satisfied:
          `Option<String>: Iterator`
          which is required by `&mut Option<String>: Iterator`

For more information about this error, try `rustc --explain E0599`.
error: could not compile `playground` due to previous error
```

Changing to `Option<&String>` works, it would be nice if this recommended that.