sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Tracking Issue for tcplistener_into_incoming
Labels: T-libs-api,C-tracking-issue


Feature gate: `#![feature(tcplistener_into_incoming)]`

This is a tracking issue for #88339

The `TcpListener::incoming` method is really useful, however for some use cases the borrow it introduces is needlessly restricting. Thus, an owned variant is added.

### Public API

```rust
// std::net

pub struct IntoIncoming;

impl Iterator<Item = io::Result<TcpStream>> for IntoIncoming;

impl TcpListener {
    pub fn into_incoming(self) -> IntoIncoming;
}
```

### Steps / History

- [x] Implementation: #88339
- [ ] Final comment period (FCP)
- [ ] Stabilization PR

### Unresolved Questions

- The `IntoIncoming` could provide methods that allow access to (or getting back) the `TcpListener`. I decided against it, but they could be added if there is a use case
- IMO the `into_incoming` method should return an opaque `impl IntoIterator` so that `IntoIncoming` is not public API, but that would be inconsistent with the rest of `std`.
Repository: pytorch
Issue: Consolidating NCCL version parsing functions
Labels: oncall: distributed,module: bootcamp,module: c10d

We currently have two different functions and implementations to pull and parse NCCL version.

1. `cuda/nccl.cpp` directly parse from `NCCL_MAJOR`, `NCCL_MINOR`, and `NCCL_PATCH` macro:

https://github.com/pytorch/pytorch/blob/ab7a47298039da3b60b4e33cbb70c5fc06e1a315/torch/csrc/cuda/nccl.cpp#L330-L342

2. `c10d/NCCLUtils.cpp` asks `ncclGetVersion` for the version. 
https://github.com/pytorch/pytorch/blob/a016150163a7a78091bd965050f311d8af870abf/torch/csrc/distributed/c10d/NCCLUtils.cpp#L9-L27

I feel the 2nd option might be better, as it directly getting that information from the runtime. So the proposal is that we consolidate these two functions into one.

## Pitch

Update `cuda/nccl.cpp` to use `ncclGetVersion`, and convert that into a `uint64`. If it failed, return `-1`. Then, `NCCLUtils.cpp` call use `cuda/nccl` to get the version info. Today, `ProcessGroupNCCL.cpp` already depends on `cuda/nccl.h`, so the new dependency should be fine. 

https://github.com/pytorch/pytorch/blob/a016150163a7a78091bd965050f311d8af870abf/torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp#L19



cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @agolynski @SciPioneer @H-Huang @mrzzd @cbalioglu @gcramer23
Repository: godot
Issue: Enum Export Variable breaks Resource in inspector after restart
Labels: bug,topic:editor

### Godot version

3.3.2.stable.mono

### System information

Windows 10

### Issue description

I am trying to create a "public" enum that is accessible in multiple scripts.
Therefore I created a script "Enums.gd"

This contains my Enum I want to use in different other scripts
```
enum StoryTriggerCondition {
	default,
	pickup_coin,
	kill_chilli,
	talk_to_B_urrito,
	talk_to_Patua_Pechos,
}
```

I e.g. use it in my "StoryBlock.gd" Script and preload it like this:

```
extends Resource
class_name StoryBlock

const ENUMS = preload("res://Scripts/Enums.gd")

export(Array, ENUMS.StoryTriggerCondition) var conditions
```

If I then create a instance of my Resource it works as I expect it to do:
![image](https://user-images.githubusercontent.com/41338825/131041075-aa271750-64c3-483e-8dd3-6d364f2a5247.png)
![image](https://user-images.githubusercontent.com/41338825/131041138-d61dce39-666c-4992-8a5c-77d2af9f807f.png)

However,**after** restarting the Editor it looks like this:
![image](https://user-images.githubusercontent.com/41338825/131041228-a71c0044-977d-40b8-9d66-0e907b779a03.png)

The fix is to force reload the depending "StoryBlock.gd" Script like this:
![k1MOAeFmun](https://user-images.githubusercontent.com/41338825/131041505-ff7dacf5-b925-4e1c-ac46-56e07149aa33.gif)



### Steps to reproduce

As described above. I have stripped down my project as far as I could before it stops working. I really can't tell what the issue is with it.
[IssueProject.zip](https://github.com/godotengine/godot/files/7063041/IssueProject.zip)


### Minimal reproduction project

I created a minimal "reproduction" project. However in that it is working without any issues. I can't tell where the issue is coming from.
[ResourceIssue.zip](https://github.com/godotengine/godot/files/7063000/ResourceIssue.zip)
Repository: material-ui
Issue: Custom components can no longer be styled the same way as Paper
Labels: new feature,component: Paper,v5.x migration

- [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.

## Summary 💡

In MUIv4 the styles that `<Paper>` used were relatively simple and custom components that didn't need the complex (square, outlined, animated multi-elevation) behaviours could easily match the same Material surface style simply by using a few variables from the MUI theme. e.g.

```js
const CustomSurface = styled('div')(({ theme }) => ({
  color: theme.palette.text.primary,
  backgroundColor: theme.palette.background.paper,
  boxShadow: theme.shadows[2],
  borderRadius: theme.shape.borderRadius,
}), []);
```

However with the introduction of Material's changes to dark mode surface styles (#18309), the way it was implemented means it's no longer possible for custom surfaces to use the standard surface background color without inheriting from `<Paper>` and moving elevation handling from styles in the custom surface to props passed from the owner component.

This is because the new dark mode background was implemented using a linear-gradient hardcoded in `<Paper>` that uses a complex `getOverlayAlpha` function which is hardcoded into `Paper.js`. As a result any custom component wanting to match `<Paper>`'s background must now copy the getOverlayAlpha and linear-gradient source code from Paper.js in order to use the correct background in their own component.

https://github.com/mui-org/material-ui/blob/7e7f40fff30ab0c2ec7a0003055a6508e11bcbb7/packages/material-ui/src/Paper/Paper.js#L61-L69

https://github.com/mui-org/material-ui/blob/7e7f40fff30ab0c2ec7a0003055a6508e11bcbb7/packages/material-ui/src/Paper/Paper.js#L13-L21

## Expectation

It should be possible to get a Material surface style background in a custom component using the Theme alone. Perhaps as a mixin. e.g. `{ ...theme.mixin.paperBackground(elevation) }`.

## Motivation 🔦

There are a lot of reasons for custom components to not want to inherit from `Paper`. The elevation of custom components is typically fixed and part of the component's intrinsic styles (e.g. how Button hardcodes its elevations) even if it is a paper-like surface that has the same background color behaviour. `styled` does not allow overriding props with a huge mess. It's even more complex if `elevation` is actually based on something dynamic like `:hover`. And the TypeScript types also end up more complex than they need to be for a component not using all of Paper's features.

I actually had to implement a modification to Accordion where it behaves like the Material demo where 2 surfaces join together into 1 surface. This was only possible using a `:before` which needed to use the same background as the `<Paper>` that Accordion is based on. This worked seamlessly in MUIv4. But after the MUIv5 update I had to copy `getOverlayAlpha` and hardcode it and the linear-gradient code into my app just to make it work in dark mode again.
Repository: TypeScript
Issue: typechecking of return types broken with `try/catch` when `strictNullChecks` and `noImplicitAny` are enabled
Labels: Suggestion,In Discussion

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms
try/catch, exception handling, strict mode

### 🕗 Version & Regression Information

Broken in 4.3.5, still broken in nightly

### ⏯ Playground Link
[Playground link with  strict mode](https://www.typescriptlang.org/play?#code/CYUwxgNghgTiAEAzArgOzAFwJYHtXwCNYAKASngC54pUBPAbgChGoBnW9JNTXfRHHGSoAFGDgC2WViAA8rDDCyoA5gD54Ab0bwd8CCAzwAblAjwAvPFTIIEJrvgLam7Q90mzlojDL3dAX3gwKAwwAAt4YhByDX9XHTgMZBh8DyZ-IA)

Disable `--noImplicitAny` and `--strict` (but leave `--strictNullChecks`) and typechecker will correctly note that `val` may have type null

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
declare function bar(): any;

async function foo(): Promise<string> {
    let val = null;
    try {
        val = bar();
    } catch (e) {}
    return val;
}
```

### 🙁 Actual behavior

Compile with `--strict` and observe no errors
Compile simply with `--strictNullChecks` and typechecker will correctly note that `val` may have type null and does not conform to the return type
### 🙂 Expected behavior

typechecker should correctly determine that `val` can have type null and does not conform to the return type
Repository: godot
Issue: Incoherent behavior of `Array.min()` and `Array.max()` with `NAN`s
Labels: topic:core,confirmed,documentation

### Godot version

3.3.3

### System information

Debian 11

### Issue description

_Disclaimer: It's not 100% clear to me if this is a bug or the intended behavior._

I was doing some experiments and I noticed the following strange behavior in GDScript:
```
var a = [3.0, NAN, NAN].min() # a = 3.0
var b = [NAN, 3.0, NAN].min() # b = NAN
var c = [NAN, NAN, 3.0].min() # c = NAN

var d = [3.0, NAN, NAN].max() # d = 3.0
var e = [NAN, 3.0, NAN].max() # e = NAN
var f = [NAN, NAN, 3.0].max() # f = NAN
```

In my opinion, the functions Array.min() and Array.max() should return a consistent result independent of the order of it's items.

### Steps to reproduce

Use the code provided in the description.

### Minimal reproduction project

_No response_
Repository: pytorch
Issue: Execute C++ based GTest unit tests from a python wrapper
Labels: good first issue,module: ci,triaged,enhancement

## Motivation

Currently lots of C++ based unit tests are executed directly from test.sh/win-test.sh for example:
https://github.com/pytorch/pytorch/blob/0bd8d0951dcb4063c0f7552a7404bd7f0e7b6e6f/.jenkins/pytorch/test.sh#L317

Which have following drawbacks:
 - It excluded those test runtime from auto-sharding/auto-categorization
 -  Make them subject of running on only particular platform (as `win-test.sh` and `test.sh` are two different files)
 - Make them abort abort test execution on the first failure despite existing policy
 - Make them susceptible of not reporting test execution results in standard XML format (if someone forgets to add `--gtest_output`) argument
 
## Pitch
Add a .json file with all C++ GTest based tests or just add them directly to run_test.py akin to https://github.com/pytorch/pytorch/blob/0bd8d0951dcb4063c0f7552a7404bd7f0e7b6e6f/test/run_test.py#L53

This would allow our auto-sharding system to balance them correctly across the shards, continue execution over failed tests as well as using re-using some of standard decorators for excluding test runs on certain configurations



cc @ezyang @seemethere @malfet @walterddr @lg20987 @pytorch/pytorch-dev-infra
Repository: flutter
Issue: Accept network accessible prebuilt binaries "flutter run --use-application-binary user@host:path/to/app"
Labels: tool,c: proposal,P3,team-tool,triaged-tool

Support application binaries built on another machine (CI, more powerful workstation, shared machine) to be passed directly into `flutter run --use-application-binary user@host:path/to/app`.  The tool could `rsync` (or `scp` or whatever mechanism is appropriate) to the machine with the tethered device.


Example: The built apk is on `machineA` at `path/to/apk`. On `machineB` run  `flutter run --use-application-binary me@machineA:path/to/apk`
Repository: electron
Issue: The webrequest.onCompleted method can listen for the body of the response
Labels: enhancement :sparkles:

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/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

webrequest.onCompleted so far, the most important thing in the callback parameter body has not been returned. If the response body is not returned, this method will lose its meaning. Therefore, we hope to add all the response things to the callback



### Proposed Solution

webrequest.onCompleted so far, the most important thing in the callback parameter body has not been returned. If the response body is not returned, this method will lose its meaning. Therefore, we hope to add all the response things to the callback



### Alternatives Considered

no


### Additional Information

_No response_
Repository: flutter
Issue: Text selection leads to scrolling in opposite direction
Labels: a: text input,framework,f: material design,f: scrolling,has reproducible steps,P2,found in release: 2.2,found in release: 2.6,f: selection,team-design,triaged-design

## Steps to Reproduce

### Minimal example
``` 
class TestTextSelectionScroll extends StatefulWidget {
  @override
  _TestTextSelectionScrollState createState() =>
      _TestTextSelectionScrollState();
}

class _TestTextSelectionScrollState extends State<TestTextSelectionScroll> {
  final TextEditingController _body = TextEditingController();

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Container(
        child: ListView(
          children: [
            TextField(
              controller: _body,
              style: Theme.of(context).textTheme.bodyText1,
              maxLines: null,
            ),
          ],
        ),
      ),
    );
  }
}
```

![issue01](https://user-images.githubusercontent.com/78305631/131076913-8dd1913e-b3cf-4dde-a659-ff4fb7e43abd.gif)

Any Textfield, Textformfield in listview has unwanted scrolling in the opposite direction of scroll when selecting long lines of text within the field. 

Expected results: Scroll only when cursor moves out of the viewport(not sure if thats the term)

Actual results: Unusual Scrolling in the opposite direction

<details>
[√] Flutter (Channel stable, 2.2.3, on Microsoft Windows [Version 10.0.19043.1165], locale en-IN)
    • Flutter version 2.2.3 at C:\Android\flutter
    • Framework revision f4abaa0735 (8 weeks ago), 2021-07-01 12:46:11 -0700
    • Engine revision 241c87ad80
    • Dart version 2.13.4

[√] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at C:\Android\sdk
    • Platform android-30, build-tools 30.0.3
    • ANDROID_HOME = C:\Android
    • ANDROID_SDK_ROOT = C:\Android\sdk
    • Java binary at: C:\Android\openjdk\bin\java
    • Java version OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_202-b08)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

[√] Visual Studio - develop for Windows (Visual Studio Build Tools 2019 16.8.4)
    • Visual Studio at C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools
    • Visual Studio Build Tools 2019 version 16.8.30907.101
    • Windows 10 SDK version 10.0.19041.0

[!] Android Studio (not installed)
    • Android Studio not found; download from https://developer.android.com/studio/index.html
      (or visit https://flutter.dev/docs/get-started/install/windows#android-setup for detailed instructions).

[√] VS Code (version 1.59.1)
    • VS Code at ########
    • Flutter extension version 3.25.0

[√] Connected device (3 available)
    • Windows (desktop) • windows • windows-x64    • Microsoft Windows [Version 10.0.19043.1165]
    • Chrome (web)      • chrome  • web-javascript • Google Chrome 92.0.4515.159
    • Edge (web)        • edge    • web-javascript • Microsoft Edge 92.0.902.78

</details>
Repository: storybook
Issue: [addon/viewport] defaultViewport is not applied
Labels: bug,addon: viewport,needs triage

**Describe the bug**
Same as #1548 - `defaultViewport` is not applied

**To Reproduce**
- Create two stories
- configure `defaultViewport` for one story
- Sometimes (rarely) `defaultViewport` will be applied, but usually not.

**System**
```
    @storybook/addon-essentials: ^6.3.1 => 6.3.1 
    @storybook/addons: ^6.1.21 => 6.3.2 
    @storybook/react: ^6.3.1 => 6.3.1
```

**Additional context**
It's literally "not applied", something with `useAddonState`
https://github.com/storybookjs/storybook/blob/next/addons/viewport/src/Tool.tsx#L152-L160
```js
   useEffect(() => {
      setState({  
        selected:  //                         <-- called here
          defaultViewport || (viewports[state.selected] ? state.selected : responsiveViewport.id),
        isRotated: state.isRotated,
      });
    }, [defaultViewport]);

    const { selected, isRotated } = state; // <--- not updated here
```
Repository: rust
Issue: Wrong (?) [E0631] signature mismatch for function with Fn trait arguments with GAT arguments
Labels: GATs-triaged,S-bug-has-test,A-GATs

Compiling this code

```rust
#![feature(generic_associated_types)]

trait Iterable {
    type Iterator<'a>;
    fn iter(&self) -> Self::Iterator<'_>;
}

struct SomeImplementation();

impl Iterable for SomeImplementation {
    type Iterator<'a> = std::iter::Empty<usize>;
    fn iter(&self) -> Self::Iterator<'_> {
        std::iter::empty()
    }
}

fn do_something<I: Iterable>(i: I, mut f: impl for<'a> Fn(&mut I::Iterator<'a>)) {
    f(&mut i.iter());
}

fn main() {
    do_something(SomeImplementation(), |_| ());
    do_something(SomeImplementation(), test);
}

fn test<'a, I: Iterable>(_: &mut I::Iterator<'a>) {}
```

with the current nightly (`rustc 1.56.0-nightly (0afc20860 2021-08-25)`) yields an E0631 argument mismatch for both calls to `do_something`. 
```
error[E0631]: type mismatch in closure arguments
  --> src/main.rs:22:5
   |
22 |     do_something(SomeImplementation(), |_| ());
   |     ^^^^^^^^^^^^                       ------ found signature of `for<'r> fn(&'r mut std::iter::Empty<usize>) -> _`
   |     |
   |     expected signature of `for<'r, 'a> fn(&'r mut <SomeImplementation as Iterable>::Iterator<'a>) -> _`
   |
note: required by a bound in `do_something`
  --> src/main.rs:17:48
   |
17 | fn do_something<I: Iterable>(i: I, mut f: impl for<'a> Fn(&mut I::Iterator<'a>)) {
   |                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `do_something`

error[E0631]: type mismatch in function arguments
  --> src/main.rs:23:40
   |
23 |     do_something(SomeImplementation(), test);
   |                                        ^^^^ expected signature of `for<'a> fn(&mut <SomeImplementation as Iterable>::Iterator<'a>) -> _`
...
26 | fn test<'a, I: Iterable>(_: &mut I::Iterator<'a>) {}
   | ------------------------------------------------- found signature of `for<'r> fn(&'r mut std::iter::Empty<usize>) -> _`
   |
note: required by a bound in `do_something`
  --> src/main.rs:17:56
   |
17 | fn do_something<I: Iterable>(i: I, mut f: impl for<'a> Fn(&mut I::Iterator<'a>)) {
   |                                                        ^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `do_something`
```

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=bda4ab05c4a579ec83ab7a0d899f34c1

I expected both calls to compile and from looking at the errors I also see no reasons why the signatures should be incompatible.  In the case that my expectation is wrong I would expect the compiler to give me some hint, why this is not possible.

Sorry for the double post, I accidentally used the wrong template in #88355
Repository: create-react-app
Issue: High CPU usage of watch with TypeScript is still an issue
Labels: stale,needs triage,issue: bug report

Astonishingly, 2 years later #6792 is still a thing and I wasted quite a bit of time to find it's a known issue despite all related tickets being closed (the above one due to inactivity!) with known workarounds being mentioned everywhere.

Upstream might have fixed it as per https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/issues/236#issuecomment-633122355 but seems like CRA 4.0.3 depends on a version that is too old?

Either update upstream, override this setting to a reasonable default or print a warning pointing to https://blog.johnnyreilly.com/2019/05/23/typescript-and-high-cpu-usage-watch/.
Repository: youtube-dl
Issue: VLIVE CH+ extract not working 
Labels: question

<!--

######################################################################
  WARNING!
  IGNORING THE FOLLOWING TEMPLATE WILL RESULT IN ISSUE CLOSED AS INCOMPLETE
######################################################################

-->


## Checklist

<!--
Carefully read and work through this check list in order to prevent the most common mistakes and misuse of youtube-dl:
- Look through the README (http://yt-dl.org/readme) and FAQ (http://yt-dl.org/faq) for similar questions
- Search the bugtracker for similar questions: http://yt-dl.org/search-issues
- Finally, put x into all relevant boxes (like this [x])
-->

- [ x ] I'm asking a question
- [ x ] I've looked through the README and FAQ for similar questions
- [ x ] I've searched the bugtracker for similar questions including closed ones


## Question

<!--
Ask your question in an arbitrary form. Please make sure it's worded well enough to be understood, see https://github.com/ytdl-org/youtube-dl#is-the-description-of-the-issue-itself-sufficient.
-->

WRITE QUESTION HERE

Vlive page is updating its security every now and then, and I cannot download the CH+ (subscription paid video) videos. I have tried many different method, downloading each m4s files and merging them but merged vid is cracking. 

following attached file is the line i have used following other's line for using vlive.py for paid vlive vid
vid link I would like to extract is this:
https://www.vlive.tv/post/1-18241380
Repository: PowerToys
Issue: Shortcut overlay disregard `DisabledHotkeys` registry setting.
Labels: Idea-Enhancement,Product-Shortcut Guide

### Microsoft PowerToys version

0.43.0

### Running as admin

- [ ] Yes

### Area(s) with issue?

Shortcut Guide

### Steps to reproduce

There is setting in registry to disable some hotkeys: value `DisabledHotkeys` in key `HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced`.
https://superuser.com/q/683274
https://www.geoffchappell.com/notes/windows/shell/explorer/globalhotkeys.htm

1. Set registry value to some key used by Explorer (e.g. "S")
2. Press shortcut to open overlay

### ✔️ Expected Behavior

Disabled keys are disabled (grayed) like arrows when there is no active window.

### ❌ Actual Behavior

Keys are looks active.

### Other Software

_No response_
Repository: terminal
Issue: Bastion shell similar to azure cloud shell
Labels: Issue-Feature,Area-Extensibility,Product-Terminal,Area-AzureShell

It would be great if windows terminal supported connecting via SSH over Azure bastion to some endpoint behind it.
So that I can work directly in windows terminal with full terminal comfort without the need to open the web based terminal emulation in azure portal.

Something similar to how the cloud shell works but with the tunneling to the final ssh endpoint in the private network.