sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: terminal
Issue: Missing operator delete/delete[] for some allocated objects
Labels: Product-Conhost,Help Wanted,Issue-Bug,Area-CodeHealth

Hi.

Looks like there are few places in the Terminal code where I can suspect a memory leaks due to missing `operator delete` or `operator delete[]`.
These allocation sites can be grouped into following:
- raw `operator new` without `operator delete` like this https://github.com/Microsoft/Terminal/blob/master/src/cascadia/TerminalConnection/ConptyConnection.cpp#L191
- allocation by `operator new` some global object or class member (https://github.com/Microsoft/Terminal/blob/master/src/cascadia/TerminalControl/TermControl.cpp#L281)
- allocation by `operator new` some memory in a function and return it by raw pointer, which can leak then.

Here is my gist with quite a simple grep for`operator new` calls - https://gist.github.com/dreamer-dead/c43248466fc4d445378b4dfba80d8d25

Is this an intentional behaviour or a bug that should be fixed?
Repository: flutter
Issue: Attach output should give clear instructions when application is already started
Labels: c: new feature,platform-android,tool,a: quality,P3,team-android,triaged-android

Internal: b/132252088

The attach output (if not run with debug-uri or url) currently says: 

```
Waiting for a connection from Flutter on Pixel 3 XL...
```

which does not prompt for a user action.

We should likely enrich this to say:

```
If your app is already running, please restart it (or pass --debug-uri <observatory_url>)
Waiting for your app to run on Pixel 3 XL...
```
Repository: vscode
Issue: Have `createQuickPick` no longer sort by label
Labels: feature-request,api,quick-pick,api-proposal

<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

Similar to https://github.com/microsoft/vscode/issues/63050, I wish to avoid the final sort on the quick pick list. I am using the quickpick as a search field, and the `items` field I set is already sorted by my relevance metric, so I do not want to have VS Code sort the list again . Specifically, I want an option to skip this block: https://github.com/microsoft/vscode/blob/a69d0f8b218498e22b7c3a0f76926cc6322e6106/src/vs/workbench/browser/parts/quickinput/quickInputList.ts#L518-L523)
Repository: flutter
Issue: MergeSemantics should not forcibly merge nodes marked as "explicitChildNodes"
Labels: framework,a: accessibility,d: api docs,a: quality,c: proposal,a: error message,P3,team-framework,triaged-framework

When the MergeSemantics widget attempts to merge its descendants' Semantics nodes, it throws the following assertion: 
```
flutter: 'package:flutter/src/semantics/semantics.dart': Failed assertion: line 2446 pos 16: 'node.parent ==
flutter: null || !node.parent.isPartOfNodeMerging || node.isMergedIntoParent': is not true.
```

I think that
1. the assert message could be clearer in notifying the developer on what is actually causing this problem
2. we should making sure the MergeSemantics documentation properly suggests this could happen

Issue first described in https://github.com/flutter/flutter/issues/31437

EDIT: Now, the goals are as follows:
1. The MergeSemantics algorithm should be updated to keep semantics nodes marked with explicitChildNodes as its own children. This allows for applications that are properly annotated/described semantically to remain as such without forcing developers to make any changes.
2. Remove the semantics examples in Switch/Checkbox/RadioListTile docs, since they will be rendered unnecessary once MergeSemantics no longer attempts to forcibly merge its children.
Repository: go
Issue: encoding/json: accept float starting with "." (".85") while unmarshaling json with ,string tag
Labels: NeedsDecision

### What version of Go are you using (`go version`)?
<pre>
❯ go version
go version go1.12.5 darwin/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="/Users/ashwin/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/ashwin/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.12.5/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.12.5/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/nl/_f7rxwqs2y730r18nk0shs240000gn/T/go-build739953451=/tmp/go-build -gno-record-gcc-switches -fno-common"
</pre></details>

### What did you do?

Tried unmarshaling json that contained float string starting with "."
The playground link below contains 3 examples
1. json unmarshal with ".85" -- fails
2. json unmarshal with "0.85" -- succeeds
3. strconv.ParseFloat ".85" -- succeeds

https://play.golang.org/p/q4OFvV6Asxt


### What did you expect to see?

I expect ".85" to be successfully converted to a float using unmarshal
".85" -> 0.85

### What did you see instead?
this error: `json: invalid use of ,string struct tag, trying to unmarshal ".85" into float64`
Repository: go
Issue: x/net/ipv4: wrong endianness in IP header on darwin-amd64
Labels: help wanted,OS-Darwin,NeedsInvestigation

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.11.5 darwin/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="/Users/rhuang/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/rhuang/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.11.5/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.11.5/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/xy/qpsgj2816g97b0ctzkq0ps_r0000gs/T/go-build097375093=/tmp/go-build -gno-record-gcc-switches -fno-common"
</pre></details>

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->

marshall IPv4 IP header with x/net/ipv4/header, but I got little-endian instead of big-endian.



### What did you expect to see?
Got big-endian IP header len.

### What did you see instead?

little-endian


Looking at By looking at the code https://github.com/golang/net/blob/master/ipv4/header.go#L71., for darwin, 32bit/64bit os should have a different conversion.
Darwin amd64 is little-endian, it should convert.
Repository: rust
Issue: rustdoc: private module appears when overriding glob re-export
Labels: T-rustdoc,A-visibility,C-bug

Consider this code in a crate's lib.rs:

```rust
mod m1 {
    pub mod m2 {
        pub struct Foo;
    }
}

pub use m1::*;

use crate::m1::m2;
```

The generated documentation will show the `m2` module at the crate root, though nothing will show up inside the `m2` module page. The `m2` module is private to outside crates, so I don't think it should be showing up at all.

## Meta

`rustc --version --verbose`:

rustc 1.36.0-nightly (7d5aa4332 2019-05-16)
binary: rustc
commit-hash: 7d5aa43325ad7629766b1183011f5bf5b2a1ea26
commit-date: 2019-05-16
host: x86_64-pc-windows-msvc
release: 1.36.0-nightly
LLVM version: 8.0
Repository: flutter
Issue: Add memory leak test
Labels: a: tests,team,engine,c: performance,a: existing-apps,perf: memory,P3,team-engine,triaged-engine

Make sure we don't get regressions on the embedding or in the engine. We manually tested and fixed issues for 1.12 to make sure the show screen, dismiss screen cycle doesn't cost any memory on a pre-warmed engine. Make sure it's locked it.

Examples: 

- https://github.com/flutter/flutter/issues/61558
- https://github.com/flutter/engine/pull/9288
- https://github.com/flutter/engine/pull/18657
- https://github.com/flutter/engine/pull/17646
- https://github.com/flutter/flutter/issues/45499
- https://github.com/flutter/flutter/issues/56482
- https://github.com/flutter/flutter/issues/65941
Repository: terminal
Issue: Code Cleanup - Member variables not initialized in GdiEngine's constructor
Labels: Product-Conhost,Issue-Bug,Area-Build

Minor Code cleanup

In src/renderer/gdi/state.cpp 
GdiEngine's constructor is not initializing all of it's member variables.

_isTrueTypeFont
_fontCodepage
_tmFontMetrics
_coordFontLast
_psInvalidData

In Debug only
_debugWindow
_debugContext

As far as I can tell, none of the above variables are used before being initialized (in the normal code path).  Most of these get set in UpdateFont and _CreateDebugWindow.  It might make sense to make a pass and initialize these in the header with default values. Some members are correctly being set to a default value in the constructor, but it might be better for maintainability to remove those and initialize them in the header also.
Repository: terminal
Issue: Callback function passed to EnumFontFamiliesExW uses wrong signature
Labels: Product-Conhost,Help Wanted,Issue-Bug,Area-CodeHealth

Example callback function used with `EnumFontFamiliesExW`:
```cpp
int CALLBACK FontEnumForV2Console(ENUMLOGFONT *pelf, NEWTEXTMETRIC *pntm, int nFontType, LPARAM lParam);
```

But `FONTENUMPROC` as expected by `EnumFontFamiliesExW` is defined as follows (SDK 10.0.18362.0):
```cpp
typedef int (CALLBACK* OLDFONTENUMPROCW)(CONST LOGFONTW *, CONST TEXTMETRICW *, DWORD, LPARAM);
```

In practice, the differing argument types are representation-compatible anyway, so it works fine, but it does require a cast on the function pointer. It was suggested in #871 to get this sorted out.

Affected files:
```none
>git grep FONTENUMPROC
src/propsheet/misc.cpp:    EnumFontFamiliesEx(hDC, &LogFont, (FONTENUMPROC)((ShouldAllowAllMonoTTFonts()) ? FontEnumForV2Console : FontEnum), (LPARAM)&fed, 0);
src/renderer/gdi/tool/main.cpp:    EnumFontFamiliesExW( hDC, &lf, (FONTENUMPROC)EnumFontFamiliesExProc, 0, 0 );
src/tools/fontlist/main.cpp:    EnumFontFamiliesExW(hdc.get(), &LogFont, (FONTENUMPROC)FontEnumForV2Console, (LPARAM)hdc.get(), 0);
```

BTW, `src/renderer/gdi/tool/main.cpp` is not included in any project in the solution, preventing it to be scanned by an IDE. Is that intentional?
Repository: flutter
Issue: Vertical `Dismissible` does not dismiss `SingleChildScrollView` (nor` ListView`)
Labels: framework,f: scrolling,customer: google,has reproducible steps,P2,found in release: 1.21,found in release: 2.2,workaround available,team-framework,triaged-framework

Internal: b/132630514

The following code snippet demonstrates that Dismissible cannot be used for implementing the common pattern of swipe downwards to dismiss screen (where the screen contains a scrollable). This pattern appears for example in the image viewer in Google Search App, in the directions screen of Google Maps and more. 

Expected behaviour: On dragging downwards, the list starts moving (not scrolling) downwards.
Observed behaviour: On dragging downwards, the list overscrolls (and cannot be dismissed)

    Dismissible(
          direction: DismissDirection.down,
          key: Key("dismissible"),
          child: SingleChildScrollView(
            child: Container(
              color: Colors.green,
              child: Column(
                children: [
                  Text("Example", style: TextStyle(fontSize: 50)),
                  Text("Example", style: TextStyle(fontSize: 50)),
                  Text("Example", style: TextStyle(fontSize: 50)),
                  Text("Example", style: TextStyle(fontSize: 50)),
                  Text("Example", style: TextStyle(fontSize: 50)),
                  Text("Example", style: TextStyle(fontSize: 50)),
                  Text("Example", style: TextStyle(fontSize: 50)),
                  Text("Example", style: TextStyle(fontSize: 50)),
                  Text("Example", style: TextStyle(fontSize: 50)),
                  Text("Example", style: TextStyle(fontSize: 50)),
                  Text("Example", style: TextStyle(fontSize: 50)),
                  Text("Example", style: TextStyle(fontSize: 50)),
                ],
              ),
            ),
          ),
        ),

--- This information is sufficient for reproducing the bug. Below we provide some further details. --

Variation 1: Changing the direction to horizontal, allows for the view to be dismissed horizontally.
Variation 2: Removing some items from the SingleChildScrollView allows for the view to be dismissed vertically.
Variation 3: Changing SingleChildScrollView with ListView does not solve the issue. 

Further investigation: It seems that a GestureDetector over SingleChildScrollView, even when using HitTestBehavior.opaque, will never get any vertical gesture event. For our prototype, we solved this issue using a stack with the scrollable and a gesture detector that decides whether to dismiss or to forward gestures to the scrollable. However, the code becomes much complicated.
Repository: go
Issue: cmd/go: ambiguous error message on ambiguous import
Labels: NeedsInvestigation,modules

### What version of Go are you using (`go version`)?
1.12

### Does this issue reproduce with the latest release?
yes


### What operating system and processor architecture are you using (`go env`)?
```
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/user/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/user/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"
GOMOD=""
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=/tmp/go-build116507160=/tmp/go-build -gno-record-gcc-switches"
```

### What did you do?
I deal with a problem of ambiguous module import when I try to import `github.com/spf13/viper@1.3.2` and `github.com/gin-gonic/gin@v1.4.0`

https://play.golang.org/p/NwzVwWsOjbO

### What did you expect to see?
@thepudds (thx to him for his support) has advised me to open a issue to have clearer diagnostic message or a simpler solution.

the proposed solution, that works for me, is:
` go get github.com/ugorji/go/codec@none`

https://groups.google.com/forum/#!topic/golang-nuts/0mJh8SkaomA
Repository: pytorch
Issue: [distribution] Support for various domain for AffineTransform
Labels: module: distributions,triaged

## 🚀 Feature
Currently, AffineTransform's domain and codomain are `real`. So transformed distribution with affine transform will return `real` support by default. It would be great if we allow several more domains such as `greater_than` or `interval`. cc @neerajprad who is also interested in this feature.

Related issue: currently, `transform_to(constraints.interval(a, b))`'s codomain is real; while it should be `constraints.interval(a, b)`.

## Motivation

This will be helpful so that users don't have to redefine `support` for such transformed distributions.

## Alternatives

A simple solution is to allow a `domain` arg in AffineTransform initialization. Then we can define `codomain` as a dependent property. This way, we can fix the above issue at `constraint_registry`  by using
```
def _transform_to_greater_than(constraint):
    return transforms.ComposeTransform([transforms.ExpTransform(),
        transforms.AffineTransform(constraint.lower_bound, 1,
                                  domain=constraint.positive)])
```
or
```
def _transform_to_interval(constraint):
    ...
    return transforms.ComposeTransform([transforms.SigmoidTransform(),
        transforms.AffineTransform(loc, scale,
                domain=constraint.unit_interval)])
```

cc @fritzo @neerajprad @alicanb @vishwakftw who are maintainers of distributions library
Repository: godot
Issue: Script gets shadow-removed when _init(arg) + tool
Labels: bug,topic:gdscript,confirmed

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
3.1.1 official
<!-- Specify commit hash if non-official. -->


**OS/device including version:**
windows 10
<!-- Specify GPU model and drivers if graphics-related. -->


**Issue description:**
Script disappears from scene, when the script is a tool-script and there is a non-standard _init() method in the script.  When i delete one or the other ("tool" or "_init(arg)" ) the script reappears.
When being used with the standard "_init()" it works as intended and the script doesnt disappear from the scene.

When i run the scene with the script not showing up in the scene-tree, the script wont exist (not attached to the node it actually should be)

I was fighting with this bug for about an hour, working with signals, wondering if i did my signals wrong, but actually it was this culprit, that my scripts just didnt exist while i ran the scene.

My expectation would be, if this is a mistake from my side, to get an error-message to show or it being fixed, if its a bug.


<!-- What happened, and what was expected. -->


**Steps to reproduce:**


**Minimal reproduction project:**

You can try it out, by opening the scene "Control.tscn" and opening the script "script_with_error.gd" by removing or adding the "tool" or the "_init(arg)".

[reproduction_project.zip](https://github.com/godotengine/godot/files/5066152/script.%2B.tool.shadow-remove.zip)

<!-- Recommended as it greatly speeds up debugging. Drag and drop a zip archive to upload it. -->

Edit: Replaced the MRP with a project created in 3.2.3.rc3
Repository: create-react-app
Issue: react-error-overlay fails to parse typescript errors
Labels: issue: bug

### Is this a bug report?
yes

### Which terms did you search for in User Guide?
react-error-overlay

### Environment

<details>
  <summary>Environment</summary>

  System:
    OS: macOS 10.14.5
    CPU: (4) x64 Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
  Binaries:
    Node: 12.2.0 - /usr/local/bin/node
    Yarn: 1.13.0 - /usr/local/bin/yarn
    npm: 6.9.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 74.0.3729.157
    Firefox: 66.0.5
    Safari: 12.1.1
  npmPackages:
    react: ^16.8.6 => 16.8.6 
    react-dom: ^16.8.6 => 16.8.6 
    react-scripts: 3.0.1 => 3.0.1 
  npmGlobalPackages:
    create-react-app: 3.0.0
</details>

### Steps to Reproduce

In a create-react-app typescript project:

1. Start the development server 
2. Make a typescript error in any file (```let a: string = 0``` for example).
3. The error overlay displays the error, however clicking on the exception does not navigate to the file in the text editor as with other webpack errors.

### Expected Behavior

Clicking on the error overlay navigates to the file in a text editor.

### Actual Behavior

The error overlay isn't clickable.

### Details

React-error-overlay tries parsing the exception by looking for a filepath in the error message. This is handled in [parseCompileError.js](https://github.com/facebook/create-react-app/blob/4704382558fe6f0d7564c72ce65d45e441a3ff61/packages/react-error-overlay/src/utils/parseCompileError.js), where the filepath regex matches only relative paths:

```js
const filePathRegex = /^\.(\/[^/\n ]+)+\.[^/\n ]+$/;
```

whereas typescript errors use absolute paths. As discussed in https://github.com/facebook/create-react-app/pull/6502#discussion_r259686344 making the paths relative has some drawbacks so it would be best to keep them absolute.
Also TS error locations are specified like `(line,colon)` so we would need to add that format to the lineNumberRegexes array.

I can submit a PR for this if that's okay.
Repository: TypeScript
Issue: const module = {}; export = module
Labels: Bug

<!-- 🚨 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.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.4.0-dev.201xxxxx

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

**Code**

```ts
const module = {

}

export = module
```

**Expected behavior:**

```js
const module_1 = {};
module.exports = module_1;
```

**Actual behavior:**

```js
const module = {};
module.exports = module;
```

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: PowerToys
Issue: Power Plan Switching (automatic too)
Labels: Idea-New PowerToy,Product-Power management

I use Full Throttle Override to force my CPU to a certain power plan automatically when a certain application is run (music production DAW in my case). It's the only app of its kind out there, and isn't under further development. I think this would be a perfect case for a Power Toy. Thanks!
Repository: go
Issue: cmd/go: building a test binary with "go test -c" probably shouldn't run vet
Labels: NeedsDecision

While working on some slow full emulation qemu VMs, I noticed `go test -c` was much slower than expected. Looking at top, I saw `vet` eating CPU.

It seems surprising that we default to running vet on a flag that's described as:

> Compile the test binary to pkg.test but do not run it

Any vet output would look like a test failed and thus ran, even if it's not technically a test.

I vote we turn it off for `-c`. @bcmills, @jayconrod, @ianlancetaylor, @rsc?

In any case, it's not critical. Now I know to always use `-vet=off` with `-c`:

```
gopher@buildlet:~/go/src/io$ time ../../bin/go test -c

real    0m28.740s
user    0m14.184s
sys     0m9.208s

gopher@buildlet:~/go/src/io$ time ../../bin/go test -c -vet=off

real    0m19.385s
user    0m9.772s
sys     0m6.488s

gopher@buildlet:~/go/src/io$ time ../../bin/go test -c 

real    0m28.651s
user    0m16.804s
sys     0m10.260s

gopher@buildlet:~/go/src/io$ time ../../bin/go test -c -vet=off

real    0m18.051s
user    0m10.504s
sys     0m6.692s
```

Marking for Go 1.14, unless this is a recent regression. I didn't check.