sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: nvm
Issue: --reinstall-packages-from fails when local repositories are npm link'd
Labels: bugs,needs followup

- Operating system and version: macOS Sierra 10.12.4

- `nvm debug` output: 
<details>
<!-- do not delete the following blank line -->

```sh
nvm --version: v0.33.0
$SHELL: /bin/zsh
$HOME: /Users/phulce
$NVM_DIR: '$HOME/.nvm'
$PREFIX: ''
$NPM_CONFIG_PREFIX: ''
nvm current: v7.9.0
which node: $NVM_DIR/versions/node/v7.9.0/bin/node
which iojs: iojs not found
which npm: $NVM_DIR/versions/node/v7.9.0/bin/npm
npm config get prefix: $NVM_DIR/versions/node/v7.9.0
npm root -g: $NVM_DIR/versions/node/v7.9.0/lib/node_modules
```
</details>

- `nvm ls` output:
<details>
<!-- do not delete the following blank line -->

```sh
         v6.9.5
         v7.2.1
->       v7.9.0
default -> v7.2.1
node -> stable (-> v7.9.0) (default)
stable -> 7.9 (-> v7.9.0) (default)
iojs -> N/A (default)
lts/* -> lts/boron (-> N/A)
lts/argon -> v4.8.2 (-> N/A)
lts/boron -> v6.10.2 (-> N/A)
```
</details>

- How did you install `nvm`? (e.g. install script in readme, homebrew): 

homebrew

- What steps did you perform? 

Ran `nvm install v7.9.0 --reinstall-packages-from=v7.2.1`

- What happened? 

Saw errors in the console and no globally installed packages were reinstalled (`yarn` for example).
<details>

```sh
Downloading and installing node v7.9.0...
Downloading https://nodejs.org/dist/v7.9.0/node-v7.9.0-darwin-x64.tar.xz...
######################################################################## 100.0%
Computing checksum with shasum -a 256
Checksums matched!
Now using node v7.9.0 (npm v4.2.0)
VERSION=''
xargs: unterminated quote
Reinstalling global packages from v7.2.1...
Linking global packages from v7.2.1...
nvm_cd:cd:2: no such file or directory: /Users/phulce/Code/npm-linked-package-a\n/Users/phulce/Code/npm-linked-package-b\n/Users/phulce/Code/npm-linked-package-c\n/Users/phulce/Code/npm-linked-package-d\n/Users/phulce/Code/npm-linked-package-e
```
</details>

- What did you expect to happen?

No errors printed to console and globally installed packages from my previous version are available in the new installation (re-linking local packages that are `npm link`'d would be a nice bonus but I did not expect it :) )

- Is there anything in any of your profile files (`.bashrc`, `.bash_profile`, `.zshrc`, etc) that modifies the `PATH`? 

Yes before the `nvm.sh` eval I add a few local
Repository: go
Issue: proposal: cmd/vet: add check for common error mishandling pattern
Labels: Proposal,Proposal-Hold,Analysis

People have proposed adding a test to vet to catch certain unused errors. This can be very noisy, and there are many cases where the error is genuinely known to be nil and can be ignored, such as in a call to `bufio.Writer.Write`. Therefore a general "unused error" check will be too noisy and fail the precision criterion described in `cmd/vet/README`.

However, my project has been badly bitten twice recently by a particular problem of unused errors that should be caught. The two looked schematically like these snippets:

```
func e() error { ... }
var err error

# Error value not caught in if init:
if e(); err != nil {...}

# Error value not caught before if:
e()
if err != nil { ... }
```

I did some experiments to catch calls to functions with the type of `e` that did not catch the error, and found too may false positives for things like `os.Setenv`.

However, since the real problem isn't that the error is discarded, but that it is discarded immediately before a check, I think it's worth trying a more targeted approach, one that would catch both of the problems in the snippets above.

The `-unusedresult` flag, on by default, already checks for things like calls to `fmt.Sprintf` where the value is not used, which is clearly a bug - there is no other reason to call `fmt.Sprintf`. That check works with a whitelist, but the problems in the examples above involved local functions that would never appear on a whitelist unless explicitly added when vet is called, which is error-prone (and not done in general).

I therefore propose to add to the `-unusedresult` check a test for the specific case with these three properties:

1. a call to a function that returns an error as one of its possibly several arguments;
2. return values from the function are dropped (no explicit `_`);
3. the next statement reads a variable of type error.

It's point 3 that makes this work, I think, eliminating almost all the noise from calls to things like `os.Setenv` while catching the real bugs. If you just called an error function and then ask about the error, if there's no flow from the call to the check, you almost certainly made a mistake.

Regarding the criteria:

Correctness: This is a real bug, and it's bitten our project twice with severe security problems as a result. This is a problem that needs fixing.

Frequency: It's hit our project twice, and our project isn't big. I believe the severity is high enough that even a modest frequency of hits justifies the fix. If I implement this, I predict it will find more.

Precision: I believe that rule 3 in this proposal should make it precise enough.
Repository: kubernetes
Issue: Standardize Container-Related Kubelet Prometheus Metrics
Labels: sig/scalability,lifecycle/frozen

Currently, the Prometheus metrics exposed by Kubelet are simply those directly exported by cAdvisor.  In light of the move to make metrics more easily accessible to third-party monitoring pipelines (as per the monitoring vision), we should standardize and document the set of metrics that are guaranteed to be exported.

Currently, the set of metrics exported by cAdvisor don't follow the instrumentation guidelines in some cases.  For instance, the container metrics use `pod_name` instead of `pod` (https://github.com/kubernetes/community/blob/master/contributors/devel/instrumentation.md#resource-referencing), and don't always follow proper naming conventions (e.g. `container_fs_inodes_total` is suffixed with `_total`, but is a gauge).  This makes them difficult to use in conjunction in a consistent way.

However, on a more fundamental level, not having a well-defined set of metrics makes it difficult for monitoring solutions to know what they can rely on (e.g. I always want to display FS state on my dashboard -- what metric do I use), and it means that changes to cAdvisor can inadvertently break compatibility (e.g. changing the semantics of certain labels).

Standardizing the set of metrics we provide also means that we ever run without cAdvisor (e.g. because we've moved the responsibility of metrics onto the container runtime), whatever is providing the metrics instead knows exactly what it needs to provide.
Repository: TypeScript
Issue: checkJs: allow file extensions other than .js
Labels: Suggestion,Awaiting More Feedback

First of all, this option is super exciting! Thank you so much for the TypeScript team to make such an incredible tool ❤️ 

Surprisingly enough, this week I wanted to have type check in a `*.jsfl` file (Scripting for Adobe Animate) and it worked pretty well using Facebook's Flow. They have [an option to configure a different file format](https://flow.org/en/docs/config/options/#toc-module-file-ext-string) other than `.js`.

It would be nice to allow this sort of configuration for TypeScript as well. I've naively tried to use `"include":["./src/*.jsfl"]` but it didn't worked. 😅 

Or is there a hidden option for this? Thanks!
Repository: rust
Issue: Specialization results in spurious mismatch type errors
Labels: T-compiler,A-specialization,C-bug,F-specialization

An upstream crate presents me with this API:

```rust
trait Foo { }

trait Bar {
    fn bar<F: Foo>(&self, f: F);
}
```

This is a fine API as far as it goes, but my problem is that I only care about one `Foo`, and I need `Bar` to be object safe. For my use case, this is the API I want:

```rust
struct MyFoo;

impl Foo for MyFoo { }

trait MyBar {
    fn my_bar(&self, f: MyFoo);
}
```

But I need to bridge `T: MyBar` to `T: Bar`. I have this solution, based on specialization, which I believe is correct:

```rust
trait BarBridge<F: Foo> {
    fn bridge(&self, f: F) -> F::Assoc;
}

struct Bridge<T: MyBar>(T);

impl<T: MyBar> BarBridge<MyFoo> for Bridge<T> {
    fn bridge(&self, f: MyFoo) -> bool {
        self.0.my_bar(f)
    }
}

impl<T: MyBar, F: Foo> BarBridge<F> for Bridge<T> {
    default fn bridge(&self, _: F) {
        unreachable!()
    }
}

impl<T: MyBar> Bar for Bridge<T> {
    fn bar<F: Foo>(&self, f: F) {
        self.bridge(f)
    }
}
```

However this appears to greedily attempt to unify `F` with `MyFoo` because of the implementation of `BarBridge<MyFoo>` instead of recognizing the implementation of `forall<F: Foo> BarBridge<F>`.

cc @nikomatsakis @aturon
Repository: youtube-dl
Issue: Feature Request: Add support for dowloading VideoLectures.NET's slides 
Labels: question

Since it's quite tedious to download each slide of a playlist, can youtube-dl also download the ppt/pdf files while downloading the corresponding videos?
Repository: go
Issue: net/http: BenchmarkClientServerParallel4 hangs and is useless
Labels: Testing,help wanted

It seems the BenchmarkClientServerParallel4 benchmark sometimes hangs while running. Sometimes it needs to be killed (first example) and sometimes it recovers on its own, leading to useless numbers.

In any case, I can't get good numbers out of it.

I suspect it's consuming too many sockets and running out of addresses or something.

```
bradfitz@gdev:~/go/src/net/http$ go test -benchtime=1s -bench=BenchmarkClientServerParallel4 -count=3 -run=XXXX | tee before
goos: linux
goarch: amd64
pkg: net/http
BenchmarkClientServerParallel4-4           30000             39470 ns/op            7539 B/op         73 allocs/op
BenchmarkClientServerParallel4-4           50000             40934 ns/op            7563 B/op         73 allocs/op
BenchmarkClientServerParallel4-4        ^C
bradfitz@gdev:~/go/src/net/http$ go test -benchtime=1s -bench=BenchmarkClientServerParallel4 -count=3 -run=XXXX | tee before
goos: linux
goarch: amd64
pkg: net/http
BenchmarkClientServerParallel4-4            5000            283132 ns/op            7244 B/op         85 allocs/op
BenchmarkClientServerParallel4-4               1        7011289330 ns/op           54720 B/op        527 allocs/op
BenchmarkClientServerParallel4-4               1        7010777787 ns/op           37472 B/op        238 allocs/op
PASS
ok      net/http        16.585s
```
Repository: go
Issue: encoding/csv: add a way to limit bytes read per field/record
Labels: Proposal,FeatureRequest,Proposal-Hold

The [csv.Reader](https://golang.org/pkg/encoding/csv#Reader) has no way to limit the size of the fields read. In combination with [LazyQuotes](https://golang.org/pkg/encoding/csv/#Reader.LazyQuotes), this can lead to cases where a simple syntax error can make the Reader read everything until io.EOF into a single field.

Probably the simplest case (with LazyQuotes == true) is a quoted field, where there is some other rune between the closing quote and the comma (e.g. `a,"b" ,c`). In this case the second field will contain all bytes until either a single quote folowed by a comma or EOF is found. (See [my comment](https://github.com/golang/go/issues/8059#issuecomment-298054037) in #8059)

This behaviour can lead to excessive memory usage or even OOM when reading broken CSV files.

To avoid this I propose to add a new, optional field to Reader to allow limiting the size of each field. When set the Reader would return an error as soon as it hits the limit.

~~Alternatively the limit could be per record instead. This could help especially with situations where FieldsPerRecord == -1, because there can be a different, basically unlimitted number of fields per record so a limit of 100 bytes per field doesn't help with e.g. missing new lines leading to records with many fields.~~

The new field would be specified as (as proposed by @bradfitz)

```go
type Reader struct {
...
      // BytesPerField optionally specifies the maximum allowed number of bytes
      // per field. Zero means no limit.
      BytesPerField int
```
Repository: go
Issue: proposal: spec: disallow T<->uintptr conversion for type T unsafe.Pointer
Labels: LanguageChange,Proposal,LanguageChangeReview

Currently, implementations permit conversions to/from `unsafe.Pointer` **and** to/from types with underlying type `unsafe.Pointer`.

Consequently, unsafe conversions can be hidden because package unsafe doesn't even have to be imported.

This was arguably an "implementation mistake" which we should fix. See also #19306.
Repository: nvm
Issue: Install script should complain if $NVM_DIR isn't a valid base path
Labels: feature requests,pull request wanted,installing nvm

https://github.com/creationix/nvm/issues/1520#issuecomment-298117770 is an example of a user having an outdated `NVM_DIR` setting in their profile file.

The installation script should detect when the NVM_DIR does not exist (and ideally backtrack up til it can find the first nonexistent directory) and inform the user clearly that they need to fix their `NVM_DIR` setting (ideally with the default) and retry the installation.
Repository: rust
Issue: Tracking issue for RFC 1824: Proposal for default crate recommendation ranking
Labels: B-RFC-approved,T-cargo,C-tracking-issue

This is a tracking issue for the RFC 1824 (rust-lang/rfcs#1824).

**Steps:**

- [x] [Sort crates by number of downloads in the last 90 days](https://github.com/rust-lang/crates.io/issues/702)
- [x] [Render contents of README on crate pages](https://github.com/rust-lang/crates.io/issues/81)
- [ ] [Have `cargo new` add a template README and template documentation](https://github.com/rust-lang/cargo/issues/3506)
- [ ] ~[Create a "Well documented" badge for crates in the top 20%](https://github.com/rust-lang/crates.io/issues/703)~ (crates.io team decided against this)
- [x] [Add a badge for crate authors to self-report their maintenance intentions ](https://github.com/rust-lang/crates.io/issues/704)
- [x] [Add the ability for crate authors to add isitmaintained.com badges to their crate](https://github.com/rust-lang/crates.io/issues/705)
- [x] [Add the ability for crate authors to add code coverage badges to their crate](https://github.com/rust-lang/crates.io/issues/706)
- [ ] [Have "favorite owners" and highlight crates owned by your favorite owners in crate lists](https://github.com/rust-lang/crates.io/issues/494)
- [ ] Adjust documentation ([see instructions on forge][doc-guide])

[doc-guide]: https://forge.rust-lang.org/stabilization-guide.html#updating-documentation
Repository: javascript
Issue: Define public API
Labels: question,pull request wanted,editorial

Thank you all for this valuable resource. I was catching up on current practices with respect to "private" properties in JavaScript when I came upon the discussion in #490. It seems to me that the definition of public API used by this style guide is stricter than what SemVer describes. For example, the guide currently states that

> Although a leading underscore is a common convention to mean “private”, in fact, these properties are fully public, and as such, are part of your public API contract.

So, as far as this guide is concerned, anything which is accessible in a JavaScript library constitutes its public API. On the other hand, SemVer describes public API differently:

> 1. Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive.

I take this to mean that, as a library author, I am free to explicitly include and exclude properties from my public API, regardless of whether or not they are accessible in my JavaScript library.

So I propose that this guide define public API for itself and explain why it adheres to the definition that it does. I think this would inform developers evaluating the pros and cons of whether or not to adopt or reject a private convention in their projects.
Repository: rust
Issue: Inference disrupted by trait bound that is redundant with a HRTB
Labels: A-lifetimes,A-trait-system,T-compiler,A-inference,C-bug,T-types,fixed-by-next-solver

This compiles:

```rust
trait Trait<'a> {}

struct S<T>(T);

impl<'a, T> Trait<'a> for S<T> where T: for<'b> Trait<'b> {}

fn main() {}
```

This following does not. It seems like the impl already has `T: for<'b> Trait<'b>` so adding `T: Trait<'a>` should not affect the behavior.

```rust
trait Trait<'a> {}

struct S<T>(T);

// Added T: Trait<'a>
impl<'a, T> Trait<'a> for S<T> where T: for<'b> Trait<'b>, T: Trait<'a> {}

fn main() {}
```

```
error[E0283]: type annotations required: cannot resolve `T: Trait<'a>`
 --> src/main.rs:6:1
  |
6 | impl<'a, T> Trait<'a> for S<T> where T: for<'b> Trait<'b>, T: Trait<'a> {}
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: required by `Trait`
```

This currently affects the following and *many* people have run into it. The workaround is to remove the bound (https://github.com/rust-lang/rust-clippy/issues/1689).

```rust
#[derive(Deserialize)]
struct S<T: serde::de::DeserializeOwned>(T);
```
Repository: rust
Issue: Tracking issue for RFC 1868: A portability lint
Labels: A-lints,B-RFC-approved,T-lang,E-help-wanted,C-tracking-issue,finished-final-comment-period,disposition-close,Libs-Tracked,S-tracking-unimplemented

This is a tracking issue for the RFC "A portability lint" (rust-lang/rfcs#1868).

**Steps:**

- [ ] Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?)
- [ ] Adjust documentation ([see instructions on forge][doc-guide])
- [ ] Stabilization PR ([see instructions on forge][stabilization-guide])

[stabilization-guide]: https://forge.rust-lang.org/stabilization-guide.html
[doc-guide]: https://forge.rust-lang.org/stabilization-guide.html#updating-documentation

**Unresolved questions:**

- [ ] It's not clear what the story should be for a library like `libc`, which currently involves intricate uses of `cfg`. We should have some idea for how to approach such cases before landing the RFC.
Repository: opencv
Issue: OpenCVFindMKL fails to find MKL 2017
Labels: bug,category: build/install

<!--
If you have a question rather than reporting a bug please go to http://answers.opencv.org where you get much faster responses.
If you need further assistance please read [How To Contribute](https://github.com/opencv/opencv/wiki/How_to_contribute).

This is a template helping you to create an issue which can be processed as quickly as possible. This is the bug reporting section for the OpenCV library.
-->

##### System information (version)

- OpenCV => 3.2.0
- Operating System / Platform => Windows (64-bit) / x86
- Compiler => Visual Studio 2017
- IPP => 2017.0.2
- MKL => 2017.0.2
- TBB => 2017.0.5

##### Detailed description

There are a number of issues with the script:
1. It doesn't set suffix when searching for `mkl_intel_<suffix>.lib` during 32-bit configuration, ending up searching for `mkl_intel_.lib`.
2. It fails to find `tbb.lib` when configuring with `-D MKL_WITH_TBB=ON`, since the directory structure of TBB 2017 differs from what the script expects.
3. It doesn't take into account what OpenCVDetectTBB has found, which could end up badly when OpenCV is being build with an open source version of TBB while the commercial version is installed side-by-side with MKL.

##### Steps to reproduce

```
set CPATH=<path-to-open-source-TBB-include>
set LIBRARY_PATH=<path-to-open-source-TBB-libraries>

cmake -G "Visual Studio 15 2017" -D BUILD_CUDA_STUBS=OFF -D BUILD_DOCS=OFF -D BUILD_EXAMPLES=OFF -D BUILD_PERF_TESTS=OFF -D BUILD_TBB=OFF -D BUILD_TESTS=OFF -D BUILD_opencv_python2=OFF -D BUILD_opencv_python3=OFF -D WITH_IPP=ON -D IPPROOT="C:\Program Files (x86)\IntelSWTools\compilers_and_libraries\windows\ipp" -D MKL_WITH_TBB=ON -D WITH_TBB=ON -D BUILD_SHARED_LIBS=ON -D BUILD_JASPER=ON -D BUILD_JPEG=ON -D BUILD_OPENEXR=ON -D BUILD_PNG=ON -D BUILD_TIFF=ON -D BUILD_ZLIB=ON ..
```
Repository: flutter
Issue: Input validator async
Labels: a: text input,c: new feature,framework,customer: crowd,c: proposal,P3,team-text-input,triaged-text-input

The input validator does not support future<String> so if i want to validate making a request i can't because flutter does not support sync http request. Any suggestion?
Repository: go
Issue: cmd/asm: change canonical spelling of CMOVLEQ to CMOVL.EQ etc
Labels: help wanted,Proposal,Proposal-Accepted,NeedsFix,compiler/runtime

This proposal is originally from @rsc in issue #14069 and is about `CMOVLEQ` being ambiguous. I Extracted it as I believe it deserves its own issue.

> Recounting this to @aclements I figured out what is going on with CMOVLEQ. The GNU form is CMOV[cond][size] but the form added for Go is CMOV[size][cond]. So GNU's cmovleq is cmov-le-q while Go's CMOVLEQ is CMOV-L-EQ. The Intel syntax has no size suffix and is CMOVEQ/CMOVLE, but it seems clear that Go should not be inserting a size suffix in the middle of the defined opcode name. While in general I feel that we need to put up with past mistakes in our assembly definitions to avoid breaking existing assembly programs, this one seems so egregious and error-prone that I think we have no choice but to change these names for Go 1.7 to match the Intel and GNU syntax.

Unfortunately it seems too late for such a breaking change so the proposal evolved into introducing new aliases like `CMOVL.EQ` (`CMOV%size.%cond`) to lift the ambiguity and then, later on, remove the old versions. Maybe.
Repository: TypeScript
Issue: Make 'new.target' emit more precautions
Labels: Suggestion,Awaiting More Feedback

I noticed that the polyfill for `new.target` ...

```
class Foo {
    constructor() {
        if (new.target)
            alert("Good.");
        else
            alert("Bad!");
    }
}
```
... outputs to this:
```
var Foo = (function () {
    function Foo() {
        var _newTarget = this.constructor;
        if (_newTarget)
            alert("Good.");
        else
            alert("Bad!");
    }
    return Foo;
}());
```
That seems dangerous to me, since this is always a true condition for older browsers that don't yet support `new.target`. Does it not make more sense to create an output such as this?:

```
var Foo = (function () {
    function Foo() {
        var _newTarget = this && this.constructor !== Window ? this.constructor : void 0;
                         /* (have to check 'this' also, in case of strict mode) */
        if (_newTarget)
            alert("Good.");
        else
            alert("Bad!");
    }
    return Foo;
}());
```

The [following code fails](https://www.typescriptlang.org/play/#src=class%20%24Foo%20%7B%0D%0A%20%20%20%20constructor()%20%7B%0D%0A%20%20%20%20%20%20%20%20if%20(new.target)%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20alert(%22Good.%22)%3B%0D%0A%20%20%20%20%20%20%20%20else%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20alert(%22Bad!%22)%3B%0D%0A%20%20%20%20%7D%0D%0A%7D%0D%0A%0D%0Atype%20FooConstructor%20%3D%20typeof%20%24Foo%3B%0D%0A%0D%0Ainterface%20CallableFoo%20extends%20FooConstructor%20%7B%20()%3A%20%24Foo%3B%20%7D%0D%0A%0D%0Anew%20%24Foo()%3B%20%2F%2F%20ok%0D%0Avar%20Foo%3A%20CallableFoo%20%3D%20%3Cany%3EFoo%3B%0D%0AFoo()%3B%20%2F%2F%20ok%3F%20%3A%2F%0D%0A%0D%0A) to work as expected in Chrome v56.0.2924.87 (output is "Good." in call cases):

```
class $Foo {
    constructor() {
        if (new.target)
            alert("Good.");
        else
            alert("Bad!");
    }
}

type FooConstructor = typeof $Foo;

interface CallableFoo extends FooConstructor { (): $Foo; }

new $Foo(); // ok
var Foo: CallableFoo = <any>Foo;
Foo(); // ok? :/

```