sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: React and defaultProps cant pass correct props to inner function
Labels: Suggestion,Needs Proposal

<!-- BUGS: Please use this template. -->
<!-- QUESTIONS: This is not a general support forum! Ask Qs at http://stackoverflow.com/questions/tagged/typescript -->
<!-- SUGGESTIONS: See https://github.com/Microsoft/TypeScript-wiki/blob/master/Writing-Good-Design-Proposals.md -->

**TypeScript Version:**  2.4.0

**Code**

```ts
import * as React from 'react';
interface CircleProps {
    percent?: number
}
export default class Circle extends React.Component<CircleProps> {
    public static defaultProps: Partial<CircleProps> = {
        percent: 100
    }

    calculateDashArray(percent: number): string {
        return `${percent}`
    }

    render() {
        const strokeDasharray = this.calculateDashArray(this.props.percent)
        return (
            <div>{strokeDasharray}</div>
        )
    }
}

```

**Expected behavior:**
`this.calculateDashArray` should correct accept value of defalutProps
**Actual behavior:**
`Argument of type 'number | undefined' is not assignable to parameter of type 'number'.
  Type 'undefined' is not assignable to type 'number'.`
Repository: go
Issue: cmd/compile: optimize away some MOVQconverts
Labels: Performance,compiler/runtime

We have to keep uintptrs and unsafe.Pointers separate, to get accurate stackmaps for the compiler. However, in some cases, this generates unnecessary register moves.

Here's the example from the runtime I'm looking at. `mapaccess1_fast32` currently ends:

```go
	for {
		for i, k := uintptr(0), b.keys(); i < bucketCnt; i, k = i+1, add(k, 4) {
			if *(*uint32)(k) == key && b.tophash[i] != empty {
				return add(unsafe.Pointer(b), dataOffset+bucketCnt*4+i*uintptr(t.valuesize))
			}
		}
		b = b.overflow(t)
		if b == nil {
			return unsafe.Pointer(&zeroVal[0])
		}
	}
```

This has an unnecessary nil check of b in the inner loop when evaluating `b.tophash`, so I'd like to change the outer loop structure to remove it:

```go
	for ; b != nil; b = b.overflow(t) {
		for i, k := uintptr(0), b.keys(); i < bucketCnt; i, k = i+1, add(k, 4) {
			if *(*uint32)(k) == key && b.tophash[i] != empty {
				return add(unsafe.Pointer(b), dataOffset+bucketCnt*4+i*uintptr(t.valuesize))
			}
		}
	}
	return unsafe.Pointer(&zeroVal[0])
```

With this new structure, the nil check is gone, but we now have an extra register-register move, instruction 0x009f:

```
	0x0096 00150 (hashmap_fast.go:42)	MOVQ	"".t+40(SP), CX
	0x009b 00155 (hashmap_fast.go:42)	MOVWLZX	84(CX), DX
	0x009f 00159 (hashmap_fast.go:42)	MOVQ	AX, BX
	0x00a2 00162 (hashmap_fast.go:42)	LEAQ	-8(BX)(DX*1), DX
	0x00a7 00167 (hashmap_fast.go:42)	TESTB	AL, (CX)
	0x00a9 00169 (hashmap_fast.go:42)	MOVQ	(DX), AX
	0x00ac 00172 (hashmap_fast.go:42)	TESTQ	AX, AX
	0x00af 00175 (hashmap_fast.go:42)	JEQ	185
```

The register-register move is there because calculating `b.overflow` involves a uintptr/unsafe.Pointer conversion, which gets translated into a MOVQconvert; regalloc allocates a register for the converted value. However, the register move is pointless; the destination register (BX) is used in an LEAQ instruction and is dead thereafter.

In general, it seems that we should be able to rewrite away some MOVQconverts when they are used once, immediately, as part of some pointer math, which is the typical usage. The hard part is making sure that the rewrite rules are safe.

This should help codegen for the runtime, which does lots of pointer arithmetic.

cc @randall77
Repository: angular
Issue: NgFor with animations displays incorrectly if NgFor array elements are reordered in-place
Labels: type: bug/fix,area: animations,hotlist: components team,freq3: high,P2,canonical

<!--
PLEASE HELP US PROCESS GITHUB ISSUES FASTER BY PROVIDING THE FOLLOWING INFORMATION.

ISSUES MISSING IMPORTANT INFORMATION MAY BE CLOSED WITHOUT INVESTIGATION.
-->

## I'm submitting a...
<!-- Check one of the following options with "x" -->
<pre><code>
[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  <!-- Please search GitHub for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
</code></pre>

## Current behavior
<!-- Describe how the issue manifests. -->
When you apply an a `void <=> *` animation to elements in an `NgFor` then rearrange the elements in the array, the animations do not display correctly. In the plunkr example below, elements are positioned on top of each other once the array is rearranged even though they initially display correctly.


## Expected behavior
<!-- Describe what the desired behavior would be. -->
The elements should animate correctly.


## Minimal reproduction of the problem with instructions
<!--
For bug reports please provide the *STEPS TO REPRODUCE* and if possible a *MINIMAL DEMO* of the problem via
https://plnkr.co or similar (you can use this template as a starting point: http://plnkr.co/edit/tpl:AvJOMERrnz94ekVua0u5).
-->
See this plunkr: http://plnkr.co/edit/qGFuVngxgIcEojZaFZPd?p=preview

Note that when the application first runs, the animations display correctly. Clicking "Rearrange" will cause the elements in the `NgFor`-ed array to be reordered using `Array.splice` but without creating a new array object. The view updates and the animations cause the elements to collapse into each other. The list displays correctly when the animation is removed.

## What is the motivation / use case for changing the behavior?
<!-- Describe the motivation or the concrete use case. -->
I want the animation to display properly in a similar use case in my app.

## Environment

<pre><code>
Angular version: 4.3.5
<!-- Check whether this is still an issue in the most recent Angular version -->

Browser:
- [x] Chrome (desktop) version XX
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
 
For Tooling issues:
- Node version: XX  <!-- run `node --version` -->
- Platform:  <!-- Mac, Linux, Windows -->

Others:
<!-- Anything else relevant?  Operating system version, IDE, package manager, HTTP server, ... -->
</code></pre>
Repository: flutter
Issue: Allow release mode builds to run on simulators
Labels: c: new feature,tool,engine,customer: crowd,P3,customer: castaway,team-engine,triaged-engine

Current documentation (https://github.com/flutter/flutter/wiki/Flutter%27s-modes) states that Flutter release mode builds cannot be run on the Simulator. For many applications, the iOS Simulators are sufficiently high fidelity to do 99% of development work without going through the additional friction of deploying to devices regularly. It's unfortunate that, unlike in native application development, you can't get an accurate understanding of your release mode behaviors with Flutter.
Repository: flutter
Issue: FocusNode and FocusScopeNode should take debug labels.
Labels: framework,a: debugging,c: proposal,P3,team-framework,triaged-framework

Currently printing the focus tree results in something like this:

```
[00059.830] 10004.10040> FocusScopeNode#5f96b
[00059.830] 10004.10040>  child 1: FocusScopeNode#6de7b
[00059.830] 10004.10040>      focus: FocusNode#96399
[00059.830] 10004.10040> 
```

It would better to have names for each of these.
Repository: bitcoin
Issue: bumpfee behavior with "Subtract fee from amount"
Labels: RPC/REST/ZMQ

When using the bumpfee command on a tx that was sent using "Subtract fee from amount", the current response is this error. "Transaction does not have a change output (code -1)". Since "Subtract fee from amount" was specified, the expected behavior would be to subtract the fee from the sent amount which would not require a change output.
Repository: puppeteer
Issue: Ability to pause all animations completely
Labels: feature,chromium

I need to be able to take deterministic screenshots and when animations are running you'll get a different frame from an animation each time.

There does appear to be some control of animations in the devtools protocol here: https://chromedevtools.github.io/devtools-protocol/tot/Animation/

I've tried these without success:

```javascript
await page._client.send('Animation.setPlaybackRate', { playbackRate: 0.0 });
```

```javascript
await page._client.send('Animation.disable');
```

There's also an official extension that disables animations: https://chrome.google.com/webstore/detail/animation-policy/ncigbofjfbodhkaffojakplpmnleeoee?hl=en

Looking at the source code of that extension it calls this:

```javascript
chrome.accessibilityFeatures.animationPolicy.set({'value': setting}, function (callback) {});
```

Where the ideal value would be 'none'. (https://codereview.chromium.org/785723002/diff/20001/chrome/common/extensions/api/accessibility_features.json#newcode48chrome/common/extensions/api/accessibility_features.json:48)

Related: #453
Repository: puppeteer
Issue: Detect sound
Labels: feature,upstream,chromium

I would like to detect if a page is playing some sound. Is there a way to do that?
Repository: TypeScript
Issue: warning on emitDecoratorMetadata for interface in esnext
Labels: Bug,Domain: Decorators

**TypeScript Version:**  2.4.2

**Code**
(using Angular 4) 

```ts
// other-file.ts
export interface MyInterface { a: string }

// my-class.ts
import { Input } from '@angular/core'
import { MyInterface } from './otherFile'

class MyClass {
  @Input() myi: MyInterface;
}
```

**tsconfig.json**
```
{
  "compilerOptions": {
    ...
    "target": "es2017",
    "module": "esnext",
    "emitDecoratorMetadata": true,
    ...
  }
}
```

**Expected behavior:**
Working, no errors. I'd expect no type information emitted for interfaces, as they're only a Typescript compile construct.

**Actual behavior:**
Although this isn't a bug per se, TypeScript generates a decorator for type information, referencing MyInterface from `otherFile`. Only...this interface doesn't exist runtime. So bundlers (webpack in my case) produce a warning for this (something like `otherFile doesn't export MyInterface`). You can workaround this by creating a local type in `my-class.ts`. Or just accept warnings.
Repository: TypeScript
Issue: Suggestion: Change `Diagnostic.file` to be `SourceFileLike` instead of `SourceFile`.
Labels: Suggestion,Help Wanted,API

`Diagnostic.file` is of type `SourceFile` which forces plugins to cast a non-`SourceFile` to a `SourceFile` to report diagnostic messages and guess which parts of `SourceFile` are not used by `tsserver`.

Consider changing `file` to be something like `SourceFileLIke` or `SourceMapSource` that specifies the exact requirements that must be supplied by plugins for this field.
Repository: go
Issue: net/http: (*Transport).getConn traces through stale contexts
Labels: Thinking,help wanted,NeedsFix

`(*http.Transport).getConn` currently starts a `dialConn` call in a background goroutine:
https://github.com/golang/go/blob/0b0cc4154e1defed07e73ca1304b9a68c7134577/src/net/http/transport.go#L942-L945

That records traces to the provided `Context` and eventually invokes `t.DialContext` with it:
https://github.com/golang/go/blob/0b0cc4154e1defed07e73ca1304b9a68c7134577/src/net/http/transport.go#L1029
https://github.com/golang/go/blob/0b0cc4154e1defed07e73ca1304b9a68c7134577/src/net/http/transport.go#L1060

This is pretty much a textbook illustration of the problem described in #19643 (Context API for continuing work). If `(*Transport).getConn` returns early (due to cancellation or to availability of an idle connection), the caller may have already written out the corresponding traces, and `dialConn` (and/or the user-provided `DialContext` callback) will unexpectedly access a `Context` that the caller believes to be unreachable.

`httptrace.ClientTrace` says, "Functions may be called concurrently from different goroutines and some may be called after the request has completed or failed." However, that is not true of `Context` instances in general: if the `http` package wants to save a trace after a call has returned, it should call `Value` ahead of time and save only the `ClientTrace` pointer. If `dialConn` calls a user-provided `DialContext` function, then `getConn` should cancel the `Context` passed to it and wait for `DialContext` to return before itself returning.

----

See also #20617 (Context race in `http.Transport`).
Repository: rust
Issue: Check the well-formed-ness of type aliases.
Labels: A-type-system,C-enhancement,T-compiler,T-types

Currently, these compile:
```rust
struct Foo<T: Copy>(T);
type X = Foo<String>;
type Y = <() as Iterator>::Item;
```

Using them does produce an error *at the use site*, but not in the definition.
Repository: go
Issue: net: DialContext can use a stale context via happy eyeballs
Labels: NeedsInvestigation

When happy eyeballs is enabled, DialContext makes parallel calls to dialSingle via dialParallel:
https://github.com/golang/go/blob/424b0654f8e6c72f69e096f69009096de16e30fa/src/net/dial.go#L415

Each dialSingle call may call ctx.Value, such as here:
https://github.com/golang/go/blob/424b0654f8e6c72f69e096f69009096de16e30fa/src/net/dial.go#L533

dialParallel doesn't wait for all dialSingle calls to complete. This means, in theory, dialSingle can call ctx.Value on a ctx that has gone out of scope. This is effectively the same problem as #21597.

/cc @bcmills
Repository: go
Issue: cmd/go: compilation order of fortran files is significant
Labels: NeedsInvestigation

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?
go version go1.9 linux/amd64

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="{....}"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build881373539=/tmp/go-build -gno-record-gcc-switches"
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"


### What did you do?

I would like to build a go package that includes fortran source code files, similar to https://github.com/golang/go/tree/master/misc/cgo/fortran. The important difference from this example is that the package that I would like to compile includes fortran modules, for example:

```
package.go // depends on code in a_subroutine.f90
a_subroutine.f90 // depends on code in b_module.f90
b_module.90 
```
I would expect to be able to compile this with ```go build```.

### What did you expect to see?
successful compilation.

### What did you see instead?
```
# {...}
<command-line>:12:6:

Fatal Error: Can't open module file ‘b_module.mod’ for reading at (1): No such file or directory
```

I think the problem might be that [the order that fortran files are fed into the compiler is significant](http://pages.mtu.edu/~shene/COURSES/cs201/NOTES/chap06/mod-files.html), and the go tool does not appear to account for this.

### Potential fixes for this problem:
1. renaming all of the fortran files in the directory so that their alphabetical order is also their required compilation order. While this (usually?) works, it appears to depend on undocumented behavior.
2. resolving the fortran dependencies and figuring out the file order within the go tool. This seems unlikely to happen.
3. Allowing the specification of files to be compiled (and their order) a la #12953.
4. Others?
Repository: youtube-dl
Issue: [Youtube] support for video watched percentage
Labels: request

## Please follow the guide below

- You will be asked some questions and requested to provide some information, please read them **carefully** and answer honestly
- Put an `x` into all the boxes [ ] relevant to your *issue* (like this: `[x]`)
- Use the *Preview* tab to see what your issue will actually look like

---

### Make sure you are using the *latest* version: run `youtube-dl --version` and ensure your version is *2017.08.23*. If it's not, read [this FAQ entry](https://github.com/rg3/youtube-dl/blob/master/README.md#how-do-i-update-youtube-dl) and update. Issues with outdated version will be rejected.
- [x] I've **verified** and **I assure** that I'm running youtube-dl **2017.08.23**

### Before submitting an *issue* make sure you have:
- [x] At least skimmed through the [README](https://github.com/rg3/youtube-dl/blob/master/README.md), **most notably** the [FAQ](https://github.com/rg3/youtube-dl#faq) and [BUGS](https://github.com/rg3/youtube-dl#bugs) sections
- [x] [Searched](https://github.com/rg3/youtube-dl/search?type=Issues) the bugtracker for similar issues including closed ones

### What is the purpose of your *issue*?
- [ ] Bug report (encountered problems with youtube-dl)
- [ ] Site support request (request for adding support for a new site)
- [x] Feature request (request for a new functionality)
- [ ] Question
- [ ] Other

---

### Description of your *issue*, suggested solution and other information
Partially watched youtube videos have a corresponding partially filled progress bar on the thumbnail, in the youtube UI. Currently the mark-watched does not have proper support for this and you get a very slightly filled progress bar.

It would be good to have a way to mark it as 100% watched progress, either with the default behavior of --mark-watched or through some new --mark-completely-watched flag.
Repository: puppeteer
Issue: How do I get rid of popup for chromium certificates selection, can I set it programmatically ?
Labels: feature,chromium

Is there another way without disabling the popup via puppeteer launch ? I tried dialog stuff but it seems not the way.

<img width="1116" alt="screen shot 2017-08-25 at 5 20 42 pm" src="https://user-images.githubusercontent.com/642874/29708177-5db7c8a4-89ba-11e7-8827-917c0d09fa4d.png">
Repository: go
Issue: install: Windows: MSI Upgrade should default to previous install folder, not insist on C:\Go\
Labels: help wanted,OS-Windows,NeedsFix

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?

1.9 release

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

Windows

### What did you do?

Had Go 1.9rc2 installed in C:\Program Files\Go\
Wizard asked if I wanted to uninstall old during upgrade, I chose YES
Wizard asks where I want to install new version, defaults to C:\Go\

### What did you expect to see?

I expected it to suggest installation in the previously selected folder, as this is an upgrade, and everything in environment is set for that path.

### What did you see instead?

It insists on suggesting C:\Go\ which fills up my root folder with more directories. I don't get it why you don't use Program Files as everything else on Windows. This is not Linux (and you would never suggest to install in /go/ on a Linux system anyway)
Repository: pytorch
Issue: DataLoader converts cuda FloatTensor into cpu DoubleTensor when shape is (n,)
Labels: needs reproduction,module: dataloader,triaged

In version 0.2.0, it appears that the DataLoader will convert a cuda.FloatTensor into a DoubleTensor when the shape is (n,)

```python
X = torch.rand(64,8).cuda()
y = torch.rand(64).cuda()
dataset = TensorDataset(X,y)
loader = DataLoader(dataset)
next((y for (X,y) in loader))
```
```
0.1309
[torch.DoubleTensor of size 1x1 (GPU 0)]
```

Using `unsqueeze` to convert the (n,) tensor to (n,1) fixes the issue.
```python
X = torch.rand(64,8).cuda()
y = torch.rand(64).cuda().unsqueeze(1)
dataset = TensorDataset(X,y)
loader = DataLoader(dataset)
next((y for (X,y) in loader))
```
```
0.8397
[torch.cuda.FloatTensor of size 1x1 (GPU 0)]
```
The workaround is easy enough, but I'm assuming this is a bug with either TensorDataset or DataLoader.

EDIT:
This seems to be independent of CUDA, as it still converts the FloatTensor to DoubleTensor in cpu mode.
```python
X = torch.rand(64,8)
y = torch.rand(64)
dataset = TensorDataset(X,y)
loader = DataLoader(dataset)
next((y for (X,y) in loader))
```
```
 0.4935
[torch.DoubleTensor of size 1]
```
```python
X = torch.rand(64,8)
y = torch.rand(64).unsqueeze(1)
dataset = TensorDataset(X,y)
loader = DataLoader(dataset)
next((y for (X,y) in loader))
```
```
 0.9419
[torch.FloatTensor of size 1x1]
```
Repository: opencv
Issue: cuda::BackgroundSubtractor::apply only allows CV_8UCx images while CPU version allows CV_16UCx images
Labels: feature,priority: low,category: gpu/cuda (contrib),RFC

##### System information (version)
- OpenCV => 3.2
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2013

##### Detailed description

Code that uses the openCV background subtractor on the CPU can pass in a 16 bit image (very useful for depth images where char is not enough resolution) but converting that function over to the cuda implemetation throws the assertion:

> OpenCV Error: Assertion failed (frameType == CV_8UC1 || frameType == CV_8UC3 || frameType == CV_8UC4) in `anonymous-namespace'::MOG2Impl::initialize, file C:\OpenCV32\source\modules\cudabgsegm\src\mog2.cpp, line 223

This same code runs fine in the CPU implementation of BackgroundSubtractorMOG2.

##### Steps to reproduce

```.cpp
        cv::Mat newBackgroundImage = cv::Mat(1024, 1024, CV_16UC1);
        // fill new background image with unsigned short data

	cv::cuda::GpuMat fgMask;
        
	BackgroundModel = cv::cuda::createBackgroundSubtractorMOG2();
	// first-run initialization
	if (fgMask.rows == 0 || fgMask.cols == 0)
	{
		fgMask = cv::cuda::GpuMat(newBackgroundImage.rows, newBackgroundImage.cols, CV_8UC1);
	}
	cv::cuda::GpuMat input = cv::cuda::GpuMat(newBackgroundImage.rows, newBackgroundImage.cols, newBackgroundImage.type());
	input.upload(newBackgroundImage);
	BackgroundModel->apply(newBackgroundImage, fgMask, -1);
```
Running the above code will throw the error.  Running the below code will work without error

```.cpp
        cv::Mat newBackgroundImage = cv::Mat(1024, 1024, CV_16UC1);
        // fill new background image with unsigned short data
       cv::Mat  fgMask;
	// first-run initialization
	if (fgMask.rows == 0 || fgMask.cols == 0)
	{
		fgMask = Mat(inputImage.rows, inputImage.cols, CV_8UC1);
	}
	BackgroundModel->apply(inputImage, fgMask, -1);
```
Repository: rust
Issue: Object safety "method references the `Self` type" check does not normalize.
Labels: A-type-system,T-compiler,C-bug,T-types,A-trait-objects

Example (using an associated type that matches a blanket `impl`):
```rust
trait Foo {
    type X;
}

impl<T: ?Sized> Foo for T {
    type X = ();
}

trait Bar {
    // Note how this is allowed without a bound.
    fn foo(&self) -> <Self as Foo>::X;
}

// error: the trait `Bar` cannot be made into an object
fn foo(_: Box<dyn Bar>) {}

fn main() {}
```