sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: incr.comp.: x.py --incremental can cause too big cache directories
Labels: C-enhancement,T-compiler,A-incr-comp

In particular, sometimes there are two cache subdirectories for a given crate in `stage0-incremental`, e.g. two `rustc_trans-xxxxxxx` directories. They have different crate disambiguators (otherwise there'd only be one directory). The disambiguator is set by the build system, either `cargo` or `x.py`. It's not clear yet whether this is a problem in `rustc` (somehow handling disambiguators or directory names wrongly) or `cargo` or `x.py`.

Note that it can be normal to have multiple directories for crates with the same name but different disambiguators, e.g. if there are two different versions of the same crate in the crate graph or if there is a library and an executable with the same name (as is the case with "rustc").
Repository: react
Issue: React-test-renderer: support for portal
Labels: Type: Feature Request,Component: Test Renderer,React Core Team

**Do you want to request a *feature* or report a *bug*?**

Report a bug

**What is the current behavior?**

This test

```javascript
import React from 'react';
import { createPortal } from 'react-dom';
import renderer from 'react-test-renderer';

const Drop = () => (
  createPortal(
    <div>hello</div>,
    this.dropContainer
  )
);

test('Drop renders', () => {
  const component = renderer.create(
    <div>
      <input />
      <Drop />
    </div>
  );
  const tree = component.toJSON();
  expect(tree).toMatchSnapshot();
});
```

fails with

> Invariant Violation: Drop(...): Nothing was returned from render. This usually means a return statement is missing. Or, to render nothing, return null.

This test passes if I wrap createPortal in a container.

```javascript
<div>
  {createPortal(
    <div>hello</div>,
    this.dropContainer
  )}
</div>
```

**What is the expected behavior?**

The code without the parent container works fine in the browser. So it seems that I'm adding the  parent `div` just for the test to pass. I believe `react-test-renderer` should support empty returns?

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**

Lastest
Repository: youtube-dl
Issue: [facebook] Support Instagram embedded videos
Labels: request

Example:

$  youtube-dl -v "https://www.facebook.com/BlueManGroupFans/posts/1747439181956701"   [debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-v', 'https://www.facebook.com/BlueManGroupFans/posts/1747439181956701']
[debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2017.11.15
[debug] Python version 3.4.2 - Linux-3.16.0-4-amd64-x86_64-with-debian-8.9
[debug] exe versions: ffmpeg 3.2.5-1, ffprobe 3.2.5-1, rtmpdump 2.4
[debug] Proxy map: {}
[facebook] 1747439181956701: Downloading webpage
ERROR: Unable to extract video ids; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
  File "/home/ant/bin/youtube-dl/youtube_dl/YoutubeDL.py", line 784, in extract_info
    ie_result = ie.extract(url)
  File "/home/ant/bin/youtube-dl/youtube_dl/extractor/common.py", line 437, in extract
    ie_result = self._real_extract(url)
  File "/home/ant/bin/youtube-dl/youtube_dl/extractor/facebook.py", line 415, in _real_extract
    webpage, 'video ids', group='ids'),
  File "/home/ant/bin/youtube-dl/youtube_dl/extractor/common.py", line 800, in _search_regex
    raise RegexNotFoundError('Unable to extract %s' % _name)
youtube_dl.utils.RegexNotFoundError: Unable to extract video ids; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.

Thank you in advance. :)
Repository: rust
Issue: Spurious "broken pipe" error messages, when used in typical UNIX shell pipelines
Labels: O-linux,O-macos,T-libs-api,C-bug

~~~~
$ cat yes.rs 
fn main() { loop { println!("y"); } }
$ rustc yes.rs && ./yes | head -n1
y
thread 'main' panicked at 'failed printing to stdout: Broken pipe (os error 32)', src/libstd/io/stdio.rs:692:8
note: Run with `RUST_BACKTRACE=1` for a backtrace.
$ yes | head -n1
y
~~~~

This was originally filed [here](https://github.com/sfackler/cargo-tree/issues/25) but @sfackler determined the cause:

> This is due to `println!` panicking on errors: https://github.com/rust-lang/rust/blob/f1ea23e2cc72cafad1dc25a06c09ec2de8e323eb/src/libstd/io/stdio.rs#L671.
> 
> C-based programs typically just get killed off with a SIGPIPE, but Rust ignores that signal.

Note that to see the backtrace, the data being piped has to be large enough to overflow the kernel pipe buffer.
Repository: go
Issue: proposal: encoding/json: add access to the underlying data causing UnmarshalTypeError
Labels: Proposal,Proposal-Hold

Currently one has to maintain a copy of the data being decoded by `json`.`Decoder` to retrieve the underlying data yielding an `UnmarshalTypeError` when decoding a `json` stream.

Making the data in `decodeState`.`data` directly accessible in the returned error:

```go
type UnmarshalTypeError struct {
    …
    Data    []byte
}
```

would make it easy to enable improved diagnostics for faulty inputs. 

(Somewhat related to #8254 and #9693 which are also about error diagnostics in `encoding/json`.)
Repository: react
Issue: Reword "unknown property" warning to be less obnoxious
Labels: Type: Enhancement,Component: DOM,React Core Team

I thought before it might cause knee jerk reactions, and it does in practice: https://twitter.com/freeformflo/status/928454078903894016

I think we should change the phrasing to a more neutral one. Potentially explaining *why* we prefer camel case.
Repository: opencv
Issue: UMat memory leak on Intel GPUs when using multiple threads
Labels: duplicate,RFC

##### System information (version)

- OpenCV => 3.3.1
- Operating System / Platform => Windows 10 64 Bit
- Compiler => Visual Studio 2013

##### Detailed description

Using UMat with OpenCL on Intel videocards in multiple host threads causes GPU memory leak.

##### Steps to reproduce

1. Create function that: loads image into `cv::Mat`, copies it to `cv::UMat` using `copyTo` method, runs some OpenCL-related function like CascadeClassifier's `detectMultiScale` or `cv::equalizeHist`, and returns.
2. Create loop: create thread, run function from 1 in this thread, join thread.
3. Watch GPU memory increasing indefinitely.

![intel_gpu_leak](https://user-images.githubusercontent.com/534699/32901516-09481228-cb01-11e7-93e7-725f5ed2aa9a.png)

##### Additional notes

1. If not using Intel GPU (tested on various NVidia GPUs), there's no memory leak.
2. If using OpenCL from fixed number of threads (for example, in fixed-size threadpool), there's no memory leak.
3. Even if I release UMat's memory using `release()` method, memory will leak.
Repository: angular
Issue: i18n: document how to lazy load locale data on bootstrap of application
Labels: feature,area: i18n,P3,feature: under consideration

<!--
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)
[ ] Bug report  <!-- Please search GitHub for a similar issue or PR before submitting -->
[ ] Feature request
[x ] 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. -->
Currently the documentation only states you should import the locale data you need for an app

## Expected behavior
<!-- Describe what the desired behavior would be. -->
A typical enterprise app supports multiple cultures and may not know the culture until run time.  An example of how to import the correct locale data at run time would be helpful.

## 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).
-->

## What is the motivation / use case for changing the behavior?
<!-- Describe the motivation or the concrete use case. -->
This was discussed as part of #20193 

## Environment

<pre><code>
Angular version: X.Y.Z
<!-- Check whether this is still an issue in the most recent Angular version -->

Browser:
- [ ] 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: TypeScript
Issue: Support typedef inheritance with JSDoc
Labels: Suggestion,In Discussion,Domain: JSDoc

**TypeScript Version:**  2.7.0-dev.20171116

**Code**

```js
/**
 * @typedef {Object} Base
 * @property {String} baseProp
 */

/**
 * @typedef {Base} Child
 * @property {String} childProp
 */

/** @type {Child} */
const child = { baseProp: '' };
```

**Expected behavior:** Error. `child` is missing the `childProp` property.

**Actual behavior:** No error. The `Child` type is identical to the `Base` type and only requires a `baseProp` property. The `childProp` property definition is completely ignored.

Or maybe there's another way to do the equivalent of `interface Child extends Base` here?
Repository: rust
Issue: Trigger JIT debuggers with panic=unwind
Labels: O-windows,C-enhancement,T-compiler,WG-debugging

Currently we only trigger JIT debuggers on Windows if we compile programs with panic=abort.
Repository: rust
Issue: Do not unwind on Windows with panic=abort
Labels: O-windows,C-enhancement,T-compiler

Currently we use the `ud2` instruction to abort the process. This unwinds the stack which we want to avoid. We also need to ensure that the abort mechanism triggers JIT debuggers (see https://github.com/rust-lang/rust/issues/46056).
Repository: rust
Issue: incr.comp.: Make sure `cargo check` is compatible with incremental compilation.
Labels: C-enhancement,E-needs-test,T-compiler,A-incr-comp,T-cargo,WG-incr-comp

So far incremental compilation did not bring any benefit for `cargo check` because incremental compilation only cached post-trans artifacts and the whole point of `cargo check` is to exit from compilation before the costly trans and LLVM parts. 

With https://github.com/rust-lang/rust/pull/46004 this has changed and we'll keep adding more and more things to this pre-trans cache. As a consequence we should make sure that `cargo check` works in conjunction with `CARGO_INCREMENTAL=1`. It already might but we've never tested it and have no regression tests.

cc @nikomatsakis @rust-lang/cargo
Repository: vue
Issue: Quadratic memory usage
Labels: improvement

### Version
2.5.4

### Reproduction link
[https://codepen.io/anon/pen/KyyxKB?editors=1010](https://codepen.io/anon/pen/KyyxKB?editors=1010)

### Steps to reproduce
1. Open browser devtools
2. Launch reproduction with different MAX variable (100, 200, 500, 1000, 1500, 2000, 4000)
3. Note that memory usage growth quadratically with the MAX variable, while number of computed properties and their implied dependencies in the program is proportional to the MAX variable.

### What is expected?
Expected linear (i.e. proportional) growth of memory consumption with growth of MAX variable

### What is actually happening?
All `data_X` observables have all `computed_X` computed values as their subscribers, so total number of subscriptions growth quadratically.

---
It's quite hard to write a code that would really affect users with the bug, but anyway it feels like a flaw in reactive system design.

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: rust
Issue: Type analysis on branches is inconsistent depending on whether an explicit return is used
Labels: C-enhancement,T-compiler,A-inference,S-has-mcve

I would expect the following two snippets of code to behave the same:

```rust
extern crate futures;
use futures::future::{self, Future};

fn main() {
    println!("{}", foo().wait().unwrap());
}

fn foo() -> Box<Future<Item=String, Error=String>> {
    (|| {
        if true {
            Box::new(future::ok("foo".to_owned()))
        } else {
            bar()
        }   
    })()
}

fn bar() -> Box<Future<Item=String, Error=String>> {
    Box::new(future::ok("bar".to_owned()))
}
```

```rust
extern crate futures;
use futures::future::{self, Future};

fn main() {
    println!("{}", foo().wait().unwrap());
}

fn foo() -> Box<Future<Item=String, Error=String>> {
    (|| {
        if true {
            return Box::new(future::ok("foo".to_owned()));
        } else {
            bar()
        }   
    })()
}

fn bar() -> Box<Future<Item=String, Error=String>> {
    Box::new(future::ok("bar".to_owned()))
}
```

But in reality, the first snippet works fine, and the second fails because the typechecker cannot unify `std::boxed::Box<futures::FutureResult<std::string::String, _>>` with `std::boxed::Box<futures::Future<Item=std::string::String, Error=std::string::String>>`. Given that the typechecker *can* and *does* unify them in the first case, it seems it should be able to do the same in the second case. Whether I use an implicit or explicit return shouldn't change the type analysis being done.
Repository: TypeScript
Issue: Return type inference broken for types with static members in ts 2.5; later fixed
Labels: Bug

Angular's dependency injection looks something like this:

```
interface Type<T> extends Function {
  new (...args: any[]): T;
}

function get<T>(token: Type<T>, notFoundValue?: T): T {
  return null as any as T;
}

class Token0 {
  a = 1;
}
class Token1 {
  static a = 1;
}

let t0 = get(Token0);  // t0 always inferred as Token0
let t1 = get(Token1);  // TS 2.5.3: t1 inferred as `{}` 
                       // TS 2.6.1 t1 inferred as `Token1`
```
As stated in those comments, starting in TS 2.5 we get the wrong type when a user asks the `Injector` for a Token with a static member. It's later fixed in TS 2.6.

Workaround is to give an explicit type argument to `get`, eg Angular users should repeat the type like `Injector.get<Token1>(Token1)`

There may be no action required here other than asking users to upgrade to TS 2.6 - but sadly Angular doesn't support it yet because we need to upgrade all the places we depend on first. Filing this issue mostly so we have a place to point to in the Angular changelog.
Repository: go
Issue: net: LookupHost IDN support
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?
go version go1.9 linux/amd64

### What operating system and processor architecture are you using (`go env`)?
GOARCH="amd64"
GOBIN="/home/oleg/go/work"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/oleg/go/"
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-build065227263=/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 tried to resolve hostname that contains special symbols, e.g. '/', '='. But I got error 'no such host'. Utilities host, dig and nslookup provides this opportunity. Also they allow to resolve hostnames with length is more then 255 symbols unlike net.LookupHost.

_**Example:**_
```
_, err := net.LookupHost("/.yandex.ru")
fmt.Println(err)      // lookup /.yandex.ru: no such host
```

### What did you expect to see?
**_For example, host:_**
```
$ host /.yandex.ru
/.yandex.ru has address 213.180.204.242
/.yandex.ru mail is handled by 10 not-for-mail.yandex.net.
```
Repository: TypeScript
Issue: Feature request: exclude outDir by default in tsconfig.json
Labels: Suggestion,Awaiting More Feedback

**Scenario**: As a user, I want typescript compiler to default-exclude output transpiled files to `compilerOptions.outDir` with `compilerOptions.declaration` property set to `true`. I would expect that `outDir` is excluded by default, because: 
- it would prevent me from importing definitions from `outDir` by error, which is easy to do with intellisense
- it would prevent me from having `TS5055` errors such as spotted in #16749 and  #6046
- `tsc` CLI has already implemented this behaviour, see PR #8703
Repository: TypeScript
Issue: Feature request: allow user to merge extended arrays in tsconfig files
Labels: Suggestion,Awaiting More Feedback

**Scenario**: As a user, I would like to optionally merge extended arrays in `tsconfig` files. To do so, I would add a nested dot array `["..."]` reminding spread operator to the property I want to merge. Here is an example: 
<details>
<summary><code>tsconfig-base.json</code></summary>
<pre>
{
  "exclude": ["**/__specs__/*"]
}
</pre>
</details> 

<details>
<summary><code>tsconfig-custom.json</code></summary>
<pre>
{
  "extends":  "./tsconfig-base.json",
  "exclude": [["...tsconfig-base"], "lib"] // resolved to ["**/__specs__/*"; "lib"]
}
</pre>
</details> 
<br/>

**Alternative**: using a config `{}` object

<details>
<summary><code>tsconfig-custom.json</code></summary>
<pre>
{
  "extends":  "./tsconfig-base.json",
  "exclude": [{ "extends": "tsconfig-base" }, "lib"] // resolved to ["**/__specs__/*"; "lib"]
}
</pre>
</details>
Repository: TypeScript
Issue: [Suggestion] Allow @ts-ignore at the end of the same line
Labels: Suggestion,In Discussion

I added a comment in https://github.com/Microsoft/TypeScript/pull/18457#issuecomment-339097980 but I think that nobody saw it.

It would be nice if I could put the `@ts-ignore` at the same line, to leave the code more readable

```ts
let v1: string = 1; // @ts-ignore
let v2: string = 2; // @ts-ignore
let v3: string = 3; // @ts-ignore
let v4: string = 4; // @ts-ignore
let v5: string = 5; // @ts-ignore
let v6: string = 6; // @ts-ignore
```

instead of:

```ts
// @ts-ignore
let v1: string = 1;
// @ts-ignore
let v2: string = 2;
// @ts-ignore
let v3: string = 3;
// @ts-ignore
let v4: string = 4;
// @ts-ignore
let v5: string = 5;
// @ts-ignore
let v6: string = 6;
```
Repository: TypeScript
Issue: No warning when using unary +/- operators on functions and objects?
Labels: Suggestion,Revisit

**TypeScript Version:**  2.6.1

**Code**
```ts
let func = () => "func";
+func; // no error
-func; // no error

let obj = { foo: "bar" };
+obj; // no error
-obj; // no error
```

**Expected behavior:**
Unary `+` or `-` is only applicable to a `number` or maybe a `string`.  I would expect the lines listed as `// no error` to be errors.

**Actual behavior:**
Unary `+` and `-` never generates a warning no matter what crazy stuff I try to apply it to.

---

I was made aware of this behavior by [a recent Stack Overflow question](https://stackoverflow.com/questions/47361859/typescript-error-on-implicit-type-conversion).  I see from #7019 that unary `+` and `-` on `string`s is supported, and I guess I can understand that as a way to parse a `string` into a `number` (for `+`, anyway.  Is `-` really used like this in practice?).  But functions? objects?  Seems more likely to be an error than intentional to me.  Thoughts?
Repository: javascript
Issue: Explain UTF-8 BOM rule in readme
Labels: question

Most style decisions are explained in the readme, but I couldn't find the reasoning on why a BOM is considered bad. Where I've looked:

* [the patch](https://github.com/airbnb/javascript/commit/d9cb343b518349982f3b094f2ce48eda8347e6c7) that enabled it, found no commit message body.
* the current code of the rules file, https://github.com/airbnb/javascript/blob/8cf2c70a4164ba2dad9a79e7ac9021d32a406487/packages/eslint-config-airbnb-base/rules/style.js#L472-L474
* [the eslint rule page](https://eslint.org/docs/rules/unicode-bom) mentioned in the patch code comment, doesn't claim it's bad.
* searched the readme for "BOM", "unicode" and "byte order"
* searched issue tracker for "BOM", "unicode" and "byte order"

Could someone explain it, or add search keywords to make the explanation easier to find?

Update: Also, is there a recommendation on how to declare the file encoding instead? I searched the readme for "charset", "encod" and "character set" but no matches.
Repository: go
Issue: time: Time.Format does not provide space padding for numbers other than days
Labels: help wanted,NeedsInvestigation,FeatureRequest

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?
`go version go1.9.2 darwin/amd64`

### Does this issue reproduce with the latest release?
I'm not sure I'm running the latest release of Go, but I just ran `brew upgrade go` on my macOS laptop and it says `go 1.9.2 already installed`.

### What operating system and processor architecture are you using (`go env`)?
```
GOARCH="amd64"
GOOS="darwin"
```

### What did you do?
I was trying to make a library that gives programmers who wanted to use Python-like `strftime` method on `time.Time` a nice `Strftime` function. While writing test code to test if paddings are working, I found that there is no space(literal ` `) padding for 'month' and 'hour' but only 'day' haves it.

To explain what happens, here's Go playground's link: https://play.golang.org/p/cAgWgVD5Tu

As you can see underscore(`_`) layout string doesn't work for month, hour, minute and second.

### What did you expect to see?
In the above playground, I expected ` 9  4` for month and day.

### What did you see instead?
But I've got `_9  4` instead. Same for month, hour, minute and second.

I would like to patch the `time` package and I'd like to know whether this issue has already issued or not. Thanks.
Repository: rust
Issue: rustc "unexpected panic"; no /proc/self/exe inside a debootstrap chroot
Labels: O-linux,I-ICE,T-compiler,C-bug

I installed rustc in a Debian chroot, as per https://wiki.debian.org/Debootstrap

```
sudo debootstrap testing /debian-testing-chroot https://deb.debian.org/debian/
```

Inside that chroot, rustc crashes.

```
# rustc hello.rs
Can't read /proc/cpuinfo: No such file or directory
error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.21.0 running on x86_64-unknown-linux-gnu

thread 'rustc' panicked at 'failed to get current_exe: no /proc/self/exe available. Is /proc mounted?', src/librustc/session/filesearch.rs:169:22
note: Run with `RUST_BACKTRACE=1` for a backtrace.

# ls /proc
#
```

Sure, I can tinker with my chroot configuration to flesh out /proc, but as rustc's output said, "the compiler unexpectedly panicked. this is a bug".