sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: net/http/httptest: httptest on Windows is IPv4-specific
Labels: help wanted,OS-Windows,NeedsInvestigation

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

go version go1.11.1 windows/amd64

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

windows/amd64

### What did you do?

Run a test leveraging net/http/httptest on a host with IPv6 but without IPv4.

To reproduce:

1. As administrator, run <pre>netsh interface ipv4 uninstall</pre>
1. Reboot
1. Execute an httptest as in https://play.golang.org/p/xlMUEEhgj5s

### What did you expect to see?

Test would pass, since the client and server code were both valid, and pass when IPv4 is available.

### What did you see instead?

2019/01/15 17:26:59 Get http://[::1]:49679: dial tcp [::1]:49679: failed to find ConnectEx: An address incompatible with the requested protocol was used.
Repository: godot
Issue: Mono No errors reported for async functions, game continues
Labels: discussion,usability,topic:dotnet

<!-- 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 non-official. -->
c6b587636b1e3cf27e566e6e5b10859316cbefb6

**OS/device including version:**
<!-- Specify GPU model and drivers if graphics-related. -->
Ubuntu 18.10, Mono 5.16

**Issue description:**
<!-- What happened, and what was expected. -->
When an async function fails to execute due to an error, it will not report the error to the console, and will not stop execution of the game.

**Steps to reproduce:**
Do something erroneous in an async function; observe that your mistake is not reported.

```
using Godot;
using System.Threading.Tasks;

public class TestScript : Node
{
    public override void _Ready()
    {
        AsyncFunc();
    }

    private async Task AsyncFunc()
    {
        GD.Print("Running...");
        var myArray = new int[3];
        myArray[4] = 0; //Whoopsie-doodle!
        GD.Print("Done.");
    }
}
```

**Minimal reproduction project:**
<!-- Recommended as it greatly speeds up debugging. Drag and drop a zip archive to upload it. -->
[NoAsyncError.zip](https://github.com/godotengine/godot/files/2762149/NoAsyncError.zip)
Repository: rust
Issue: Confusing error message: the trait bound `String: From<impl Into<String>>` is not satisfied
Labels: C-enhancement,A-diagnostics,T-compiler,D-confusing

[Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=cdcd8450f4c81cab2c3c297bcf51e7ef)
```rust
struct Foo(String);
trait Bar {
    fn buz(&self, s: impl AsRef<str>) -> Foo;
}
impl Bar for () {
    fn buz(&self, s: impl Into<String>) -> Foo
    {
        Foo(s.into())
    }
}
```
The true error is that the trait signature is different than the `impl` block (and maybe the `impl` keyword shall not be in the trait as yet?). The message however, is really confusing:

```text
error[E0277]: the trait bound `std::string::String: std::convert::From<impl Into<String>>` is not satisfied
 --> src/lib.rs:6:5
  |
6 |     fn buz(&self, s: impl Into<String>) -> Foo
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::convert::From<impl Into<String>>` is not implemented for `std::string::String`
  |
  = help: consider adding a `where std::string::String: std::convert::From<impl Into<String>>` bound
  = note: required because of the requirements on the impl of `std::convert::Into<std::string::String>` for `impl Into<String>`
  = note: the requirement `impl Into<String>: std::convert::Into<std::string::String>` appears on the impl method but not on the corresponding trait method

error: aborting due to previous error
```
Repository: godot
Issue: InputEventMouse.global_position doesn't return global position
Labels: bug,confirmed,topic:input

Godot version: v3.1.beta1.official
OS: Ubuntu 18.10

This can easily be seen by having a camera around & moving it and on a node place:

```gdscript
func _unhandled_input(event: InputEvent) -> void:
	if event is InputEventMouse:
		print(get_global_mouse_position(), event.position, event.global_position)
```

Output eg.:
```
(2398.499023, 814.499573)(1918.499878, 742.499939)(1918.499878, 742.499939)
```

`event.global_position == even.position` is `true`.
Repository: vue
Issue: Allow nested transition to trigger upon removal
Labels: feature request,transition

### Version
2.5.22

### Reproduction link
[https://jsfiddle.net/wx91uLft/](https://jsfiddle.net/wx91uLft/)
other: https://jsfiddle.net/ae82rfnv/






### Steps to reproduce
- Show/hide elements with the  "Toggle" button.
- Show/hide elements with the  "Toggle Ticked" button. Shows a workaround.

### What is expected?
All transitions should be triggered on leave, even for nested child elements.

### What is actually happening?
Transition classes don't get applied to nested child elements, when conditions for leaving transitions occur on the same tick.

Workaround: Delaying the parent transitions by one tick fixes the problem.

---
This has been reported, but got closed due to the sample code did not use `appear` on the `<transition>` elements. (See issues [#7643](https://github.com/vuejs/vue/issues/7643) and [#9243](https://github.com/vuejs/vue/issues/9243))

My example is more detailed and also provides a workaround.

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: opencv
Issue: Potential bug (rounding error?) in cv::mean() in OpenCV 4.0.0
Labels: category: core

## System information (version)
- OpenCV => 4.0.0 (maybe 3.4.x for x > 0)
- Operating System / Platform => Windows 10, 64 Bit
- Compiler => Visual Studio 2017


## Detailed description

We encountered a problem(?) with the ``cv::mean()`` function while switching from **OpenCV 3.4.0** to **OpenCV 4.0.0** lately.

Given the following image and mask

![img](https://user-images.githubusercontent.com/2692578/51246633-24334880-198b-11e9-920e-6f354a14f7ec.png) ![mask](https://user-images.githubusercontent.com/2692578/51246643-25fd0c00-198b-11e9-88d1-67305b2e0b2c.png)

and the following code

```c++
cv::Mat img = cv::imread("img.png", cv::IMREAD_GRAYSCALE);
cv::Mat mask = cv::imread("mask.png", cv::IMREAD_GRAYSCALE);
cv::Scalar mean = cv::mean(img, mask);
```

we get the following values for `mean[0]`:
* `255.00000000000000` for **OpenCV 3.4.0** and
* `255.00000000000003` for **OpenCV 4.0.0**.

Unfortunately, a lot of checks like `mean[0] <= 255` will now fail as you can imagine...


## Steps to reproduce

Download the above images and run the above code.


## Wild guess

We had a brief look at the source code differences between the aforementioned OpenCV versions with respect to the ``cv::mean()`` function. The only changes we could found were:

**OpenCV 3.4.0** - modules/core/src/stat.cpp

```c++
1500    uchar* ptrs[2];

1514    buf = _buf;
```

**OpenCV 4.0.0** - modules/core/src/mean.cpp

```c++
130    uchar* ptrs[2] = {};

144    buf = _buf.data();
```

Unfortunately, we don't have resources to further investigate this issue on our own, but hopefully, we could provide a clue into the right direction.
Repository: TypeScript
Issue: Undocumented node_modules/@types fallback strategy for classic module resolution
Labels: Suggestion,Awaiting More Feedback,Add a Flag

I'm using TypeScript 2.7.2 with MSBuild 15.9.21.664

A fallback was added to classic module resolution to resolve modules using node_modules/@types in this PR https://github.com/Microsoft/TypeScript/pull/11147
Going purely from the Module Resolution section of the handbook, I would have expected this behaviour only when using node module resolution. 

This is undocumented behavior is an issue because the fallback will override any ambient module declarations in the resolution process.

To give some context, I have a ASP.NET MVC project that uses MSBuild to compile TypeScript. This project takes advantage of some TypeScript files in a separate NPM project located up a few directions on in the File system by using the following csproj syntax:
````
<TypeScriptCompile Include="..\..\external-typescript-project\src\Cat.ts">
     <Link>Scripts\app\Cat.ts</Link>
</TypeScriptCompile>
````
When MSBuild shells out to tsc it does so like `tsc "..\..\external-project\src\Cat.ts"`. 

So far so good, except if both projects share the same TypeScript definition dependency i.e. if both the MVC project and external NPM project have a TypeScript definition for jQuery, the "..\..\external-typescript-project\node_modules@types\jquery.index.d.ts" is used in preference to the MVC project's ambient jQuery module declaration.
If I manually delete the "..\..\external-typescript-files\node_modules@types\jquery.index.d.ts" file the MVC project gets the correct ambient module declaration.

In an ideal world I'd disable MSBuild triggering the compilation using `<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>` and manage TypeScript definition dependencies using NPM with module resolution "node", but the entire project relies on ambient module declaration files in a custom ".\typescript-definitions" folder which gets passed to the TypeScript compiler i.e. `tsc "..\..\external-project\src\Cat.ts" "typescript-definitions\jquery\index.d.ts"`, so it would be a tricky migration. 

My understanding is path mapping would solve the issue, but unfortunately this isn't supported by MSBuild. I would like the ability to opt-out of falling back to node_modules/@typings when using classic module resolution, or at the very minimum this behaviour could be documented.
Repository: vue
Issue: Vue-Mobx integration broken with PR #7828
Labels: need repro

### Version
2.5.18

### Reproduction link
[https://codesandbox.io/s/k90k8kwn2r](https://codesandbox.io/s/k90k8kwn2r)







### Steps to reproduce
* Use the `mobxjs/mobx-vue` package (or a custom integration with Mobx)
* Everything worked fine on Vue 2.5.17 and is broken on 2.5.18 and above
* See that TypeErrors are thrown

### What is expected?
Vue would not attempt to to set the `__proto__` property of a Proxy.

### What is actually happening?
Reactivity with Mobx is broken:

[Vue warn]: Error in event handler for "input": "TypeError: 'set' on proxy: trap returned falsish for property '__proto__'"
---
We attempted to upgrade Vue from 2.5.17 to latest version for our applications - thought it would be smooth because upgrade target was still 2.5.x, but ever version after 2.5.18 is broken with Mobx integration.

We have a custom integration with Mobx-state-tree, but some of the code is very similar to `mobxjs/mobx-vue` integration code.  We are not using that library, and I'm not a Vue internals expert,  but I _think_ I  tracked the problem down to this PR: https://github.com/vuejs/vue/pull/7828.  

Since then I have searched around and found this issue reported to that package also: https://github.com/mobxjs/mobx-vue/issues/15#issuecomment-453570397.  @Nemikolh wrote the codesandbox example I referenced above and it appears to be the same conclusion.

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: go
Issue: cmd/go: `go mod download -json` is incomplete
Labels: NeedsFix,early-in-cycle,modules

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.11.4 linux/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
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/steb/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/steb/projects/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/go"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/run/user/1000/tmp/go-build023848120=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

1. Ran `go mod download -json`.
2. Bundled up all files listed in the JSON output (adding `/list` files as needed).
3. Tried to replay this bundle, using an HTTP server as a GOPROXY.

### What did you expect to see?

`go build`, `go mod download` should work without fetching anything.

### What did you see instead?

`go build` and `go mod download` is getting 404 errors due to files missing from the bundle. It looks like `go build` is trying to fetch:

1. Packages mentioned in `go.sum` files that aren't actually needed for the build (as far as I can tell, at least).
2. Older (minor) versions of packages mentioned in some dependencies' go.mod files.

I'd expect `go mod download -json` to return a list of *every* downloaded package.

---

Context: I'm trying to integrate `go mod` with IPFS.

* Dead-simple (but easy to read) bash implementation: https://gist.github.com/Stebalien/7bfd1ea07f81c1fbbe9eadac4faeccd3
* Slightly better (but more complicated) go implementation: https://github.com/Stebalien/ipgo/blob/master/main.go

Testing against: https://github.com/anacrolix/torrent/tree/ipgo
Repository: electron
Issue: Add new protocol interceptor that allows delegating to URLRequestHttpJob
Labels: enhancement :sparkles:

**Is your feature request related to a problem? Please describe.**
As a user of electron, I want to be able to intercept http requests and optionally send a response back. If I don't choose to send a response I want it to be handled by chrome's network stack.

**Describe the solution you'd like**
I'd like to add a new protocol like interceptFooProtocol that:
* Calls into a handler at various points in the request job (at the start of the request, after headers are constructed, when headers are received, etc)
* Allows optionally providing a http response for the job
* If an http response is not provided, delegates to `URLRequestHttpJob` in chrome

**Describe alternatives you've considered**
* Use `interceptStreamProtocol` and use the node network stack
  * The problem with this is that `URLRequestHttpJob` does a lot under the hood, and rewriting it in js is possible, but a lot of work. Among other things it adds headers, manages cookies, and checks ssl certs for pinning.
  * The other problem is that as bugs arise with interceptStreamProtocol it still needs to go through electron to be fixed, vs calling into `URLRequestHttpJob` and knowing that it will be handled the same as chrome.
* Use [WebRequest](https://electronjs.org/docs/api/web-request) to intercept
  * This only allows inspecting the request or cancelling it, you can't provide an http response as far as I can see.

**Additional context**
* This would be helpful in bringing [offline support to nativefier](https://github.com/jiahaog/nativefier/issues/680).
* I've also been discussing this with Ryan Patterson who's working on [chronicler](https://github.com/CGamesPlay/chronicler) (cc @CGamesPlay)
Repository: scrcpy
Issue: The LG K8 does not operate the mouse wheel
Labels: input events

I play the **Bowling King** game through **scrcpy** (phenomenal app) and I have a problem. My keys are all keys except the dial when I need to play the ball. Then I need to **roll back** the wheel and the ball should drop to go, but it will not. I found this instruction but I do not know if this is for this problem. At this address. How can I fix this? Thank you.
https://github.com/Genymobile/scrcpy/pull/27
Repository: godot
Issue: Polygon2D texture not displaying correctly.
Labels: bug,topic:rendering,confirmed,topic:2d

<!-- 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 non-official. -->
9c1768836f25e780a7ef51a1d18a0a15e0b55e42

**OS/device including version:**
<!-- Specify GPU model and drivers if graphics-related. -->
Win10 64bit

**Issue description:**
<!-- What happened, and what was expected. -->
When using a atlas/region texture resource for the polygon texture, it works fine in the polygon editor, but shows the whole source texture in the canvas editor and in game.

From this:

![godot_master_2019-01-17_01-21-26](https://user-images.githubusercontent.com/13004169/51285278-ff74ba80-19f6-11e9-9f66-cd9ec18c61d5.png)

To this:

![godot_master_2019-01-17_01-21-40](https://user-images.githubusercontent.com/13004169/51285281-026fab00-19f7-11e9-93a2-bdf7ebb5d319.png)


**Steps to reproduce:**

1. Create an atlas texture resource.
2. Assign it to a Polygon2D's texture.
3. Create the points of the polygon.


**Minimal reproduction project:**
<!-- Recommended as it greatly speeds up debugging. Drag and drop a zip archive to upload it. -->
[3.1 Polygon Texture Issue.zip](https://github.com/godotengine/godot/files/2766502/3.1.Polygon.Texture.Issue.zip)
Repository: vscode
Issue: Disable Multiple Cursors
Labels: feature-request,editor-multicursor

I don't use the 'multiple cursors' feature, and there doesn't appear to be any way to turn it off. 

You can change the key binding between ctrl and alt, but there's no way to prevent multiple cursors from being created altogether. If you use these modifiers for other things, it's easy to accidentally create multiple cursors in random places and end up with text in areas you don't expect. 

Being able to set this key binding to 'none' would probably be sufficient.
Repository: TypeScript
Issue: Auto fixable quick fixes
Labels: Suggestion,API,Domain: TSServer,Domain: Quick Fixes,Experience Enhancement

VS Code is investigating the concept of autofixable quick fixes. You can find the current proposal [here](https://github.com/Microsoft/vscode/issues/62110#issuecomment-454182230)

## Motivating use case
You open the following TS file:

```ts
interface IFoo {
    bar(): void;
}

class Foo implements IFoo { }

new foo()
```

This file has two errors: incorrect interface implementation on `class Foo` and a spelling error in `new foo()`

You hit `F8` to start navigating through errors. While navigating, you can hit a single keyboard shortcut to auto implement the interface or to correct `foo` -> `Foo` 

## Current VS Code proposal
To implement auto fixes, VS Code [currently proposes](https://github.com/Microsoft/vscode/issues/62110#issuecomment-454182230) that some quick fixes be marked with a `canAutoApply` flag. This flag would indicate that:

- The quick fix will fix the underlying problem (and not suppress it or hide it)
- The quick fix can be fairly safely automatically applied without user input
- The provider of the quick fix is relatively confident that the quick fix could be correct (100% confidence is not required since the auto fix is being triggered by a user action). More importantly, the quick fix should be easy to undo if it is incorrect

When the user hits `auto fix` in VS Code, if only a single `canAutoApply` quick fix is returned for a diagnostic, VS Code would automatically apply it. If multiple `canAutoApply` fixes are returned, we would show a list of these for the user to select from. The existing, more complete list of quick fixes and code actions could still be accessed using the lightbulb menu

## Proposal for TS
The UX experience of being able to auto fix errors with a single keyboard shortcut is very nice and I think we can make reasonable fix assumptions about a fair number of real world errors. The work that would be required on the TS side to support the proposed auto fix feature in VS Code:

- Add an optional `canAutoApply` property on the TS `CodeFix` objects
- Add some logic to decide when a fix can be marked as `canAutoApply`. `//@ts-ignore` fixes for example should never be marked as `canAutoApply` but spelling errors, add missing `this`, and perhaps even `add missing import` could be.

The initial implementation would only need  to support `canAutoApply` for a small set of diagnostics, which could be expanded in future releases.

/cc @DanielRosenwasser, @minestarks, @amcasey
Repository: TypeScript
Issue: "fix everything in this file" code action
Labels: Suggestion,In Discussion,API,Domain: TSServer,Domain: Quick Fixes

VS Code is investigating an api for better support for fixing all fixable errors in a file with a single action. This action could also be triggered on save. You can find the current proposal [here](https://github.com/Microsoft/vscode/issues/62110#issuecomment-454182230)

## Motivating use case
You change a file's extension from `ts` to `js` and start seeing lots of errors about converting your old jsdocs to real types. Thankfully you've enabled `"editor.codeActionsOnSave": { "source.autoFix": true }` in VS Code and TypeScript has implemented this feature. So you just save the file and all your jsdocs are converted to types (along with fixing other trivial errors)

## Current VS Code proposal
The current VS Code [proposal](https://github.com/Microsoft/vscode/issues/62110#issuecomment-454182230) for this requires that extensions return a single source code action marked as `autoFix`. This action would contain all auto-fix edits for the file. We'd handle applying these edits on save.

## Proposal for TS
To implement this properly for TS, we likely need a new TS server api that would take a file and return a set of edits that fix all of the trivial errors within that file. Making this a single API call per file allows TS to properly handle overlapping fixes within the file. Candidates for what could be fixed automatically:

- Errors with one, well known quick fix, such as `convert jsdocs to types`
- Trivial coding errors where the intent of the programmer was clear.

I see this feature as being  especially helpful for JS -> TS. The initial implementation would only need  to support fixes for a small set of diagnostics, which could be expanded in future releases.

/cc @DanielRosenwasser, @minestarks, @amcasey