sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: deno
Issue: Better implicit binding for IPv6/IPv4 on Windows
Labels: windows,suggestion

## Environment

```
deno 1.10.1 (release, x86_64-pc-windows-msvc)
v8 9.1.269.27
typescript 4.2.2
```

The problem is specific to the Windows version of Deno. It does _not_ happen for `x86_64-unknown-linux-gnu` under WSL2, but it _does_ happen for `x86_64-pc-windows-msvc` invoked under WSL2.

## Problem

On Windows, after starting a Deno HTTP server (either stdlib between `0.60.0` and `0.97.0` or `Deno.listen`), the first incoming connection is delayed by 300ms.

When doing rapid development in watch-and-restart mode, this can be a minor annoyance.

Repro scripts:

* [deno_srv_delay_stdlib.js](https://gist.github.com/mitranim/ea15f621505d38877190a0a057b5cd01)
* [deno_srv_delay_unstable.js](https://gist.github.com/mitranim/e35e95e0d609e3167effaca2232c4639)

Typical output from repro scripts (`x86_64-pc-windows-msvc`):

```
[srv] listening on http://localhost:57294
headers: 316ms
body: 1ms
headers: 1ms
body: 0ms
```

Typical output from repro scripts (`x86_64-unknown-linux-gnu`):

```
[srv] listening on http://localhost:57294
headers: 7ms
body: 1ms
headers: 0ms
body: 0ms
```
Repository: angular
Issue: Explore potential CLDR locale data byte savings by omitting trailing undefined values
Labels: area: build & ci,area: common,P3

_As noted by @petebacondarwin in https://github.com/angular/angular/pull/42230#discussion_r638126133. Mostly for tracking_

In the CLDR locale data we often output data as followed: `[a, b, undefined, undefined]`. This is basically the same as `[a, b]` - as long as we don't care about the length of the array.

We might be able to further improve this by trimming any trailing `undefined` values from the locale array.

It's unclear whether this could land in a minor/patch, or whether we should wait for a major. If experiments show that we can do this optimization, then we could figure out where to land it. I assume a major is more suitable in  case users rely on the locale data length (for unknown reasons?)
Repository: go
Issue: x/build: solaris-amd64-oraclerel failures with "no space left on device"
Labels: OS-Solaris,Builders,NeedsInvestigation

The `solaris-amd64-oraclerel` builder seems to be failing moderately frequently with `no space left on device` errors:

[2021-05-24T20:15:56-15d9d4a/solaris-amd64-oraclerel](https://build.golang.org/log/fbc79326715e6723c06d373cc094ae204122d837)
[2021-05-10T15:11:50-ecb7392/solaris-amd64-oraclerel](https://build.golang.org/log/68689b8f4d4bcc374625a4d0e9af0a0344cc60bc)
[2021-05-03T16:42:22-169155d/solaris-amd64-oraclerel](https://build.golang.org/log/127d944ee42af43a09c3159d9495013176bf4dc4)
[2021-04-28T19:13:50-ad989c7/solaris-amd64-oraclerel](https://build.golang.org/log/2669e12373b36dbebad436fd4d7f12aa0d21cab9)
[2021-04-26T21:27:41-9f60169/solaris-amd64-oraclerel](https://build.golang.org/log/b3d02ecedee0107dc39bae42756fbd6890bba309)
[2021-04-08T20:55:59-0243799/solaris-amd64-oraclerel](https://build.golang.org/log/6a34b0e8c433b47306050f64def1b0d04ac5768a)
[2021-04-08T02:08:45-b261fe9/solaris-amd64-oraclerel](https://build.golang.org/log/2b6609d0325e9d6c6652bf2a5b738bcffdb2160a)
[2021-03-30T21:06:17-4fbd30e/solaris-amd64-oraclerel](https://build.golang.org/log/87eeaf1e285cf449bffcd1095f6f004170e3292d)

It's not obvious to me whether the buildlet script is failing to clean something up, the device's disk is getting too full for other reasons, or perhaps the builder is just configured to run too many builds in parallel.

CC @golang/release @rorth
Repository: vscode
Issue: User forwarded port has the first request TTFB too high
Labels: feature-request,remote-explorer,remote-connection

- VS Code Version:
  ```
  Version: 1.56.2 (user setup)
  Commit: 054a9295330880ed74ceaedda236253b4f39a335
  Date: 2021-05-12T17:13:13.157Z
  Electron: 12.0.4
  Chrome: 89.0.4389.114
  Node.js: 14.16.0
  V8: 8.9.255.24-electron.0
  OS: Windows_NT x64 10.0.19042
  ```
- OS Version:
  ```
  Windows_NT x64 10.0.19042
  ```

**Steps to Reproduce:**

1. Forward the port of a container inside VSCode
2. Access it through browser

   ![image](https://user-images.githubusercontent.com/7198081/119506822-aa72ad00-bd44-11eb-9c53-0ef8e33a6801.png)
   ![image](https://user-images.githubusercontent.com/7198081/119506841-af376100-bd44-11eb-83b1-c32cbc9e02a4.png)

3. See that the first request has almost `400ms` of **TTFB** and the second one is less than `10ms`
Repository: storybook
Issue: Provide an option to resolve  manager-webpack5 module path in different folder than storybook config
Labels: feature request,has workaround,core,configuration

**Is your feature request related to a problem? Please describe**
Monorepo folders structure:
-Root
 - /FolderA/./storybook/main.js
 - /builder/storybook/config.js
 - /builder/storybook/node_modules/@storybook
All storybook module are located under `/builder/storybook/`, i want to have ability enabled webpack5 in `./main.js` of storybook and point manager and builder to  `/builder/storybook/node_modules/@storybook` for searching `builder-webpack5` and `manager-webpack5`. There is a way to provide full path for builder, but in this case manager will fallback to webpack4

**Describe the solution you'd like**
Add options in storybook config core to provide custom resolved path to `manager-webpack5` like:
```
core: {
        builder: path.resolve(__dirname, "../builder/storybook/node_modules/@storybook/builder-webpack5"),
        manager: path.resolve(__dirname, "../builder/storybook/node_modules/@storybook/manager-webpack5"),
    },
    
```
Repository: vscode
Issue: Terminal.creationOptions API shows default options in remotes
Labels: bug,api,terminal-process

From @chrmarti:

> For terminals created through the UI Terminal.creationOptions has the default options, that's different from 1.50 and also different from when the terminal is created through the API.
Repository: godot
Issue: Can't select another function for Array in Visual Script. Functions suggestion box is empty
Labels: bug,topic:editor,topic:visualscript

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
3.3

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
macOS

**Issue description:**
<!-- What happened, and what was expected. -->
Tried to change Array.front() to Array.back()
Saw emptiness in the suggestion window

It seems this one affects Array. Other types are not affected for some reason...
But I tried only Object, Node, Node2D.

**Steps to reproduce:**
1) Create node Array.front()
2) Try to change function in the node inspector
3) See empty suggestions, no way to change
![изображение](https://user-images.githubusercontent.com/4563032/119510911-96e23900-bd7a-11eb-84a9-077ccd7de610.png)


**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
Repository: rust
Issue: Compiler warning about dead code when enum is used in a match against return value of FFI call
Labels: A-lints,A-FFI,T-compiler,C-bug,L-dead_code

I tried this code:

```rust
#[repr(C)]
#[derive(Debug, PartialEq)]
enum ResultEnumFromC {
    Success = 0,
    FailureOfTypeOne = 1,
    FailureOfTypeTwo = 2,
}

pub enum ErrEnumInRust {
    FailureOfTypeOne = 0,
    FailureOfTypeTwo = 1,
}

extern "C" {
    fn FunctionFromC() -> ResultEnumFromC;
}

pub fn wrapper_around_function_from_c(
) -> Result<(), ErrEnumInRust> {
    match unsafe { FunctionFromC() } {
        ResultEnumFromC::Success => Ok(()),
        ResultEnumFromC::FailureOfTypeOne => Err(ErrEnumInRust::FailureOfTypeOne),
        ResultEnumFromC::FailureOfTypeTwo => Err(ErrEnumInRust::FailureOfTypeTwo),
    }
}
```
link to example in Rust playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=c3d9e0b917bfabeebeb6285a4aa73a6d

I expected to see this happen: no warning about dead code, since ResultEnumFromC is created on the C side and used in a match on the Rust side.

Instead, this happened: Compiler complained about ResultEnumFromC never being constructed (which is true on the Rust side, but I wouldn't expect this since it's the result of an FFI call).

```
warning: variant is never constructed: `Success`
 --> src/main.rs:4:5
  |
4 |     Success = 0,
  |     ^^^^^^^^^^^
  |
  = note: `#[warn(dead_code)]` on by default

warning: variant is never constructed: `FailureOfTypeOne`
 --> src/main.rs:5:5
  |
5 |     FailureOfTypeOne = 1,
  |     ^^^^^^^^^^^^^^^^^^^^

warning: variant is never constructed: `FailureOfTypeTwo`
 --> src/main.rs:6:5
  |
6 |     FailureOfTypeTwo = 2,
  |     ^^^^^^^^^^^^^^^^^^^^

warning: 3 warnings emitted
```

### Meta

Happens on Rust playground on stable, beta and nightly.

`rustc --version --verbose`:
```
1.52.1
```

<details><summary>Backtrace</summary>
<p>

```
warning: variant is never constructed: `Success`
 --> src/main.rs:4:5
  |
4 |     Success = 0,
  |     ^^^^^^^^^^^
  |
  = note: `#[warn(dead_code)]` on by default

warning: variant is never constructed: `FailureOfTypeOne`
 --> src/main.rs:5:5
  |
5 |     FailureOfTypeOne = 1,
  |     ^^^^^^^^^^^^^^^^^^^^

warning: variant is never constructed: `FailureOfTypeTwo`
 --> src/main.rs:6:5
  |
6 |     FailureOfTypeTwo = 2,
  |     ^^^^^^^^^^^^^^^^^^^^

warning: 3 warnings emitted
```

</p>
</details>
Repository: go
Issue: cmd/go: 'go mod graph' doesn't show module's replacement
Labels: Documentation,NeedsInvestigation

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.16.4 windows/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=...
set GOENV=...
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=...
set GONOPROXY=...
set GONOSUMDB=...
set GOOS=windows
set GOPATH=...
set GOPRIVATE=...
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=...
set GOVCS=
set GOVERSION=go1.16.4
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=...
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=...
</pre></details>

### What did you do?

Not completely sure whether this is an issue or what the expected behaviour is here. I've tried to describe the issue here
https://github.com/bvwells/module-graph

This is to clarify the behaviour of 'go mod graph' when the replace is used in a module. The example adds a replace in the module for a dependency. After doing 'go mod tidy' the only version seen in the sum file is the version defined in the replace statement.

Then run 'go mod graph' to output the module graph.

### What did you expect to see?

The documentation states:

```
The go mod graph command prints the module requirement graph (with replacements applied) in text form.
```
See https://golang.org/ref/mod#go-mod-graph

I was expecting to see the dependency gopkg.in/yaml.v3  replaced with the version gopkg.in/yaml.v3 v3.0.0-20210107192922-496545a6307b.

### What did you see instead?

The original dependency versions of gopkg.in/yaml.v3 were seen in the graph.

Apologies if I've misunderstood the documentation.
Repository: next.js
Issue: CSS modules duplicated when used with `next/dynamic`
Labels: Webpack,Lazy Loading

### What version of Next.js are you using?

10.2.2

### What version of Node.js are you using?

14.16.0

### What browser are you using?

Chrome

### What operating system are you using?

macOS

### How are you deploying your application?

Vercel

### Describe the Bug

When using `next/dynamic` with CSS modules, we've found that CSS can be re-inserted (duplicated)

In our scenario, we have a simple `<Text />` component that is already in use throughout the application. When we used `<Text />` in a new component that was dynamically imported, styles for `<Text />` were re-inserted.

These styles were inserted below all other styles, breaking some styles that rely on specificity - which is how we found this bug.

As a temporary workaround, we've removed that component from the dynamically loaded component.

### Expected Behavior

Styles should not be re-inserted/duplicated.

### To Reproduce

We haven't been able to reliably reproduce this in a standalone repo.

We've looked and found some potentially similar issues, and this _might_ be related: https://github.com/vercel/next.js/issues/20203.
Repository: godot
Issue: Mono version crashes on build (Ubuntu 21.04)
Labels: bug,topic:editor,confirmed,topic:dotnet,crash

Hey,
I already searched open and closed issues but couldn't find something related to my problem.
Mostly people had MSBuild missing or something.
I have dotnet-sdk-3.1  (as well as 5.0) and mono-devel installed.
Editor and project are setup to use visual studio code as external editor and MSBuild for building solution.

**Godot version:**
v3.3.2.stable.mono.official


**OS/device including version:**
OS: Ubuntu 21.04 x86_64 
Kernel: 5.11.0-17-generic 
CPU: AMD Ryzen 7 3700X (16) @ 3.600G
GPU: NVIDIA GeForce RTX 3080
Memory: 3035MiB / 32088MiB

**Issue description:**
Mostly after editing a C# file, the editor crashes when rebuilding the solution.
But this doesn't happen all the time. Sometimes (2/10) it won't crash.

Here is a --verbose output on pastebin:
https://pastebin.com/rkA4u31W

**Steps to reproduce:**
A: 
1. Open project
2. Click on MSBuild
3. Click >Build
4. Click Rebuild

or

B:
1. Open project
2. Edit .cs file
3. Click Play (>) or Build


**Minimal reproduction project:**
[MonoCrashRepro.zip](https://github.com/godotengine/godot/files/6540881/MonoCrashRepro.zip)
Repository: PowerToys
Issue: Task bar auto hide
Labels: Idea-New PowerToy

when processing 'slelcted' program, hido task bar.

or 

i want 'short cut' to hide task bar.

Thanks.
Repository: go
Issue: x/exp/cmd/gorelease: split release, diff functionality and prepare to merge into GOROOT
Labels: NeedsDecision,modules,Tools

@jadekler and I spent some time talking today about the future of gorelease. Here's what we're thinking.

* There seem to be two diverging use cases: 1) checking whether the module in the current directory is ready to be released as a new version, and 2) find what changed between two existing versions, either of the same module, different major versions, or different modules (forks, renames). The code that serves these use cases in nearly the same, but we should think about splitting the CLI.
* We eventually want to make gorelease part of the go command. Like `go doc`, it will run a separate binary (`cmd/doc` in that case). As part of this, I propose we name the command `go mod vet` to make it clear this is module-related, and it analyzes something like `go vet`. The name `go release` makes it sound like it's performing a release (uploading something), and the [GoReleaser](https://goreleaser.com/) project has a similar name.
* Comparing APIs of existing versions doesn't seem like it should be part of `go mod vet`, though it's an important use case. We should move this into a new command, say `golang.org/x/tools/cmd/gomoddiff`.

To move forward, let's do the following:

* Confirm via proposal process in #26420 or a new issue that this is the right approach forward.
* Fix release blocking bugs and add core features:
  - [x] #44133
  - [x] #40913
  - [x] #40267
  - [x] #37781
  - [ ] #37566
  - [ ] #37561
  - [ ] #37559
  - [x] #46372
  - See the [gorelease milestone](https://github.com/golang/go/milestone/178) for a complete list of issues; issues not included in the list above probably shouldn't block `go mod vet`.
* Refactor most of the core code into a library in `x/tools` that can be used to implement `go mod vet` and `gomoddiff`.
* Move the CLI into `cmd/gomodvet` and `golang.org/x/tools/cmd/gomoddiff`.
* Add `go mod vet` that invokes `cmd/gomodvet`.
Repository: rust
Issue: DepNodeIndex does not uniquely identify anonymous queries
Labels: T-compiler,A-self-profile,A-query-system

The `DepNodeIndex` for an anonymous query is computed from its `DepKind` and from the list of dependencies, but does not depend on its key. As `DepNode`s are deduplicated before creation, the same `DepNodeIndex` can correspond to multiple anonymous query invocations.

Query self-profiling relies on `DepNodeIndex` to identify query invocations.

The consequences of this deduplication on self-profiling need further investigation.

cc @michaelwoerister
Repository: TypeScript
Issue: Support for `Object.hasOwn` (`lib.d.ts` and narrowing)
Labels: Suggestion,Domain: lib.d.ts,ES Next

`Object.hasOwn(obj, key)` has just moved to stage 3.

https://github.com/tc39/proposal-accessible-object-hasownproperty
Repository: pytorch
Issue: [local lint] Shellcheck quicklint file filter is incorrect
Labels: triaged,better-engineering

Since `make shellcheck CHANGED_ONLY=--changed-only` essentially does `git status | egrep '.sh$'`, it will miss extracted GitHub actions YAMLs from `tools/extract_scripts.py` (since they are `.gitignore`d). It will also spuriously include any changed shell scripts, whereas in CI we only lint the extracted workflows and `.jenkins` (though maybe we should change this)?
Repository: flutter
Issue: ImagePicker plugin with Camera time countdown
Labels: p: image_picker,package,c: proposal,team-ecosystem,P3,triaged-ecosystem

Default time countdown is 5 seconds, I  believe we should be able to set a default countdown or rather not use it
Repository: godot
Issue: Visual Script function which returns Constant (Array) - returns reference, but not value.
Labels: bug,topic:visualscript

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
3.3.2

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
macOS

**Issue description:**
<!-- What happened, and what was expected. -->
Happened: confusion as to why constant array from another function is being saved
in the memory and reused.

Expected: using UNNAMED constants inside functions to utilize their function-lifetime-values, help creating decoupled
values from variables for reuse in another functions.

Example: function which returns names of node children and uses Constant with empty array.
Those names shuffled and used in another function to show random strings in the interface.
Right now the problem is that every time first function called - it will be populated with more and more
children names, affecting function logic "give me children names for this one node".
Workaround - Constant -> Array.duplicate() right away, which is a problem since Visual Script becomes more
hard to read and understand the point of this particular action, especially for non programmers.

![изображение](https://user-images.githubusercontent.com/4563032/119555057-16d1c880-bda6-11eb-904e-1f34d1dd3b8e.png)


**Steps to reproduce:**
1) Create function which returns constant with empty array
2) Append elements into array inside another function
3) Print changes to array each time
4) See that function that returns constant returns REFERENCE to constant, but not VALUE.
And this unnamed constant from first function is somehow somewhere saved and used every time
another function gets it.

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Dr
ag and drop a zip archive to upload it. -->

Just start the scene and see the logs:

[poolvector2arrayrepro.zip](https://github.com/godotengine/godot/files/6541747/poolvector2arrayrepro.zip)
Repository: neovim
Issue: ui_compositor.c segmentation fault
Labels: ui,needs:repro,bug-crash

<!-- Before reporting: search existing issues and check the FAQ. -->

I've checked around recent issues and searched through with keywords but didn't find anything related. If I missed something, I sincerely apologize.

- `nvim --version`: v0.5.0-dev+1354-ga282a177d
- Operating system/version: Linux 5.12.6-arch1-1 x86_64
- Terminal name/version: alacritty 0.8.0 (a1b13e68)
- `$TERM`:

### Steps to reproduce using `nvim -u NORC`
I have no idea, tbh. I **believe** that I had just used undo and this error was thrown. I've since tried to reproduce it by undoing thousands of changes to various files with no issues. 

Error message:
![nvim_error](https://user-images.githubusercontent.com/59481467/119558115-e104f380-bd55-11eb-9fec-a0a594c59bb6.png)

Edit: I recognize that this may be related to a plugin's functionality and how it interacts with Neovim's source code. I have submitted this here because the error thrown mentioned Neovim's source code and I figured it might be clear or helpful to someone else who knows what they are doing.
Repository: rust
Issue: rustc output could be more clear for double Result consumtption with ? / Try
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&gist=d7983fe62904168513818cd408466b11

```rust
struct Thing(u32);

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let maybe_u32 = Some("32".to_string());

    let thing = if let Ok(parsed_u32) = maybe_u32
    .unwrap_or_default()
    .parse()?
    {
        Thing(parsed_u32)
    } else {
        Thing(0)
    };
    
    drop(thing);
    
    Ok(())
}
```

The current output is:

```
error[E0277]: the trait bound `Result<_, _>: FromStr` is not satisfied
 --> src/main.rs:8:6
  |
8 |     .parse()?
  |      ^^^^^ the trait `FromStr` is not implemented for `Result<_, _>`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0277`.
error: could not compile `playground`

To learn more, run the command again with --verbose.
```

<!-- The following is not always necessary. -->
Ideally the output should look like:

```
8 |     .parse()?
  |             ^ `?` is unnecessary as the Result is already consumed
```

<!--
If the problem is not self-explanatory, please provide a rationale for the
change.
-->
The current output is surprisingly obtuse for what is a simple fix, although I understand it might be hard for the compiler to tell that this is the case.

The fix for this error is to just remove the try operator (`?`).

<!--
If dramatically different output is caused by small changes, consider also
adding them here.

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. The output might also be
different depending on the Edition.
-->