sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: electron
Issue: [Documentation]: In the testing page, mention that the Webdriver (etc...) add parameters to electron
Labels: enhancement :sparkles:,documentation :notebook:,pr welcome

### 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

If you use "yargs" to parse arguments on the command line, it can be configured as "strict".

But in that mode, the additional command line parameters provoke the application to fail.

I propose to add that on the page https://www.electronjs.org/docs/latest/tutorial/using-selenium-and-webdriver#3-connect-to-chromedriver

### Proposed Solution

- Do you agree on that addition in the documentation?
- Where is this page stored, so that I can make a pull request for review? Didn't find it in the "doc" folder...


### Alternatives Considered

No idea...

### Additional Information

_No response_
Repository: material-ui
Issue: [link] Support extending theme color with `color` prop
Labels: new feature,component: link,package: material-ui

### Summary 💡

Currently `Link` component's `color` prop can receive `"primary" | "secondary" | "error"`, for other palette such as `warning`, a `.main` postfix is needed, so does custom palette.

The current behavior is shown in a [code sandbox](https://codesandbox.io/s/links-color-prop-b9cq3?file=/demo.js).

Expect the `.main` postfix is not needed.

### Examples 🌈

Working code currently:

```html
<Link href="#" color="warning.main">
  Warning
</Link>
<Link href="#" color="foo.main">
  Custom palette
</Link>
```

Expected behaviour:

```html
<Link href="#" color="warning">
  Warning
</Link>
<Link href="#" color="foo">
  Custom palette
</Link>
```
Repository: pytorch
Issue: functorch transforms are silently incorrect with autograd.Function
Labels: high priority,module: autograd,triaged,module: vmap,module: correctness (silent)

## 🐛 Bug

Cross linked from https://github.com/pytorch/functorch/issues/207

## To Reproduce

https://gist.github.com/zou3519/73a6189e21561f6ef5b42874e8a4826f

## Expected behavior

It should either work or raise an error.


cc @ezyang @gchanan @zou3519 @bdhirsh @jbschlosser @albanD @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
Repository: create-react-app
Issue: Facing vulnerabilities with bfj version 7.0.2 
Labels: stale,needs triage

I am facing vulnerabilities while working with bfj version 7.0.2, got check-types of two different version (11.1.1 and 11.1.2) in package-lock.json file, found vulnerabilities in check-types version 11.1.2,hoopy version 0.1.4 and tryer version 1.0.1.It is effecting my work kindly resolve this issue
Repository: pytorch
Issue: pytorch/ExampleRepo
Labels: module: ci,triaged

## 🚀 Feature

A `pytorch/ExampleRepo` template repository that has a working C++ extension build, CI setup, and binary build pipeline and is tested on a nightly or weekly basis.

## Motivation

Out-of-tree repos are becoming more popular among PyTorch developers (functorch, MaskedTensor, xFormers) and are important for developer velocity while prototyping new features. The main pain point for out-of-tree repos is release engineering: very few people have the knowledge to set up a binaries release if the repo contains C++ or CUDA code. The inability to build binaries means that engineers spend countless weeks on figuring out how to build binaries. We should have some ExampleRepo template that comes with a tested CircleCI configuration that builds binaries.

## Alternatives

Each repo needs a release engineer.

## Additional context

n/a


cc @seemethere @malfet @pytorch/pytorch-dev-infra
Repository: pytorch
Issue: In place `or` operator doesn't work in torchscript
Labels: oncall: jit

## 🐛 Bug

When using inplace `or` operator while indexing a tensor, the operator has no effect.

## To Reproduce

Steps to reproduce the behavior:

1. Run the following code
1. Observe the assert failing

```python
import torch


def inplace_or():
    x = torch.zeros(1, 1, dtype=torch.int16)
    x[0, :] += 1
    assert not (x == 0).all()   # this works as expected
    x = torch.zeros(1, 1, dtype=torch.int16)
    x[0, :] |= 1
    assert not (x == 0).all()  # this fails but only when run with torchscript.


def main():
    inplace_or()

    jitted = torch.jit.script(inplace_or)
    jitted()


if __name__ == '__main__':
    main()
```

## Expected behavior

I would have expected the inplace `|=` operator to change the value of `x`.

## Environment

PyTorch version: 1.10.0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 11.6 (x86_64)
GCC version: Could not collect
Clang version: 13.0.0 (clang-1300.0.29.3)
CMake version: version 3.21.3
Libc version: N/A

Python version: 3.8.12 (default, Oct 13 2021, 06:42:42)  [Clang 13.0.0 (clang-1300.0.29.3)] (64-bit runtime)
Python platform: macOS-11.6-x86_64-i386-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.21.4
[pip3] torch==1.10.0
[pip3] torchvision==0.11.1
[conda] blas                      1.0                         mkl
[conda] mkl                       2019.4                      233
[conda] mkl-service               2.3.0            py38h9ed2024_0
[conda] mkl_fft                   1.3.0            py38ha059aab_0
[conda] mkl_random                1.1.1            py38h959d312_0
[conda] mypy                      0.812                    pypi_0    pypi
[conda] mypy-extensions           0.4.3                    pypi_0    pypi
[conda] numpy                     1.20.2                   pypi_0    pypi
[conda] numpy-base                1.19.2           py38hcfb5961_0
[conda] pytorch                   1.9.1                   py3.8_0    pytorch
[conda] torch                     1.8.1                    pypi_0    pypi
[conda] torchaudio                0.8.1                    pypi_0    pypi
[conda] torchvision               0.9.1                    pypi_0    pypi
(env) ➜  @topkernel[r_diffq]/r_diffq git:(ts) ✗
Repository: pytorch
Issue: Incorrect return type annotation for _get_mobile_model_contained_types
Labels: oncall: jit

## Incorrect return type annotation for _get_mobile_model_contained_types

https://github.com/pytorch/pytorch/blob/master/torch/jit/mobile/__init__.py#L109

Specified int, but should probably be `set[str]`

```
def _get_mobile_model_contained_types(f_input) -> int:
    r"""
    Args:
        f_input: a file-like object (has to implement read, readline, tell, and seek),
            or a string containing a file name
    Returns:
        type_list: A set of string, like ("int", "Optional"). These are types used in bytecode.
    Example:
    .. testcode::
        from torch.jit.mobile import _get_mobile_model_contained_types
        # Get type list from a saved file path
        type_list = _get_mobile_model_contained_types("path/to/model.ptl")
    """
```
Repository: create-react-app
Issue: Windows 10 Powershell create-react-app EPERM error on yarn.lock
Labels: needs triage,issue: bug report



### Describe the bug


Using Windows Powershell running this command 'npx create-react-app xx' I get error An unexpected error occurred: "EPERM: operation not permitted, open 'C:\\Users\\brice\\source\\repos\\xx\\yarn.lock'".

Even if I elevate to Administration I get the error. I have full permissions on the source\repos folder.





### Environment

Environment Info:

  current version of create-react-app: 4.0.3
  running from C:\Users\brice\AppData\Local\npm-cache\_npx\c67e74de0542c87c\node_modules\create-react-app

  System:
    OS: Windows 10 10.0.19042
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
  Binaries:
    Node: 16.13.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.4 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 8.1.3 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 95.0.4638.69
    Edge: Spartan (44.19041.1266.0), Chromium (95.0.1020.44)
    Internet Explorer: 11.0.19041.1202
  npmPackages:
    react: Not Found
    react-dom: Not Found
    react-scripts: Not Found
  npmGlobalPackages:
    create-react-app: Not Found


(paste the output of the command here.)

### Steps to reproduce

<!--
  run npx create-react-app xx in Windows Powershell
-->

(Write your steps here:)

1. Tries to create the app
2. Throws an EPERM error
3. Deletes the resulting files except for the yarn-error.log file

### Expected behavior

Create a react app
Repository: TypeScript
Issue: Intersection with omit loses function argument type inference, even when type is known
Labels: Needs Investigation

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

<!--
  What search terms did you use when trying to find an existing bug report?
  List them here so people in the future can find this one more easily.
-->

omit intersection function argument inference

### 🕗 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 is the behavior in every version I tried.

### ⏯ 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.4#code/GYVwdgxgLglg9mABKMBGAPAFQHwAoCGATgOaoBcimANIkcQEwUDyAtjFFjQORfYCUiAN4BYAFBiAvmLEpo8JCnpY8dcpRp1GiVu06Ie2RADIhiOFAAWAU0IB+CvjABPRBIEjxoqZ5SpcYxEDTACMiClwwCjAQFmCbAQBeQyQAakRUVyoAoMFEUMIoxCTEMAAqUvpXMT4AbmlRRX9RIJCwxAiomLjCROTENIyJLOacvLakYrKKqtFaoA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
function fun1<T>(arg1: T, arg2: Omit<T, ''>) {

}

function fun2<T>(arg1: T, arg2: Omit<T, ''> & { other?: any }) {

}

fun1(
    { bar: (n: number) => n + 1 },
    { bar: n => n**2 }
);

fun2(
    { bar: (n: number) => n + 1 },
    // Error: n has implicit any type
    // hovering over bar shows the correct type including the argument type
    { bar: n => n**2 }
);
```

### 🙁 Actual behavior

The type of the argument of `bar` could not be inferred in `fun2`.

### 🙂 Expected behavior

The type of the argument of `bar` should be able to be inferred in the `fun2` call, just like it was in the `fun1` call.
Repository: material-ui
Issue: Nextjs / MUI integration example sandbox is broken
Labels: bug 🐛,external dependency

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Current behavior 😯

clicking on the sandbox example at https://codesandbox.io/s/github/mui-org/material-ui/tree/master/examples/nextjs leads to an app that fails to render

### Expected behavior 🤔

example should work

### Steps to reproduce 🕹

Steps:
go to the documentation sandbox https://codesandbox.io/s/github/mui-org/material-ui/tree/master/examples/nextjs
1.
2.
3.
4.


### Context 🔦

_No response_

### Your environment 🌎

<details>
  <summary>`npx @mui/envinfo`</summary>

```
  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.
```
</details>
Repository: rust
Issue: Confusing diagnostic for iterators lifetimes with `Drop` and `chain()`
Labels: A-diagnostics,T-compiler

Given the following code: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=26f878711564a5bff2c0da3be4de81af

There are two things that I consider to be error output bugs, but that can be probably be discussed:

## `IntoIterator` exists for `&Type` but not `Type`

The first one was that an earlier version of this code didn't use `into_iter()` at line 18, because I thought that it would compile properly without it. After all, the promise is that `for x in X` is the same as `for x in X.into_iter()`, right? But in that case, `&itertools::GroupBy` (note leading borrow) has `IntoIterator`, not `itertools::GroupBy` itself.

The compiler output for that error is the following:

```
error[E0277]: `itertools::GroupBy<i32, std::slice::Iter<'_, Val>, [closure@src/main.rs:18:46: 18:61]>` is not an iterator
   --> src/main.rs:18:26
    |
18  |     for (_key, chunk) in vec.iter().group_by(|val| val.x % 2){
    |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `itertools::GroupBy<i32, std::slice::Iter<'_, Val>, [closure@src/main.rs:18:46: 18:61]>` is not an iterator
    |
    = help: the trait `Iterator` is not implemented for `itertools::GroupBy<i32, std::slice::Iter<'_, Val>, [closure@src/main.rs:18:46: 18:61]>`
    = note: required because of the requirements on the impl of `IntoIterator` for `itertools::GroupBy<i32, std::slice::Iter<'_, Val>, [closure@src/main.rs:18:46: 18:61]>`
note: required by `into_iter`
```

It would be ideal if it could suggest to use `&vec.iter().group_by(...)` instead, and maybe give fewer details about the error message itself.

## Lifetime error is confusing

The current output is:

```
error[E0597]: `val_start` does not live long enough
  --> src/main.rs:21:36
   |
21 |         let iter = std::iter::once(&val_start)
   |                                    ^^^^^^^^^^ borrowed value does not live long enough
...
25 |     }
   |     -
   |     |
   |     `val_start` dropped here while still borrowed
   |     borrow might be used here, when `chunk` is dropped and runs the `Drop` code for type `Group`
   |
   = note: values in a scope are dropped in the opposite order they are defined
```

While I understand, after discussing this with others, that this is probably correct, the error message is quite confusing: I think that it _could_ mention that the lifetime of the borrow value is induced by the lifetime of the `iter` value, itself induced by the `chain()` calls which will take the overall longer lifetime.

Also, the relationship to `Drop` is really not obvious, in particular, and has me gotten quite confused (but it makes sense: it could be that the `itertools::Group` passed to `chain` actually stored something within its own struct fields using inner mutability, and thus that the `itertools::Group` would need to do something with it in its `Drop` implementation). I wonder if we could hint anything useful in that particular case, like `"chunk" could store a reference to "&val_start"` at line 22.

cc @estebank
Repository: pytorch
Issue: C++ at::Tensor's pinned_memory status is not printing out correctly.
Labels: high priority,module: cpp,triaged,module: correctness (silent)

## 🐛 Bug

We can create an at::Tensor with pinned memory for better GPU transfer performance etc. 
Despite we create an at::Tensor with pinned memory option, the tensor's options (_my_tensor.options()_) say that it is _not_ pinned. However, my_tensor.is_pinned() returns 1 which seems to imply that the pinning is actually performed. 

## To Reproduce

```
// Credit: jianyuhuang@fb.com
#include <ATen/ATen.h>
#include <iostream>

using namespace at;

int main() {
  int n = 100;
  Tensor r = at::empty({n}, at::TensorOptions().dtype(at::kInt).device(at::kCPU).pinned_memory(true));
  std::cout << r.options();

  return 0;
}
```

r.options() say pinned_memory = False, whereas r.is_pinned() returns 1.

## Environment
FB internal build (Oct 26)


cc @ezyang @gchanan @zou3519 @bdhirsh @jbschlosser
Repository: flutter
Issue: Increase in stack size per nesting level
Labels: framework,perf: memory,P2,team-framework,triaged-framework

The change here https://github.com/flutter/flutter/pull/93175

Caused an increase in stack frame size:

https://flutter-flutter-perf.skia.org/e/?begin=1634872419&end=1636480388&keys=Xe3f9934a59c344d1913580859559d4a9&requestType=0&xbaroffset=26447

/cc @HansMuller @goderbauer 

I believe @tvolkert added this benchmark to help debug `StackOverflow` exceptions, and may have advice about whether this increase in frame size is safe.
Repository: flutter
Issue: [Proposal]Allow customisation of ExpansionPanel icon size
Labels: c: new feature,framework,f: material design,c: proposal,team-design,triaged-design

<!-- Thank you for using Flutter!

     If you are looking for support, please check out our documentation
     or consider asking a question on Stack Overflow:
      * https://flutter.dev/
      * https://api.flutter.dev/
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     If you have found a bug or if our documentation doesn't have an answer
     to what you're looking for, then fill out the template below. Please read
     our guide to filing a bug first: https://flutter.dev/docs/resources/bug-reports
-->

## Use case

I need to include the size of icon just as design provided and expansion panel widget doesn't include the parameters yet. looking at the code it's possible to do but was not implemented yet

> how it should lo
<img width="1621" alt="example-use-case" src="https://user-images.githubusercontent.com/48217522/140982591-9a02c938-9deb-4359-aed2-94c257e5578b.png">
ok vs how it's looking


<!--
     Please tell us the problem you are running into that led to you wanting
     a new feature.

     Is your feature request related to a problem? Please give a clear and
     concise description of what the problem is.

     Describe the alternative solutions you've considered. Is there a package
     on pub.dev/flutter that already solves this?
-->

## Proposal

I'd suggest to include parameters to modify icon side params. if we allow it we can fix this issue for my use case
if it's possible I will create a pr to fix this 

![image](https://user-images.githubusercontent.com/48217522/140982920-3aa8d189-1f36-415d-a434-ca8a90a4118a.png)
![image](https://user-images.githubusercontent.com/48217522/140982928-f708981b-d4e8-42cc-b218-f379cb744499.png)


<!--
     Briefly but precisely describe what you would like Flutter to be able to do.

     Consider attaching something showing what you are imagining:
      * images
      * videos
      * code samples

     Does this have to be provided by Flutter directly, or can it be provided
     by a package on pub.dev/flutter? If so, maybe consider implementing and
     publishing such a package rather than filing a bug.
-->
Repository: TypeScript
Issue: Code blocks for `@typedef` do not preserve indentation in the generated `.d.ts` file.
Labels: Bug,Help Wanted,Effort: Moderate,Domain: Comment Emit

# Bug Report

### 🔎 Search Terms

`code` `block` `typedef` `indentation`

### 🕗 Version & Regression Information

Version 4.4.3, 4.4.4, 4.6.0-dev.20211109

- This is the behavior in every version I tried, and I reviewed the FAQ for entries about `@typedef`

### ⏯ Playground Link

[Playground link with relevant code](https://www.typescriptlang.org/play?target=99&jsx=0&filetype=js#code/PQKhCgAIUgBAXAngBwKYBNUDNIG8D2ARgFaoDG8AvpACoCiAyjVDHQB4CGAtsgDaoAuFi0gADccQDOI3CMiQA1qkQB9AIwDIANw68ArqnVzFylQCZNs6PJtLVZ9ZeM2T99Y8gByAFq+AXgGAZASezpCUxuHWkTDioizA4OCgENawAE6o8HppAHaSeDl6XISoadEJqGzI+GnwkGT4eXUA5pkqHHkA7qWQALyQABQAlH0AfJAALGbgQA)

### 💻 Code

```js
/**
 * @typedef {object} TEST
 * ```js
 * {
 *   key_1: value_1,
 *   key_2: {
 *     key_2_1: {
 *       key_2_1_1: 'ZZZzzz…'
 *     }
 *   }
 * }
 * ```
 */
```

### 🙁 Actual behavior

Code blocks for `@typedef` do not preserve indentation in the generated `.d.ts` file.

```ts
/**
 * ```js
 * {
 * key_1: value_1,
 * key_2: {
 *   key_2_1: {
 *     key_2_1_1: 'ZZZzzz…'
 *   }
 * }
 * }
 * ```
 */
type TEST = object;
```

### 🙂 Expected behavior

Code blocks for `@typedef` preserve indentation in the generated `.d.ts` file.

```ts
/**
 * ```js
 * {
 *   key_1: value_1,
 *   key_2: {
 *     key_2_1: {
 *       key_2_1_1: 'ZZZzzz…'
 *     }
 *   }
 * }
 * ```
 */
type TEST = object;
```
Repository: youtube-dl
Issue: Add site support for Confluent.io
Labels: site-support-request

## Checklist
- [+] I'm reporting a new site support request
- [+] I've verified that I'm running youtube-dl version **2021.06.06**
- [+] I've checked that all provided URLs are alive and playable in a browser
- [+] I've checked that none of provided URLs violate any copyrights
- [+] I've searched the bugtracker for similar site support requests including closed ones


## Example URLs
- Single video: https://videos.confluent.io/watch/dizWs7BRkxRo5heZvEQn9F

## Description
See the initial bug here: https://github.com/ytdl-org/youtube-dl/issues/30203
Repository: react
Issue: Timeline: Nested update warning logic flaw
Labels: Type: Bug,Component: Developer Tools,Component: Scheduling Profiler

Timeline shows the following nested update warning when a synchronous update causes an event handler to run long:
> A big nested update was scheduled during layout. Nested updates require React to re-render synchronously before the browser can paint. Consider delaying this update by moving it to a passive effect (useEffect).

This warning was intended to encourage developers to move _heavy_ updates from layout effects into passive effects so that they did not block paint or stretch event handlers.

Unfortunately this warning currently does not handle a few cases well:
1. Passive effects might be flushed synchronously (along with their updates) if a layout effect schedules a synchronous update.
2. ~~Click events now always flush passive effects synchronously~~ (see https://github.com/facebook/react/issues/20074#issuecomment-811296789).

This means that the current warning may be confusing or misleading. We should either update it to ensure that it never fires for updates that were _already_ scheduled inside of a passive effect, or if that is not possible we should remove it entirely.
Repository: flutter
Issue: Audit plugin test duplication
Labels: a: tests,team,package,team-ecosystem,P3,triaged-ecosystem

As we've federated plugins in flutter/plugins, we are often duplicating integration tests (taking the same tests we run in the front-end package, and running them all for each implementation package). We should audit our integration tests to ensure that they are only testing what is relevant for the layer they are running in; in many cases we should probably be eliminating most of the integration tests from the app-facing packages, since in many of the simpler plugins the app-facing package is a simple pass-through to the platform implementation.

The main driver here is CI times; unfortunately it's not clear yet how much this will help. It's likely that much of the time comes from having to build and launch the test harness, not from the individual tests.