sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Improve enum usage in Dictionary exports for C#
Labels: enhancement,topic:gdscript,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. -->
3.1.1

**OS/device including version:**
<!-- Specify GPU model and drivers if graphics-related. -->
Win10

**Issue description:**

Feature request:

I am trying to export a dictionary of `enum: float`. In the editor my enum shows up as an int, instead of a string. This makes it difficult to use. There is also no auto-complete available. If possible these would be great features to have.

**Steps to reproduce:**

    [Export]
    public Godot.Collections.Dictionary Weights = new Godot.Collections.Dictionary() {
        {EnumName1, 0.5}
    };

Appears as the following in the editor

![image](https://user-images.githubusercontent.com/7429786/56982021-246be400-6b35-11e9-9d08-70ef84645790.png)

If you type the dictionary, it will correctly set the value as a float (otherwise initializing to 1 will cause it to be an int in the editor), but the enum is still not auto-translated to a string in the editor.


    [Export]
    public Godot.Collections.Dictionary<ClassName.EnumNames, float> Weights = new Godot.Collections.Dictionary<ClassName.EnumNames, float> () {
        { EnumName1, 1 } // 1 will be a float in the editor, but EnumName1 will still show up as 11 and not offer auto-complete
    };

Using a C# dictionary causes the exported var to not show up at all in the editor.
Repository: opencv
Issue: Positional Argument `outImg` Should Be Keyword Argument in cv2.drawMatches
Labels: category: python bindings,category: documentation

##### System information (version)
- OpenCV => 4.0.1
- Operating System / Platform => MacOS 10.14 Mojave
- Compiler => XCode 10.1

##### Detailed description

The docstring says

> drawMatches(...)
>     drawMatches(img1, keypoints1, img2, keypoints2, matches1to2, outImg[, matchColor[, singlePointColor[, matchesMask[, flags]]]]) -> 
> 
> @param outImg Output image. Its content depends on the flags value defining what is drawn in the output image. See possible flags bit values below.

But it doesn't mention that passing `None` would actually eliminate the need to instantiate a placeholder image to draw on, which would otherwise be quite the task in itself - how would one even calculate the output size of a feature-matched pair of images with lines?

Either way, the **actual behavior** of the `outImg` positional argument is exactly what a Python **kwarg** is meant to do. Please implement this breaking change (breaking changes are necessary in software development).

[See this StackOverflow thread](https://stackoverflow.com/questions/31631352/typeerror-required-argument-outimg-pos-6-not-found/31631995) for the confusion this has caused.

##### Steps to reproduce
```python
import cv2
cv2.drawMatchesKnn(img1, kp1, img2, kp2, matches, None)
```
Repository: TypeScript
Issue: `paths` not used for auto import
Labels: Bug,Domain: Quick Fixes

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

From https://github.com/Microsoft/vscode/issues/72931
<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.5.0-dev.20190430

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
- paths
- auto import

**Repo**
1. clone https://github.com/ac566/typescript-auto-import-issue and open in vscode
1. In VS Code, set `"typescript.preferences.importModuleSpecifier": "non-relative"`
1. Open `src/app/app1/test.ts`
1. Delete the import for `TestType`
1. Try using a quick fix or auto import to add the impact back


**Expected behavior:**
The import is added as `import { TestType } from "@myLib/example_2";`

The is expected since the tsconfig configures `paths` and the import of `@myLib/example_2` was previously working properly:

```
{
    "compilerOptions": {
        "target": "es5",
        "module": "es2015",
        "moduleResolution": "node",
        "baseUrl": ".",
        "paths": {
            "@myLib/*": [
                "./src/lib/src/*/_index.ts"
            ]
        }
    }
}
```


**Actual behavior:**
The import is added as `import { TestType } from "@myLib/example_2/_index";`
Repository: go
Issue: cmd/go: go get -u behaves differently with and without GOPROXY when a module doesn't exist at head
Labels: NeedsInvestigation,GoCommand,modules

<pre>
$ go version
go version devel +fbc6a97222 Mon Apr 29 19:54:30 2019 +0000 linux/amd64
</pre>
The problem exists with go1.12 as well.

### What did you do?
Without proxy, I could run `go get -u` successfully. With proxy, it fails with cryptic error message.

<pre>
$ export GOPROXY=direct
$ mkdir scratch; cd scratch; go mod init example
$ go get github.com/spf13/viper
$ go get -u
go: finding golang.org/x/sys latest
go: finding golang.org/x/crypto latest
go: finding golang.org/x/tools latest
go: finding github.com/ugorji/go/codec latest
go: finding gopkg.in/check.v1 latest
go: finding golang.org/x/sync latest
go: finding golang.org/x/net latest
go: finding github.com/armon/consul-api latest
</pre>

<pre>
$ export GOPROXY=https://proxy.golang.org
$ mkdir scratch; cd scratch; go mod init example
$ go get github.com/spf13/viper
$ go get -u
go get: upgrading github.com/ugorji/go/codec@v0.0.0-20181204163529-d75b2dcb6bc8: reading https://proxy.golang.org/github.com/ugorji/go/codec/@v/list: 404 Not Found
</pre>

What happens underneath:

The viper module or its dependencies have dependency on github.com/ugorji/go/codec@v0.0.0-20181204163529-d75b2dcb6bc8.  The `github.com/ugorji/go/codec` does not exist in the origin at head (no go.mod file, no valid tag), but it probably existed with `@d75b2dc`. Thus, `go mod download github.com/ugorji/go/codec@v0.0.0-20181204163529-d75b2dcb6bc8` succeeds with and without GOPROXY.

But when trying to upgrade, with GOPROXY=direct, the go command runs a sequence of git commands and detects there is no tag, no go.mod file at head and doesn't attempt to upgrade. 

With GOPROXY=<proxy>, the go command queries /@v/list endpoint to find available module versions. The proxy doesn't know about the named module (because the module doesn't exist according to what `go list -m -v` reports), so answers HTTP error (404/410/500/...). Then, the go command treats it as a hard error. 

I think in this case (the list query failure), the go command should not fail but proceed as if there is no newer version to upgrade (indeed, there is no version to upgrade to!)
Repository: TypeScript
Issue: Object.getOwnPropertyDescriptors accepts undefined (lib.es2017.object.d.ts)
Labels: Bug,Domain: lib.d.ts

**TypeScript Version:**  3.4.5

**Search Terms:**
getOwnPropertyDescriptors

**Code**
```ts
Object.getOwnPropertyDescriptors(undefined);
```

**Expected behavior:**
Undefined is not accepted.

**Actual behavior:**
Undefined is accepted.

**Playground Link:**
https://www.typescriptlang.org/play/index.html#src=Object.getOwnPropertyDescriptors(undefined)%3B

However, can't seem to enable es2017 in the Playground

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
n/a
Repository: terminal
Issue: Console window cannot be closed when in selection mode before WSL tty is ready
Labels: Product-Conhost,Area-Interop,Issue-Bug

On Windows 10 1903 (build 18362.86), but could be the same on other build, I didn't test on earlier ones or 20H1.

Launching a WSL distribution opens a console window and connects it as a tty* to the instance.
If an edit selection is marked before the client process gets connected, for example by click and drag over the window client area right when it appears in QuickEdit Mode, before any output gets displayed, the output is paused until the selection is cancelled or copied.

In that state, trying to close the console window using the [X] button does not close the console, and instead seems to queue the WM_CLOSE until the output is resumed by cancelling or copying the selection.
This means if a user triggers a selection before the shell gets displayed, the close button seems ineffective until they first resolve the selection issue, at which point the window gets closed even if the user changed their mind. In QuickEdit Mode, if a selection is triggered by mistake, it might not be obvious to the user, and pressing the close button several times has no effect.

In the state shown in the screenshot, the close button does not work :
![conhost closing refused](https://user-images.githubusercontent.com/25664275/56991190-52821000-6b97-11e9-8313-80be217b6f45.png)

This only seems to happen with WSL distributions, probably because Win32 CUI processes are always started before a console gets created or attached to their process, making it always ready to process WM_CLOSE, while in WSL the console gets created before the shell process gets started and connected to it.

Current behavior: Pressing the close button does nothing while in selection mode, and when selection is over, the window gets closed even if user doesn't press the close button again.

Expected behavior: Pressing the close button should always be a reliable way to close a console window.

Instead of an ineffective close button that only reacts asynchronously once the selection is over, pressing the close button (or processing a WM_CLOSE sent by another process to the console window's message queue) should automatically cancel any selection underway, similar to how the selection gets cancelled if a keypress gets processed.
This wouldn't change the behavior for Win32 CUI processes, and would resolve the issue for WSL instances.
Repository: flutter
Issue: iOS Add2App profile mode can't attach/find observatory
Labels: platform-ios,tool,a: existing-apps,a: debugging,customer: amplify,P3,team-ios,triaged-ios

`flutter run --profile` on a iPhone allows you to attach and use the observatory in a normal way.

However, running in a profile mode add2app scenario does not.
Repository: godot
Issue: GIProbe based GI is wrong for intersecting or overlapping geometry
Labels: bug,topic:rendering

**Godot version:**
Godot master (#25670)

**OS/device including version:**
Windows 10

**Issue description:**
Voxel based GI (with GIProbe) is not computed correctly for intersecting or overlapping geometry.

![gierrora](https://user-images.githubusercontent.com/1067920/56994863-9299c080-6ba0-11e9-8cc2-e3d9478b8f55.png)
![gierrorb](https://user-images.githubusercontent.com/1067920/56994867-9594b100-6ba0-11e9-985d-3a00977830c6.png)

**Minimal reproduction project:**
[test0 - Kopie.zip](https://github.com/godotengine/godot/files/3133225/test0.-.Kopie.zip)
Repository: flutter
Issue: rename the `--observatory-port` cli arg of `flutter run`
Labels: tool,c: API break,P3,team-tool,triaged-tool

`flutter run` supports an `--observatory-port` cli arg. That's the name of an app which uses the service protocol. We should rename that to something that better describes what it does.

`flutter run --service-protocol-port` would be more correct. `flutter run --debug-port` might be a bit more meaningful for the user (and shorter to type).
Repository: flutter
Issue: Output of "flutter channel beta" when there's a hot fix pending is disturbing
Labels: tool,a: first hour,P2,team-tool,triaged-tool

I downloaded v1.4.9-hotfix.1-beta and tried to do `flutter channel beta` and the output was concerning:

```
ianh@ianh:~/dev/test-install$ tar xf flutter_linux_v1.4.9-hotfix.1-beta.tar.xz 
ianh@ianh:~/dev/test-install$ cd flutter/
ianh@ianh:~/dev/test-install/flutter$ bin/flutter channel beta
  ╔════════════════════════════════════════════════════════════════════════════╗
  ║ A new version of Flutter is available!                                     ║
  ║                                                                            ║
  ║ To update to the latest version, run "flutter upgrade".                    ║
  ╚════════════════════════════════════════════════════════════════════════════╝

Switching to flutter channel 'beta'...
git: From https://github.com/flutter/flutter
git:  + 88fa7ea40...09cbc34a0 beta                    -> origin/beta  (forced update)
git:    6c7b6833c..0ba67226e  dev                     -> origin/dev
git:    6c7b6833c..514fb2c7c  master                  -> origin/master
git:  * [new branch]          revert-30339-tap-buttons -> origin/revert-30339-tap-buttons
git:    e9dd13d1a..5ae6952c0  revert-30873-revert-30414-remove-hover-pressure -> origin/revert-30873-revert-30414-remove-hover-pressure
git:  * [new branch]          revert-30951-roll_branch -> origin/revert-30951-roll_branch
git:  * [new branch]          revert-30991-caretheight -> origin/revert-30991-caretheight
git:  * [new branch]          revert-30995-revert_engine -> origin/revert-30995-revert_engine
git:  * [new branch]          revert-31736-roll_build -> origin/revert-31736-roll_build
git:  * [new branch]          revert-31801-revert-30339-tap-buttons -> origin/revert-31801-revert-30339-tap-buttons
git:  * [new branch]          v1.5.4-hotfixes         -> origin/v1.5.4-hotfixes
git:  * [new tag]             v1.5.0                  -> v1.5.0
git:  * [new tag]             v1.5.1                  -> v1.5.1
git:  * [new tag]             v1.5.2                  -> v1.5.2
git:  * [new tag]             v1.5.3                  -> v1.5.3
git:  * [new tag]             v1.5.4                  -> v1.5.4
git:  * [new tag]             v1.5.4-hotfix.1         -> v1.5.4-hotfix.1
git:  * [new tag]             v1.5.8                  -> v1.5.8
git:  * [new tag]             v1.5.5                  -> v1.5.5
git:  * [new tag]             v1.5.6                  -> v1.5.6
git:  * [new tag]             v1.5.7                  -> v1.5.7
git: Already on 'beta'
git: Your branch and 'origin/beta' have diverged,
git: and have 1 and 173 different commits each, respectively.
git:   (use "git pull" to merge the remote branch into yours)
ianh@ianh:~/dev/test-install/flutter$ 
```

As a user I don't know what to make of all this nonsense.

cc @jonahwilliams
Repository: godot
Issue: String parsing behavior is inconsistent between float() and int() in gdscript
Labels: bug,discussion,topic:core,breaks compat

This probably can't be fixed due to a breakage of incompatibility but I've noticed that the functions `int` and `float` behave subtly differently in strange ways:

```
int("456") # yields 456
int("asdfjaldsgja;lsdgj456") # yields 456
int("dfkj4dkfjj5dkjf6dfkjdk") # yields 456
int("4.56") # yields 4
int("4kgjsdjkfhglskd.b56") # yields 4
int("4.5.6") # yields 4
int("1e3") # yields 13
```

Essentially, int seems to do a left-right parse ignoring any character except [0-9] and ".". After it hits the first "." it will terminate.

Compare this with float

```
float("456") # yields 456
float("asdfjaldsgja;lsdgj456") # yields 0
float("dfkj4dkfjj5dkjf6dfkjdk") # yields 0
float("4.56") # yields 4.56
float("4kgjsdjkfhglskd.b56") # yields 4
float("4.5.6") # yields 4.5
float("1e3") # yields 1000
```

The float parser appears to abort the second it sees a non [0-9] or "." character except `e`. I expect this is due to the handling of exponentiation. It'll also terminate upon hitting a second decimal point, e, or a "." occurring anywhere after an "e".

You probably shouldn't have arbitrary text in the strings you're trying to convert to numbers anyway, but I think this should at least be documented in case someone hits it. To me, the most dangerous one is the difference between `int("1e3")` and `float("1e3")` which is a difference that could theoretically occur even in seemingly well-formed parse strings.
Repository: vscode
Issue: Add a button to open Find All References from Peek References
Labels: feature-request,editor-symbols,references-viewlet

Issue Type: <b>Feature Request</b>

While I typically like to use Peek References (and want to keep it as the default for code lens), once it opens depending on the number of items, I'll then often want to "upgrade" the peek to a full Find All References, but it is not convenient to do so. It would be great if there were a button somewhere like below to run Find All References once the peek is open:

![image](https://user-images.githubusercontent.com/641685/57004802-fa034080-6b9f-11e9-98da-6c1bbd83ec39.png)


VS Code version: Code - Insiders 1.34.0-insider (473af338e1bd9ad4d9853933da1cd9d5d9e07dc9, 2019-05-01T00:22:05.899Z)
OS version: Windows_NT x64 10.0.18362


<!-- generated by issue reporter -->
Repository: storybook
Issue: Addon-docs: support interactions with existing addons
Labels: discussion,addon: docs

From @trevoreyre :

> Any thoughts on how addon-docs would interact with other addons? I notice right now when you switch to the docs tab, the addons panel goes away, as well as any other tabs you have enabled through other addons. I think it would be useful to still be able to interact with other addons, like seeing actions as you're clicking through things in the docs, like you would in a story, or changing themes or context variables and seeing all of the stories in the docs update.

It's tricky because all the addons assume that there is only one story currently visible, and in docs there are potentially many. We have a proposal for "knobs v2" to address this for knobs, but nothing planned to address it in general. How we deal with it generally is open for discussion!
Repository: flutter
Issue: Animate Snackbar (SnackBarBehaviour.floating) with FAB as it does with SnackBarBehaviour.Fixed
Labels: c: new feature,framework,f: material design,c: proposal,P3,team-design,triaged-design

The new behaviour with the snackbar floating works really well rxcept when there is a FAB in the scaffold, the FAB stays in the same position and the snackbar floats above the FAB, instead of adding extra padding to the bottom of the FAB with the snackbar being below.

Is this actually per the MD guidelines or does it need to be updated? Would look a lot better if the FAB bottom padding increased!
Repository: flutter
Issue: Check whether the device can display a specific emoji char
Labels: c: new feature,framework,dependency: dart,a: typography,customer: crowd,P3,team-framework,triaged-framework

When placing the emoji's unicode inside a `Text` widget, I did notice that some Android devices cannot display some emojis (besides the emulators, I've seen it in an Asus Zenfone Go Live). 

There should be a way to detect if an emoji cannot be displayed, so developers can work around.
Repository: flutter
Issue: Allow configuration of Flutter CLI colors
Labels: c: new feature,tool,good first issue,P3,team-tool,triaged-tool

look like in android studio
_red:error_
_brown:debug_
_green:info_
...etc..
and can custom color
Repository: create-react-app
Issue: Performance with SVG as ReactComponent and eslint with React.memo missing display name
Labels: issue: needs investigation

I'm using this component in a `create-react-app` app:

```js
import { ReactComponent as ProfileIcon } from "./icons/profile.svg";

...
render(){
  <ProfileIcon {...props}/>
}
```

Using also `why-did-you-render` (https://github.com/welldone-software/why-did-you-render) I got this warning:

```log
SvgProfileIcon
whyDidYouRender.min.js:1191 {SvgProfileIcon: ƒ} "Re-rendered because the props object itself changed but it's values are all equal." "This could of been avoided by making the component pure, or by preventing it's father from re-rendering." "more info at http://bit.ly/wdyr02"
whyDidYouRender.min.js:1191 prev props: {svgRef: null, className: "icon", height: "24", width: "24"} !== {svgRef: null, className: "icon", height: "24", width: "24"} :next props
```

So I made a custom `PureComponent` like this:

```js
import React from "react";

export default WrappedComponent =>
  React.memo(props => <WrappedComponent {...props} />, () => true);
```

**FIRST QUESTION**: Is this performances-correct?

I'm using it like this:

```js
import { ReactComponent as ProfileIcon } from "./icons/profile.svg";

import PureComponent from "./PureComponent";

const PureProfileIcon = PureComponent(ProfileIcon);

...
render(){
  <PureProfileIcon {...props}/>
}
```

**SECOND QUESTION**: Can I avoid this component at all using React.memo (or something else) differently?

Now eslint is complaining about:

```error
Component definition is missing display name eslint(react/display-name)
```

**THIRD QUESTION**: How can I fix this?
Repository: TypeScript
Issue: Configurable import suggestions to override global types
Labels: Suggestion,Needs Proposal,Domain: Quick Fixes

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Please read the FAQ first, especially the "Common Feature Requests" section.

-->

## Search Terms

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

## Suggestion

In our code base we have a module export called `Option` which we use very often.

However, if we try to reference `Option` in a module where it's not currently imported, we will not get import suggestions/fixes for this.

This is because there is already a (different) global type of the same name, provided by the `dom` `lib` types.

I would like to be able to configure TypeScript and/or VS Code so that I do have import suggestions for `Option`.

Suggestion: any time a module references a global value, and the project has a module export of the same name, provide an import suggestion for that.

Potential caveat of this suggestion: what happens when you select "add all missing imports"? Ideally I would want it to import my `Option`, but what if I intentionally wanted to use the global version instead?

## Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).