sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: material-ui
Issue: Select field not showing menu items on iPhone browsers
Labels: component: select,browser: Safari

Material-UI Select and NativeSelect fields not showing menu items on iPhone browsers (tested on Safari and Chromium-based).

- [ x] The issue is present in the latest release.
- [ x] I have searched the [issues](https://github.com/mui-org/material-ui/issues) of this repository and believe that this is not a duplicate.

## Current Behavior 😯

I have created an app that has forms that use Material-UI Select fields. Everything works fine on all platform browsers except iPhone.  When I click on the Select field which has options (I know that from testing in on my computer's browsers), it just opens an empty menu with no items to choose from. Issue persists with both - Select and NativeSelect fields.

## Expected Behavior 🤔

The Select field should show me the options that are available on other platforms browsers.

## Steps to Reproduce 🕹

Code is the same as is in the documentation.

```tsx
        <Select
          id={name}
          label={label}
          native
          fullWidth
          disabled={disabled}
          required={isRequired}
          onChange={handleChange}
        >
          <option aria-label="None" value="" />
          {options.map(({ label, value }) => (
            <option key={value} value={value} label={label} />
          ))}
        </Select>
```

Steps:

1. Create a Select field with some option items
2. Open the app using an iPhone device
3. Click on the Select field
4. View the opened Select field's menu

## Context 🔦

I cannot use forms made with Material-UI in my app when it comes to users with iPhone devices. 

## Your Environment 🌎

<details>
  <summary>`npx @mui/envinfo`</summary>
  
```
System:
    OS: macOS 11.5
  Binaries:
    Node: 14.8.0 - /usr/local/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.7 - /usr/local/bin/npm
  Browsers:
    Chrome: 93.0.4577.82
    Edge: Not Found
    Firefox: 89.0.2
    Safari: 14.1.2
  npmPackages:
    @emotion/styled:  10.0.27 
    @types/react: ^17.0.0 => 17.0.7 
    react: ^17.0.2 => 17.0.2 
    react-dom: ^17.0.2 => 17.0.2 
    typescript: ^4.3.5 => 4.3.5 
```
</details>

Material-UI package version: `"@material-ui/core": "^4.12.3"`
Repository: TypeScript
Issue: Accessing property with bracket notation can sometimes incorrectly return an implicit `any` type
Labels: Bug

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms
implicit any, property access
### 🕗 Version & Regression Information

<!-- When did you start seeing this bug occur?

"Bugs" that have existed in TS for a long time are very likely to be FAQs; refer to
  https://github.com/Microsoft/TypeScript/wiki/FAQ#common-bugs-that-arent-bugs

If possible, please try testing the nightly version of TS to see if it's already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly

Note: The TypeScript Playground can be used to try older versions of TypeScript.

Please keep and fill in the line that best applies:
-->
- This changed between versions 4.2.3 and 4.3.5

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior

  The TypeScript Workbench can be used for more complex setups, try
  https://www.typescriptlang.org/dev/bug-workbench/

  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=4.4.2#code/MYewdgzgLgBCBGArGBeGBvAsAKAJAEEAuGARgBodcAhYknAXwG4ccB6VmASQHMwQAnAKYwoAC2EBLALYAHADaCpgsFACGUCeDIwJUAOQQYq+CACusMZLAAzQfyEATGEKin+YEQE8ZwkNZHiMNamYMAaWjAA7qISwKIwEKJmck7wwgBE+OkwAD4w6VTpOKCQsNyCUABKqmAOIFIA0oKeqDAAFACUqAB8MACy6qIAdPw1dVKdML0ADEMArDAA-PlZMMQFRdg4UN7CAGIgIK0wlRVuYAAquwA8Oz5+MOVVY-VNnr2CAB5Qyg6GANbNB53QQPBDIZanVzuK4+W67B5Paq1V7NXrEMCCABudmYW2wJWgzhejWarSRJLenTxhNgwFU0EEDmIByOaApKNJnmplGK4CJo05b1OEFMclgaHBAG1BeM3gBdGn8ukMn4OEViiVwJBS+mMhyKoA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
const obj = {
	A: 1,
	B: 1
};

// Ignore the implementation, it's about the inferred return type of the function, which should be "A" | "B"
const getRandomKey = () => Math.random() > 0.5 ? "A" : "B"

type Foo =  ReturnType<typeof getRandomKey> extends keyof typeof obj ? ReturnType<typeof getRandomKey> : never;

const randomKey = getRandomKey();
const casted: Foo = getRandomKey();
	
const randomKeyResult = obj[randomKey];
const castedResult = obj[casted];
```

### 🙁 Actual behavior

`randomKeyResult` has type 'number', but `castedResult` has type `any`

### 🙂 Expected behavior

Both `randomKeyResult` and `castedResult` should be type `number`. 

If you look at the type of `casted` and `randomKey`, the types are identical: `"A" | "B"`. Yet when using them to access a property, they behave differently. Note that in 4.2.3, this expected behavior was also the actual behavior.
Repository: flutter
Issue: [google_maps_flutter] Add stroke pattern with dash lines
Labels: c: new feature,p: maps,package,c: proposal,team-ecosystem,P3,triaged-ecosystem

I want to make a polygon with dash line but stokePattern are not available in method. can you please add stroke pattern property in polygon so that we can use it
Repository: godot
Issue: [Doc Gen] CTRL+CLICK doesnt go to script documentation
Labels: bug,topic:editor

### Godot version

v4.0.dev.20210916.official [104a6191f]

### System information

manjaro Gnome 21, AMD R7 200 series, Intel i3 3.0 GHZ,8GB RAM

### Issue description

When you click on a godot class with CTRL  holded, you go to its documentation, which is not true for the custom classes:

![doc](https://user-images.githubusercontent.com/58845030/134158376-9be5a0bf-7952-4ae7-a59c-c237471efc12.gif)



### Steps to reproduce

Shown above

### Minimal reproduction project

N/a
Repository: godot
Issue: Typed variables in GDScript fails with opcode 13 when using singleton class name as a type
Labels: discussion,topic:core,topic:gdscript,documentation

### Godot version

3.4 beta

### System information

Windows 10

### Issue description

![image](https://user-images.githubusercontent.com/17108460/134161644-d1823702-bf1f-4c6c-a519-bf7732f12316.png)


### Steps to reproduce

Can be reproduced with this small snippet:
```gdscript
extends Node2D

var geometry: Geometry
```

I don't know whether it's an issue in 4.x. If not, then feel free to close the issue.

This was revealed in goostengine/goost#130. My main use case is that global instances can be used globally, but sometimes they can also be used locally (to override parameters).

### Minimal reproduction project

_No response_
Repository: pytorch
Issue: torch.sparse.sum on scalar sparse tensor fails when dim is specified
Labels: module: sparse,triaged

## 🐛 Bug

As in the title.

## To Reproduce

```python
>>> import torch
>>> t = torch.tensor(1).to_sparse()
>>> torch.sparse.sum(t, dim=0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/pearu/git/pearu/pytorch/torch/sparse/__init__.py", line 152, in sum
    return torch._sparse_sum(input, dim)
RuntimeError: Trying to create tensor with negative dimension -1: [-1, 1]
```

## Expected behavior

torch.sparse.sum should not fail on scalar input (see additional context):
```python
>>> torch.sparse.sum(t, dim=0)
tensor(1)
```

## Environment

 - PyTorch Version (e.g., 1.0): 1.10.0a0

## Additional context

Recall torch.sum behavior on scalar-tensor input:
```python
>>> t = torch.tensor(1)
>>> torch.sum(t, dim=0)
tensor(1)
>>> torch.sum(t, dim=-1)
tensor(1)
>>> torch.sum(t, dim=())
tensor(1)
```
For torch.sparse.sum, that should mimic torch.sum behaviour on sparse inputs, we currently have
```python
>>> t = torch.tensor(1).to_sparse()
>>> torch.sparse.sum(t, dim=0)  # expecting tensor(1) but getting:
RuntimeError: Trying to create tensor with negative dimension -1: [-1, 1]
>>> torch.sparse.sum(t, dim=-1)  # expecting tensor(1) but getting:
RuntimeError: Trying to create tensor with negative dimension -1: [-1, 1]
>>> torch.sparse.sum(t, dim=())  # works as expected
tensor(1)
```

cc @nikitaved @pearu @cpuhrsch @IvanYashchuk
Repository: go
Issue: x/mod/module: MatchPrefixPattern doesn't match when glob ends with trailing slash
Labels: NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.16.5 darwin/arm64
</pre>

### Does this issue reproduce with the latest release?



### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
```
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/hauyang/Library/Caches/go-build"
GOENV="/Users/hauyang/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/hauyang/go/pkg/mod"
GONOPROXY="github.com/zeals-co-ltd/"
```
</pre></details>

### What did you do?
I want to get a private repo with `GOPRIVATE`, but I failed. The reason is the url ends with salsh `/`.

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->



### What did you expect to see?
Ends with slash should be fine for url


### What did you see instead?
failed to get the private repo
Repository: rust
Issue: `TypeId` documentation should mention gotcha re covariant subtypes
Labels: T-libs-api,A-docs

A covariant subtype gets a different type-ID, but can be converted freely from one to the other. This means that taking a type-ID of a generic type argument in a type's `new` method is not guaranteed to give the same type-ID that the type will eventually be called with. The solution is to force the generic type argument to be invariant using PhantomData. See [this bug in `qcell` crate](https://github.com/uazu/qcell/issues/20).

It would be helpful if this were documented to avoid similar bugs occurring in other crates.

```
use std::any::TypeId;
fn main() {
    println!(
        "{:?}, {:?}",
        TypeId::of::<fn(&'_ ())>(),
        TypeId::of::<fn(&'static ())>(),
    );
}
```
Repository: PowerToys
Issue: [Settings: ImageResizer] Edit size dialog: Add validation against empty name
Labels: Idea-Enhancement,Product-Settings,Product-Image Resizer,External Dependency-WinUI 3,Needs-Triage,Needs-Team-Response

There is one small thing we should add. (But I don't know how.)
The data in the name field of the edit dialog should be validated against `.NullOrEmpty`!
_Originally posted by @htcfreek in https://github.com/microsoft/PowerToys/pull/13285#issuecomment-924113251_

**Detailed description:**
While users edit an image size in the ImageResizer settings on PT's settings ux they are able to clear the name of the image size. This doesn't lead to errors/exceptions, but it also doesn't make sense to have sizes without a name. So we should prevent user from doing this in the edit dialog.

_**Note:**_
This is the second and last change that is needed to prevent the users from having incorrect image size settings (#8698). But I think this is not as relevant, because a missing name won't break image resizing._

---

cc: @niels9001
Repository: rust
Issue: Tracking Issue for RFC: Supertrait Item Shadowing
Labels: E-hard,T-lang,E-help-wanted,C-tracking-issue,S-tracking-impl-incomplete,T-types,F-supertrait_item_shadowing

This is a tracking issue for:

- https://github.com/rust-lang/rfcs/pull/2845
- https://github.com/rust-lang/rfcs/pull/3624

The feature gate for the issue is `#![feature(supertrait_item_shadowing)]`.

### About tracking issues

Tracking issues are used to record the overall progress of implementation.  They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.  A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.  Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

### Steps

- [x] Accept an RFC.
  - https://github.com/rust-lang/rfcs/pull/2845
  - https://github.com/rust-lang/rfcs/pull/3624
- [ ] Implement in nightly.
  - https://github.com/rust-lang/rust/pull/125782
- [ ] Add documentation to the [dev guide][].
  - See the [instructions][doc-guide].
- [ ] Add documentation to the [reference][].
  - See the [instructions][reference-instructions].
- [ ] Add formatting for new syntax to the [style guide][].
  - See the [nightly style procedure][].
- [ ] Stabilize.
  - See the [instructions][stabilization-instructions].

[dev guide]: https://github.com/rust-lang/rustc-dev-guide
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs
[edition guide]: https://github.com/rust-lang/edition-guide
[nightly style procedure]: https://github.com/rust-lang/style-team/blob/master/nightly-style-procedure.md
[reference]: https://github.com/rust-lang/reference
[reference-instructions]: https://github.com/rust-lang/reference/blob/master/CONTRIBUTING.md
[stabilization-instructions]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[style guide]: https://github.com/rust-lang/rust/tree/master/src/doc/style-guide

### Unresolved Questions

TODO.

### Related

- https://github.com/rust-lang/rfcs/pull/2845
- https://github.com/rust-lang/rfcs/pull/3624
- https://github.com/rust-lang/rust/pull/125782
Repository: terminal
Issue: Narrator reading order for About dialog appears incorrect
Labels: Help Wanted,Issue-Bug,Area-Accessibility,Product-Terminal,Priority-3,Tracking-External

This is the order:

![image](https://user-images.githubusercontent.com/18221333/134210932-753323e3-95cb-4b2f-8e65-4ce69a116f6f.png)

I think it should be reading the text at the top first before reading the "Documentation link" one below it.
Repository: rust
Issue: Confusing trait bound error with impl parameter
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=2018&code=fn%20bar()%20-%3E%20anyhow%3A%3AResult%3C()%3E%20%7B%0A%20%20%20%20if%20true%20%7B%0A%20%20%20%20%20%20%20%20Err(String%3A%3Anew().into())%0A%20%20%20%20%7D%20else%20%7B%0A%20%20%20%20%20%20%20%20baz(String%3A%3Anew())%0A%20%20%20%20%7D%0A%7D%0A%0Afn%20baz(e%3A%20impl%20Into%3Canyhow%3A%3AError%3E)%20-%3E%20anyhow%3A%3AResult%3C()%3E%20%7B%0A%20%20%20%20Err(e.into())%0A%7D%0A%0A):
```rust
fn bar() -> anyhow::Result<()> {
    if true {
        Err(String::new().into())
    } else {
        baz(String::new())
    }
}

fn baz(e: impl Into<anyhow::Error>) -> anyhow::Result<()> {
    Err(e.into())
}
```

The current output is:

```
error[E0277]: the trait bound `String: std::error::Error` is not satisfied
 --> src/lib.rs:3:27
  |
3 |         Err(String::new().into())
  |                           ^^^^ the trait `std::error::Error` is not implemented for `String`
  |
  = note: required because of the requirements on the impl of `From<String>` for `anyhow::Error`
  = note: required because of the requirements on the impl of `Into<anyhow::Error>` for `String`

error[E0277]: the trait bound `String: From<String>` is not satisfied
 --> src/lib.rs:5:13
  |
5 |         baz(String::new())
  |             ^^^^^^^^^^^^^
  |             |
  |             expected an implementor of trait `From<String>`
  |             help: consider borrowing here: `&String::new()`
...
9 | fn baz(e: impl Into<anyhow::Error>) -> anyhow::Result<()> {
  |                ------------------- required by this bound in `baz`
  |
  = note: required because of the requirements on the impl of `From<String>` for `anyhow::Error`
  = note: required because of the requirements on the impl of `Into<anyhow::Error>` for `String`
```

On the surface the two error cases look very similar. The first error message is correct and works as expected. The second one is very confusing: it claims that `String: From<String>` is not satisfied, while it's always provided by the blanket impl, and it is unclear why the compiler would search for `String: From<String>` at all, given that `anyhow` provides only two conversion impls:

```rust
impl<E> From<E> for Error where
    E: StdError + Send + Sync + 'static, { /* ... */ }

impl From<Error> for Box<dyn StdError + Send + Sync + 'static> { /* ... */ }
```

neither of which could possibly lead to `String: From<String>`.

The suggested fix `consider borrowing here: &String::new()` also doesn't make any sense.

The error reproduces on the current stable `rustc 1.55`, nightly `rustc 1.57.0-nightly (e4828d5b7 2021-09-16)` and beta compiler toolchains.
Repository: flutter
Issue: [video_player] Removing public member `fileContents` in `SubRipCaptionFile`.
Labels: p: video_player,package,team-ecosystem,P3,triaged-ecosystem

This public member: [fileContents](https://github.com/flutter/plugins/blob/master/packages/video_player/video_player/lib/src/sub_rip.dart#L19) doesn't seem to be useful. Since removing it will be a breaking change, we can cooperate this into another more meaningful breaking change in the package.
Repository: pytorch
Issue: Enable is_contiguous slowpath for torch_dispatch
Labels: triaged,module: __torch_dispatch__

## 🚀 Feature
contiguous and is_contiguous need to frequently be overwritten for Tensor subclasses. They currently cannot

```
class ExampleTensor(torch.Tensor):
  @staticmethod
  def __new__(cls, data):
    # Use a Tensor that of the give size for the wrapper.
    return torch.Tensor._make_subclass(cls, torch.empty(data.size(), device='meta'), data.requires_grad)

  def __init__(self, data):
    self.example_data = data

  @classmethod
  def __torch_dispatch__(cls, func, types, args, kwargs):
    print("Calling func: ", func)
    return NotImplemented
          
e = ExampleTensor(torch.randn(2, 3))
e.contiguous()
e.is_contiguous()
e.cos()
```

yields

```
Calling func:  <built-in method cos of PyCapsule object at 0x7f731a8c64b0>
[...]
TypeError: no implementation found for 'torch.ops.aten.cos' on types that implement __torch_dispatch__: [0x7f731a923cf0]
```

Running this on ```https://download.pytorch.org/whl/nightly/cpu/torch-1.10.0.dev20210918%2Bcpu-cp37-cp37m-linux_x86_64.whl```

## Motivation

New Tensor types need to overwrite contiguous and is_contiguous to support new or experimental memory layouts.

## Pitch

Enable the slow path for these functions for torch_dispatch

## Alternatives

Not sure

## Additional context

cc @albanD
Repository: rust
Issue: Use LLVM's externally_available linkage for inline functions
Labels: A-linkage,C-enhancement,A-codegen,WG-llvm

This tells LLVM that the function has a given definition to allow for inlining, but that the function is already externally defined, so locally emitting object code for it is not necessary. It is necessary to provide an export elsewhere though. This can be done by making the monomorphization collector handle them like normal functions when it isn't being inlined from another crate or cgu.

On one hand this will likely save executable size and for debug mode compilation time as codegen of inline functions can be skipped. On the other hand it will likely result in bigger libraries due to the extra inlined functions. It will also break the (incorrect) assumption that some crates have that `#[inline]` functions are never codegened if not used.

Codegen backends that don't support externally_available can treat it as local or if they don't support inlining at all don't codegen them at all.
Repository: pytorch
Issue: Add a `__torch_pre_dispatch__` that will live at the top of the dispatcher
Labels: feature,triaged,module: dispatch

From previous discussion, it is something we considered but don't want to implement unless we have an explicit need for it.

From doing prototyping with @cpuhrsch I think we do have a need for it, in particular to:
- re-use the python arg parser the same way torch_dispatch does
- be able to  override composite op that are called on the c++ side.
Repository: vscode
Issue: Git - Source Control Tab "Discard Changes" on a file called '*' discards all untracked changes
Labels: bug,git

<!-- ⚠️⚠️ 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.60.1
- OS Version: MacOS 11.3 / RHE Linux 7.6

Steps to Reproduce:

1. Open workspace in a git repo
2. Make lots of new untracked files. 
3. Create a file called '*'    😛
4. In the Source Control tab right click the file '*' and select Discard Changes
5. VSCode displays a dialog saying "This file will FOREVER BE LOST if you proceed."
6. Click "Delete File"
7. vscode runs "git clean -f -q -- '/path/to/dir/*"
8. You have lost all your untracked work, not just the file '*' as the dialog suggests.

Not really sure what the solution here is. Not sure exactly how you would modify the git command to be compatible with a filename of '*'. But certainly the operation vscode performed did not match the operation selected or the text of the dialog box warning.

You might think it absurd that someone would make this filename, or even expect vscode to handle it elegantly. However at 01:10 in the morning, I did this, and it was painful. 😭