sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: os: Add example showing how to read data from stdin
Labels: Documentation,help wanted,NeedsInvestigation

A pretty common task, especially for new programmers, is to ask the user to type in some value at the command line and then have the program act on it. (think "interactive maze game", "determine if word is palindrome", etc). It would be nice if we had an example in the `os` package showing how to do this.
Repository: rust
Issue: Tails calls are not being emitted as such
Labels: A-LLVM,T-compiler,C-bug

The following rust code should get tail calls:
```rust
pub fn moo() -> String {
    goo()
}

#[inline(never)]
pub fn goo() -> String {
    "https://".to_string()
}
```
Instead we get:
```assembly
example::moo:
        push    rbp
        mov     rbp, rsp
        push    rbx
        push    rax
        mov     rbx, rdi
        call    example::goo@PLT
        mov     rax, rbx
        add     rsp, 8
        pop     rbx
        pop     rbp
        ret

example::goo:
        push    rbp
        mov     rbp, rsp
        push    rbx
        push    rax
        mov     rbx, rdi
        lea     rsi, [rip + str.0]
        mov     edx, 8
        call    <alloc::string::String as core::convert::From<&'a str>>::from@PLT
        mov     rax, rbx
        add     rsp, 8
        pop     rbx
        pop     rbp
        ret

str.0:
        .ascii  "https://"
```
Repository: kubernetes
Issue: Increase test coverage for HA failure modes
Labels: area/test,kind/cleanup,sig/api-machinery,sig/cluster-lifecycle,kind/feature,lifecycle/frozen

Issues such as #47131 suggest our test coverage of failure modes for HA kubernetes configurations is insufficient.

This is a placeholder issue to review our existing test coverage, identify our most critical blind spots and propose a set of changes to improve our test coverage of HA failure modes.

The etcd team has written up a [summary of potential test cases](https://github.com/coreos/etcd/issues/8711)

cc @xiang90
Repository: rust
Issue: Compilation Error when Mixing Line and Block comment
Labels: A-diagnostics,A-parser,T-compiler

I have written a [small program](https://play.rust-lang.org/?gist=fb8ae0872ee993a786443f3a9900a5ec&version=stable).
```rust
fn main() {
    println!("Hello, one!");
    //*
    println!("Hello, two!");
    //*/
    println!("Hello, three!");
}
```
The above program compiles and runs successfully. But.
```rust
fn main() {
    println!("Hello, one!");
    /*
    println!("Hello, two!");
    //*/
    println!("Hello, three!");
}
```

The above program does not compiles and produces this `error: unterminated block comment`.
But as you can see the block comment is terminated.

This is a small trick to toggle comment a large group of statements by addition and removal of a `/`.
C language, javascript and Rust Lang share the same type of commenting style ( `//` and `/*  */` ).
This trick works in C lang ( I tried gcc and clang compiler) and javascript as well, but currently it is not working in Rust Lang.
Repository: TypeScript
Issue: Array.prototype.filter doesn't require callback to return
Labels: Suggestion,Domain: lib.d.ts,Awaiting More Feedback

I dig a bit and found out in #5850 and subsequently in #7779 the signature of filter has been changed not to return a boolean, so that people could return a truthy value in the implementation of the filter.

While I undertand the _convenience_ in terms of ease of use, this as far as I observed puts developers at risk of simple bugs like the following:

```typescript
const even = [1,2,3].filter(x => {
    x % 2 == 0
})
```

Notice the missing `return` statement means the function returns `undefined`, which translates to `false`, which filters all the items out. This applies also in the case of `noImplicitReturns` set to true, since the function return type is `any`, thus it could be a void function for what the compiler knows.

I believe TypeScript's job should be to put this kind of cases in check actually, so that things like truthy values (which sometimes aren't as obvious as we might think and introduce bugs we don't really understand) can be better taken care of.

One solution to make both parties happy would be to optionally support truthy values (maybe an extra compiler flag? Another `truthy` type to allow for more relaxed checking?) and reintroduce the original signature of filter.
Repository: kubernetes
Issue: Control plane bootstrapping order AKA we need a run-level concept
Labels: area/controller-manager,sig/api-machinery,sig/cluster-lifecycle,kind/feature,area/admin,area/admission-control,priority/important-longterm,lifecycle/frozen

### Background:

We are adding extension mechanisms to the Kubernetes control plane, initializers and admission webhooks. If e.g. the webhooks are configured but not actually running in the cluster, then the cluster is broken until an administrator can fix it. To make it possible to avoid this situation, we're going to let the webhook be gated on a selector matching the labels on the namespace containing the item under consideration. This should make it possible to construct a set of labels on namespaces that will allow the namespaces hosting the critical webhooks to be operational when the webhooks aren't running. (I will add a link to the design when it is published.)

### What we need:

We're looking for documented best practices around this. We imagined building a "run level" system in labels on namespaces out of this. A complete solution should
* Cover how many run levels there are
* Cover what components go in which run level
* Analyze the functionality of the current controller-manager; it may need to be split into binaries or modes that are in different run levels
* Draw some inspiration from Brian's [layers doc](https://docs.google.com/document/d/1XkjVm4bOeiVkj-Xt1LgoGiqWsBfNozJ51dyI-ljzt1o/edit). 

We think cluster lifecycle SIG is probably the best place for this to be worked out.

(This is from a meeting between myself, @cheftako, @deads2k, @smarterclayton, @liggitt, @caesarxuchao, and @jagosan. )
Repository: youtube-dl
Issue: Google Play Music support
Labels: geo-restricted,account-needed

## 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.10.20*. 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.10.20**

### 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)
- [x] Site support request (request for adding support for a new site)
- [ ] Feature request (request for a new functionality)
- [ ] Question
- [ ] Other
---

### If the purpose of this *issue* is a *site support request* please provide all kinds of example URLs support for which should be included (replace following example URLs by **yours**):

This is based on the `right click` -> `share` -> `copy link` functionality of items in google play music.

- Single video: https://play.google.com/music/m/Tg5o46ybbyflzb3epfxzr22za64?t=Asian_Jake_Paul_feat_Boyinaband_-_Idubbbz
- Single video: https://play.google.com/music/m/Tli62dsrjbu4b3paiux5uzp5rxq?t=Thats_What_I_Like_-_Bruno_Mars
- Playlist: https://play.google.com/music/playlist/AMaBXykOn9WLvry7WvNVB-721RkJthw2YC4qCLUngsHdXNoOc4W52UzzTH6EEgZipurK_2GXTDWMN6GOvZAs_VKvlfL4vvYNCQ%3D%3D
- Album: https://play.google.com/music/m/Bkgg5do3ni6nyae3hvn6ngtia2e?t=Astro_Lounge_-_Smash_Mouth

Note that **youtube-dl does not support sites dedicated to [copyright infringement](https://github.com/rg3/youtube-dl#can-you-add-support-for-this-anime-video-site-or-site-which-shows-current-movies-for-free)**. In order for site support request to be accepted all provided example, URLs should not violate any copyrights.

---

### Description of your *issue* suggested solution and other information

Site support for Google Play Music. Hopefully, audio-only services are welcome here. This does require a youtube red/GPM subscription to support non-user uploaded songs.
Repository: TypeScript
Issue: No compile error for satisfying function signature of only one branch of union of two
Labels: Bug

<!-- 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 -->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  What the playground uses today (October 25th)

**Code**

```ts
class Henk {
    giveMe<T>(valueWhere: T & { henk: string }) {
        
    }
}

class Piet {
    giveMe<T>(valueWhere: T & { piet: number }) {

    }
}

const henkOrPiet: Piet | Henk = null
henkOrPiet.giveMe({
    henk: ''
})
```

**Expected behavior:**
I would expect a compile error, because `henkOrPiet.giveMe(...)` should accept only a `T` that matches both `T & { henk: string }` and `T & { piet: number }`, which should (ideally) be `{ henk: string, piet: number }`. Instead it compiles if we only satisfy the first.

**Apparently this has to do with the order in which `Henk` and `Piet` are defined, because if I switch them, `henkOrPiet.giveMe({ piet: 4 })` will compile.

**Actual behavior:**
No compile error.
Repository: pytorch
Issue: DataLoader "casting" non statndard objects to lists
Labels: module: dataloader,triaged

**The Problem:**
Currently if you implement a nonstandard collate function which, for example returns a namedtuple and set pin_memory=True the namedtuple would be "casted" to a list  by the following [code](https://github.com/pytorch/pytorch/blob/23a3f78988aeeaf3ca193ec0b03fd755ddbcdd49/torch/utils/data/dataloader.py#L116).

**Proposed Approach:**
Add another argument to the data loader constructor `DataLoader(batch_type_ctor=bt_ctor)`, where bt_ctor is a callable returning a constructed object. The result of pin_memory_batch should be passed to bt_ctor, and so should be the result of collate_fn if collate_fn is default_collate.

This approach might seem to add complexity to DataLoader since the connection between batch_type_ctor and collate_fn is non trivial if you don't read the code and may result in some code duplication.

For example if you implement a nonstandard collate_fn which returns a namedtuple then the return value of the collate_fn should be resupplied via batch_type_ctor if pin_memory is used.

But this approach seems to result in the most simple api and simple implementation.

**PS**
I would enjoy contributing to the project.





cc @SsnL
Repository: vscode
Issue: Git - Support to compare with arbitrary commit instead of the current HEAD
Labels: feature-request,git

Currently numerous places (explorer, gutters, etc.) will display changes since the last commit. I believe it would be useful to allow to show the same annotations but related to a different branch or tag. I am currently working on a large pull request and find myself constantly running `git diff master` in a console.
Repository: nvm
Issue: nvm uninstall... doesn't
Labels: uninstalling,bugs,pull request wanted

- Operating system and version:

Ubuntu 14.04.3 LTS

- `nvm debug` output:
<details>
<!-- do not delete the following blank line -->

```
nvm --version: v0.31.0
$SHELL: /bin/bash
$HOME: /home/ubuntu
$NVM_DIR: '$HOME/.nvm'
$PREFIX: ''
$NPM_CONFIG_PREFIX: ''
nvm current: v6.11.5
which node: $NVM_DIR/versions/node/v6.11.5/bin/node
which iojs: 
which npm: $NVM_DIR/versions/node/v6.11.5/bin/npm
npm config get prefix: $NVM_DIR/versions/node/v6.11.5
npm root -g: $NVM_DIR/versions/node/v6.11.5/lib/node_modules
```
</details>

- `nvm ls` output:
<details>
<!-- do not delete the following blank line -->

```
        v6.10.0
->      v6.11.5
         system
default -> 6.11.5 (-> v6.11.5)
node -> stable (-> v6.11.5) (default)
stable -> 6.11 (-> v6.11.5) (default)
iojs -> N/A (default)
```
</details>

- How did you install `nvm`? (e.g. install script in readme, homebrew):

Pre-installed on Cloud 9.

- What steps did you perform?

```
$ nvm ls
        v6.10.0
->      v6.11.5
         system
default -> 6.11.5 (-> v6.11.5)
node -> stable (-> v6.11.5) (default)
stable -> 6.11 (-> v6.11.5) (default)
iojs -> N/A (default)
$ node -v
v6.11.5
$ nvm uninstall 6.10.0
Uninstalled node v6.10.0
$ nvm ls
        v6.10.0
->      v6.11.5
         system
default -> 6.11.5 (-> v6.11.5)
node -> stable (-> v6.11.5) (default)
stable -> 6.11 (-> v6.11.5) (default)
iojs -> N/A (default)
```

- What happened?

As above.

- What did you expect to happen?

I expected v6.10.0 to be uninstalled.  It was reported as being deleted, but it wasn't.

- Is there anything in any of your profile files (`.bashrc`, `.bash_profile`, `.zshrc`, etc) that modifies the `PATH`?

No.
Repository: vue
Issue: Request: add v-model.lazy for components
Labels: feature request,has PR

### What problem does this feature solve?
v-model for components already supports .trim and .number.
Lazy modifier support for components would make it more uniform across the platform.

### What does the proposed API look like?
The only change (backwards compatible) would be to add a new property to model definition:
```
model: {
  prop: 'value',
  event: 'input',
  eventLazy: 'change'
}
```

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: go
Issue: x/build/cmd/coordinator: staging environment doesn’t run current version
Labels: Builders

When running coordinator on the `go-dashboard-dev` project (our staging environment), it panics:
```
2017/10/25 17:24:24 Running in prod mode
panic: unknown builder "windows-386-gce"

goroutine 1 [running]:
main.stagingClusterBuilders(0x8)
	/go/src/golang.org/x/build/cmd/coordinator/coordinator.go:396 +0x527
main.main()
	/go/src/golang.org/x/build/cmd/coordinator/coordinator.go:318 +0xc50
```

This appears to be an issue with the environment and not the binary logic.

/cc @adams-sarah
Repository: go
Issue: cmd/compile: escape analysis loopdepth should reset when blocks end
Labels: NeedsInvestigation,compiler/runtime

Compiling the package below with compile -m shows that `new(int)` escapes to heap:

    package p

    func g() bool

    //go:noescape
    func h(*int)

    func f() {
            var p *int
            if g() {
            x:
                    goto x
            } else {
                    p = new(int)
            }
            h(p)
    }

After replacing `x: goto x` with `for {}`, it no longer escapes.

The issue is `x` is considered a looping label, so `(*EscState).esc` increments `e.loopdepth` when visiting it. However, loopdepth is never decremented again at the end of its enclosing block, so loopdepth is still incremented when visiting the `p = new(int)` assignment.
Repository: go
Issue: cmd/dist: feature request: control over maximum number of CPUs used during build and test
Labels: NeedsInvestigation

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?
go version
go version devel +a31e0a4aac Sat Oct 21 11:32:53 2017 +0000 darwin/amd64

### Does this issue reproduce with the latest release?
Yes


### What operating system and processor architecture are you using (`go env`)?
go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/sean/go"
GORACE=""
GOROOT="/Users/sean/goLang/go"
GOTOOLDIR="/Users/sean/goLang/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/75/tsmllrjr8xl81b0059bfyyd00000gs/T/go-build923680158=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
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?
Invoke `all.bash` after updating with `git fetch` and `git pull`.

### What did you expect to see?
No more than `$GOMAXPROCS`  used during the build and testing process.


### What did you see instead?
Every processor available being utilized.

I really like to be able to limit the number of logical processors that the build and test process Go uses. The logical choice would be for the process to respect the environment variable `GOMAXPROCS`. The reason for wanting to impose this limit is to manage the amount of heat produced on my system during the process.
Repository: rust
Issue: Specialization: cannot specialize an impl of a local trait when the default impl is a blanket impl bounded by a non-local trait
Labels: T-compiler,A-specialization,C-feature-request,F-specialization

Found this in the Chucklefish AMA thread, [in the subthread](https://www.reddit.com/r/rust/comments/78bowa/hey_this_is_kyren_from_chucklefish_we_make_and/dow4br2/?context=3) about working around the lack of `Ord` on floats.

This code compiles:
```rust
#![feature(specialization)]

trait Foo { fn foo(&self); }

impl<T: Ord> Foo for T { default fn foo(&self) {} }
```

...But adding a specialized impl fails:
```rust
#![feature(specialization)]

trait Foo { fn foo(&self); }

impl<T: Ord> Foo for T { default fn foo(&self) {} }

impl Foo for f64 { fn foo(&self) {} }
```

Error message:
```
error[E0119]: conflicting implementations of trait `Foo` for type `f64`:
 --> src/main.rs:7:1
  |
5 | impl<T: Ord> Foo for T { default fn foo(&self) {} }
  | --------------------------------------------------- first implementation here
6 | 
7 | impl Foo for f64 { fn foo(&self) {} }
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `f64`
  |
  = note: upstream crates may add new impl of trait `std::cmp::Ord` for type `f64` in future versions
```

I'm afraid I don't see how the error message is relevant, or how an upstream impl of `Ord` for `f64` could conflict with this impl of the local `Foo` trait. Is this intended behavior?

The above is a reduction, here's the original example which raises a few other questions:
```rust
#![feature(specialization)]

pub trait OrdSubset: PartialOrd<Self> + PartialEq<Self> {
	fn is_outside_order(&self) -> bool;
}

impl<T: Ord> OrdSubset for T {
    default fn is_outside_order(&self) -> bool {
        false
    }
}

// I'd expect this to work
impl OrdSubset for f64 {
	fn is_outside_order(&self) -> bool {
			(*self).is_nan()
	}
}

// not sure about this
impl<'a, A: OrdSubset> OrdSubset for &'a A {
	fn is_outside_order(&self) -> bool {
		(**self).is_outside_order()
	}
}

/*   The next two are basically the same as above, &mut and f64

impl<'a, A: OrdSubset> OrdSubset for &'a mut A {
	fn is_outside_order(&self) -> bool {
		(**self).is_outside_order()
	}
}

impl OrdSubset for f32 {
	fn is_outside_order(&self) -> bool {
		(*self).is_nan()
	}
}
*/
fn main() {
}
```
Repository: rust
Issue: ABI code generates oversize loads when returning with a cast
Labels: I-crash,A-LLVM,A-codegen,P-medium,T-compiler,C-bug

## Meta

```
$ rustc --version
rustc 1.22.0-nightly (185cc5f26 2017-10-02)
```

## STR

```Rust
#![crate_type="rlib"]

#[no_mangle]
pub extern "C" fn foo(x: &(i8, i8, i8)) -> (i8, i8, i8) {
    *x
}
```

target is x86_64-unknown-linux-gnu

## Expected Result

Code generated should not have UB

## Actual Result

The generated no-opt LLVM IR is:
```llvm
; ModuleID = 'cast.cgu-0.rs'
source_filename = "cast.cgu-0.rs"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

; Function Attrs: nounwind uwtable
define i32 @foo({ i8, [0 x i8], i8, [0 x i8], i8, [0 x i8] }* noalias readonly dereferenceable(3)) unnamed_addr #0 {
start:
  %_3 = alloca { i8, [0 x i8], i8, [0 x i8], i8, [0 x i8] }
  ; COMMENT MINE: %_0 has size 3
  %_0 = alloca { i8, [0 x i8], i8, [0 x i8], i8, [0 x i8] }
  %1 = bitcast { i8, [0 x i8], i8, [0 x i8], i8, [0 x i8] }* %0 to i8*
  %2 = bitcast { i8, [0 x i8], i8, [0 x i8], i8, [0 x i8] }* %_3 to i8*
  call void @llvm.memcpy.p0i8.p0i8.i64(i8* %2, i8* %1, i64 3, i32 1, i1 false)
  %3 = bitcast { i8, [0 x i8], i8, [0 x i8], i8, [0 x i8] }* %_3 to i8*
  %4 = bitcast { i8, [0 x i8], i8, [0 x i8], i8, [0 x i8] }* %_0 to i8*
  call void @llvm.memcpy.p0i8.p0i8.i64(i8* %4, i8* %3, i64 3, i32 1, i1 false)
  ; COMMENT MINE it is cast to an i32 here
  %5 = bitcast { i8, [0 x i8], i8, [0 x i8], i8, [0 x i8] }* %_0 to i32*
  ; COMMENT MINE and then loaded as through it was size 4
  %6 = load i32, i32* %5, align 1
  ret i32 %6
}

; Function Attrs: argmemonly nounwind
declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture writeonly, i8* nocapture readonly, i64, i32, i1) #1

attributes #0 = { nounwind uwtable "probe-stack"="__rust_probestack" }
attributes #1 = { argmemonly nounwind }
```

This loads 4 bytes of an alloca of size 3. I couldn't trivially turn this to an end-to-end mis-code-generation (this can't be used to load from anything *but* the return pointer, so you can't do the standard "load at end of page" trick), but I can't see how can oversize loads can be anything *but* UB.

cc @eddyb - I *think* one solution would be to pad the return pointer alloca to always have enough space for the cast, aka:
```llvm
  %_0_store = alloca {{ i8, [0 x i8], i8, [0 x i8], i8, [0 x i8] }, [1 x i8]}
  %_0 = getelementptr inbounds {{ i8, [0 x i8], i8, [0 x i8], i8, [0 x i8] }, [1 x i8]}, {{ i8, [0 x i8], i8, [0 x i8], i8, [0 x i8] }, [1 x i8]}* %_0_store, i32 0, i32 1
```

I *think* the problem load is the one in https://github.com/rust-lang/rust/blob/e847f30f571e617990f7193665ab10127100e9df/src/librustc_trans/mir/block.rs#L247, but I can't be sure.