sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: `thread::Builder::spawn` returns WouldBlock for EAGAIN
Labels: O-linux,P-low,T-libs-api,C-bug

When trying to launch a thread and the thread limit is reached or there is not enough virtual address space available for another thread, `thread::Builder::spawn` returns an `io::Error` of kind `WouldBlock`.

```rust
extern crate libc;

fn main() {
    unsafe {
        libc::setrlimit(libc::RLIMIT_NPROC, &libc::rlimit { rlim_cur: 0, rlim_max: 0 });
    }

    let error = std::thread::Builder::new().spawn(|| unreachable!()).unwrap_err();

    println!("I/O error kind {:?}: {:?}", error.kind(), error);
}
```

This prints (on Linux):
```
I/O error kind WouldBlock: Error { repr: Os { code: 11, message: "Resource temporarily unavailable" } }
```

[WouldBlock means](https://doc.rust-lang.org/std/io/enum.ErrorKind.html#variant.WouldBlock):

> The operation needs to block to complete, but the blocking operation was requested to not occur.

This doesn't make a lot of sense in the context of thread creation. Yes, if the create call were to block until the thread/virtual address space limit is no longer reached, this error interpretation would be correct, but I know of no threading API (Windows or Linux) with these semantics.

The source of the problem is that the POSIX errors `EAGAIN` and `EWOULDBLOCK` may be defined as the same error value, and Rust chose to always interpret that as `EWOULDBLOCK`. I'm not sure what course of action I'd suggest to clear up the confusion.

(NB. On Windows, AFAICT there is no way to limit the number of threads, but when running out of virtual address space, `CreateThread` returns `ERROR_NOT_ENOUGH_MEMORY`, which gets decoded as kind `Other`)
Repository: kubernetes
Issue: start migrating controllers to use the new Event API group
Labels: sig/scalability,area/controller-manager,lifecycle/frozen

Following #49112

The kubernetes/features#383 intends to migrate the different controllers towards the event API group described. This issue intends to track the PRs related to this migration.

cc @gmarek
Repository: pytorch
Issue: Suppress hidden state output of RNNs?
Labels: module: memory usage,triaged,enhancement

Currently the forward method of RNN modules (LSTM, GRU, etc) return the output as well as the hidden states of all layers. When an RNN module contains many layers, the second output can take up a significant amount of memory, even though in many cases it is not needed. E.g.
```
lstm = nn.LSTM(40, 320, 5)
y, _ = lstm(x)    # The '_' variable takes lots of memory even though it's discarded right away
```
On the other hand, if I break down a multilayer RNN module into many modules representing single layers, I can discard the second output of the forward method layer by layer. With a 5-layer LSTM, I found doing so saved so much memory that I could double the batch size.
```
lstm1 = nn.LSTM(40, 320, 1)
lstm2 = nn.LSTM(320, 320, 1)
lstm3 = nn.LSTM(320, 320, 1)
lstm4 = nn.LSTM(320, 320, 1)
lstm5 = nn.LSTM(320, 320, 1)
x, _ = lstm1(x)    # The unwanted second output is discarded layer by layer
x, _ = lstm2(x)    # and doesn't not consume too much memory
x, _ = lstm3(x)
x, _ = lstm4(x)
x, _ = lstm5(x)
```
Is it possible to add a switch to the forward method to specify whether the second output should be computed? E.g.
```
lstm = nn.LSTM(40, 320, 5)
y = lstm(x, requires_hidden = False)    # Do not store the hidden states of each layer
```
Repository: opencv
Issue: build warning: QuartzCore.framework/QuartzCore.tbd out of sync
Labels: category: build/install,platform: ios/osx

```
[ 28%] Linking CXX shared library ../../lib/libopencv_videoio.dylib
ld: warning: text-based stub file /System/Library/Frameworks//QuartzCore.framework/QuartzCore.tbd and library file /System/Library/Frameworks//QuartzCore.framework/QuartzCore are out of sync. Falling back to library file for linking.
```

Install Xcode 9.1
Run: `sudo xcode-select --install`
Repository: rust
Issue: Program compiles even though a type cannot be inferred
Labels: T-compiler,A-inference,C-bug

The code below compiles, even though the type of the elements of the `Vec` is unknown.

```rust
use std::mem;
use std::os::raw::c_void;

#[no_mangle]
pub extern "C" fn alloc(size: usize) -> *mut c_void {
    let mut buf = Vec::with_capacity(size);
    let ptr = buf.as_mut_ptr();
    mem::forget(buf);
    return ptr as *mut c_void;
}

fn main() { }
```

Somehow, Rust is picking a type and compiling anyway. It is unclear to me which type that may be and whether this behavior is specified somewhere. The type could be anything, from `()` to `String` or something else. You can test this by adding a type annotation to the declaration of `buf`. The code compiles regardless of the type you choose.
Repository: go
Issue: x/text: Support UnicodeSet as per UTR35
Labels: NeedsDecision

Feature request: Support the [UnicodeSet](http://unicode.org/reports/tr35/#Unicode_Sets) syntax as defined in [Unicode Technical Report 35](http://unicode.org/reports/tr35/). This would be needed to implement [CLDR transliteration rules](http://unicode.org/repos/cldr/trunk/common/transforms/) which use UnicodeSets for filtering and matching; to support [CLDR exemplar characters](http://unicode.org/reports/tr35/tr35-6.html#Character_Elements) which are also defined in terms of UTR35 UnicodeSets; and other Unicode stuff such as [UTR39 Unicode Security Mechanisms](http://www.unicode.org/reports/tr39/) that make use of UnicodeSets.

See Unicode’s [list-unicodeset tool](http://unicode.org/cldr/utility/list-unicodeset.jsp) for an online demo (and its [documentation](http://cldr.unicode.org/unicode-utilities/list-unicodeset)); and the [ICU documentation](http://userguide.icu-project.org/strings/unicodeset) for the ICU API to UnicodeSets.  For reference, you might want to have a look at the [C++ implementation](http://source.icu-project.org/repos/icu/icu/tags/release-58-rc/source/common/uniset.cpp) and the [Java implementation](http://source.icu-project.org/repos/icu/icu4j/tags/release-58-rc/main/classes/core/src/com/ibm/icu/text/UnicodeSet.java) inside the ICU sources.

Not sure if this could be implemented by rewriting the string syntax to Go regular expressions, or if this would need more work.
Repository: rust
Issue: Adding a specialized impl can break inference.
Labels: T-compiler,A-inference,C-bug,F-specialization

Relevant to #31844. This is how it happens:
```rust
#![feature(specialization)]

trait B { fn b(&self) -> Self; }

// Impl 1
impl<T> B for Option<T> where T: Default
{
    default fn b(&self) -> Option<T> { Some(T::default()) }
}
// Removing one of the two concrete impls makes inference succeed.
// Impl 2
impl B for Option<String>
{
    fn b(&self) -> Self { Some("special".into()) }
}
// Impl 3
impl B for Option<i32>
{
    fn b(&self) -> Self { Some(0) }
}

fn main() { 
    // Cannot infer `T` in `Option<T>`.
   None.b();
}
```
This issue does not originate from specialization, since if we removed `Impl 1` the same problem would occur. But with specialization if those impls were added in order, the story would be a bit confusing:
1. With `Impl 1`, inference fails.
2. Added `Impl 2`, yay inference succeeds.
3. Added `Impl 3`, inference is back to failing.

The only fix would be to make inference fail in step 2. Even if it's not something we want fix it still seems worth noting somewhere that we are ok with specializaton breaking inference.
Repository: rust
Issue: Poor error message for attempt to make doubly-fat pointers
Labels: C-enhancement,A-diagnostics,T-compiler

Compiling the following code yields the given error:
```rust
#![allow(unused_variables)]

trait T1 { fn f(&self); }
trait T2 { fn g(&self); }

struct S;

impl T1 for S {
    fn f(&self) {
        println!("<S as T1>::f");
    }
}

impl T2 for T1 {
    fn g(&self) {
        println!("<T1 as T2>::g");
        self.f();
    }
}

fn main() {
    let s: S = S;
    let bs: Box<S> = Box::new(s);

    let t1_object: Box<T1> = bs;
    let t2_object: Box<T2> = t1_object;
}
```

```plain
error[E0308]: mismatched types
  --> src/main.rs:26:30
   |
26 |     let t2_object: Box<T2> = t1_object;
   |                              ^^^^^^^^^ expected trait `T2`, found trait `T1`
   |
   = note: expected type `std::boxed::Box<T2>`
              found type `std::boxed::Box<T1>`
```

This is confusing when the intent is to create a trait object. I think it's common to internalize the rule that one can coerce `Box<T>` to `Box<Trait>` if `T: Trait`, without noticing the side requirement that `Box<T>` must not be a fat pointer, lest we create a doubly-fat pointer.

I would speculate that what's going on in the compiler is that the coercion code declines to perform any coercion, leaving Rust to report the mismatch. It would be helpful to issue a note to the effect that trait object creation was considered, but rejected because the incoming pointer was already fat.
Repository: rust
Issue: cargo test incorrectly warns for dead code
Labels: C-enhancement,T-cargo

Hi!

I got unexpected dead code warnings when executing `cargo test` with multiple test files. I use a very simple example below that reproduces the issue.

I have two files that contains tests, `tests/test_one.rs` and `tests/test_two.rs`. Both contains exactly the same content (except for the unique test function name they contain):

```rust
mod routines;

#[test]
fn test_one() {
    routines::my_routine();
}
```

And another file called `tests/routines.rs` that simply contains:

```rust
pub fn my_routine() {
}
```

When I execute `cargo test`, the two tests are executed successfully and there is no raised warning. But if I remove the `my_routine()` call from one of the two tests, `cargo test` stills end up successfully but raises a warning on `pub fn routine()` saying `function is never used`. However, one test still calls the function, so there is no dead code as stated. 

I got the same issue with both rust stable (1.22.1) and rust nightly (1.24.0).

Thanks.
Repository: go
Issue: go/types: TestStdFixed test results are cached across $GOROOT/test changes
Labels: NeedsInvestigation

"go test go/types -run TestStdFixed" results may be cached by cmd/go even after changing files in $GOROOT/test. I noticed this by changing "ignored" to "package ignored" in test/fixedbugs/issue22877.go (in CL 80759), and repeated runs of go test still output "(cached)" pass results.

/cc @rsc @griesemer
Repository: TypeScript
Issue: Suggest specifying generic as union if candidates are different
Labels: Suggestion,Needs Proposal,Domain: Error Messages

<!-- 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:**  2.6.1.

**Code**

> If a generic type can't be formed by picking one of the inference candidates, you'll get the error you posted.

– https://stackoverflow.com/questions/39905523/why-isnt-the-type-argument-inferred-as-a-union-type/39905723#39905723

This makes sense, however I would like to question whether we can improve the user experience around this, so errors due to this constraint are easier to understand and fix.

For example:

```ts
{
    function compare<T>(x: T, y: T): number {
        return 1;
    }
    compare(
        'oops',
        /* Argument of type '42' is not assignable to parameter of type 'string'. */
        42,
    );
}

{
    function match<T>(cases: { foo: T; bar: T }): T {
        return cases.foo;
    }
    /*
    Argument of type '{ foo: number; bar: string; }' is not assignable to parameter of type '{ foo: number; bar: number; }'.
        Types of property 'bar' are incompatible.
            Type 'string' is not assignable to type 'number'.
    */
    match({
        foo: 1,
        bar: 'foo',
    });
}
```

As a TypeScript user, I have struggled with these errors many times, and I've only recently realised the specific constraint on the type system which is the root cause of these errors: generics are picked from the first candidate and are not widened to include all candidates. I have also seen other people struggle with this when learning TypeScript.

We can fix this error by specifying the generic as a union:

``` ts
    match<string | number>({
        foo: 1,
        bar: 'foo',
    });
```

However, this fix is really not obvious from the error message, especially if the user is not aware of this constraint on the type system (that generics will not be inferred as unions).

I'm wondering if there's any way we can better surface this constraint to the user, to make it clearer to users how they can fix these type errors, such as by specifying the generic as a union (if that is what they intend).
Repository: go
Issue: runtime: unsafe pointer maps
Labels: NeedsInvestigation,compiler/runtime

There are several places in the code where pointers are stored into slots that the pointer maps do not note as holding pointers. 

While the occurrences found so far appear benign with the current GC they do prevent adding diagnostics to the write barrier intended to detect errant writes. At the very least they should be documented as to why they are benign.
Repository: opencv
Issue: 'Segmentation fault' with gpu video decoding
Labels: bug,priority: low,category: gpu/cuda (contrib)

- OpenCV => 3.3.1-dev (github trunk: 29e4a4940dd81b22b26cbb51a2673d8c17f9f57d)
- Operating System / Platform => CentOS 7.3 64Bit
- Compiler => Default compiler on OS, gcc 4.8.5 20150623 (Red Hat 4.8.5-11)
- Cuda => 9.0
- GPU => 1080 Ti

I am trying 'samples/gpu/video_reader.cpp' to decode video using nvidia's gpu, but got 'segfault'. Cuda 9 now uses 'dynlink_nvcuvid.h' headers, and before that it uses 'nvcuvid.h'.

So I guess this must be something related to 'dynlink_nvcuvid.h'
Repository: bitcoin
Issue: Bitcoin is returning higher fees for 36 block window than 2 block window (on testnet)
Labels: TX fees and policy

In testnet, right now, `estimatesmartfee` is returning *higher* estimates for 36 block window than 2 block window. The results:

```
estimatesmartfee 2 ->
{
  "feerate": 0.01254483,
  "blocks": 2
}

estimatesmartfee 36 ->
{
  "feerate": 0.03863968,
  "blocks": 36
}


estimaterawfee 2 ->
{
  "short": {
    "decay": 0.962,
    "scale": 1,
    "fail": {
      "startrange": 490954,
      "endrange": 1e+99,
      "withintarget": 35,
      "totalconfirmed": 35.41,
      "inmempool": 165,
      "leftmempool": 0
    },
    "errors": [
      "Insufficient data or no feerate found which meets threshold"
    ]
  },
  "medium": {
    "feerate": 0.01254483,
    "decay": 0.9952,
    "scale": 2,
    "pass": {
      "startrange": 626596,
      "endrange": 1e+99,
      "withintarget": 38,
      "totalconfirmed": 38.96,
      "inmempool": 1,
      "leftmempool": 0
    },
    "fail": {
      "startrange": 596758,
      "endrange": 626596,
      "withintarget": 15.9,
      "totalconfirmed": 50.78,
      "inmempool": 14,
      "leftmempool": 0
    }
  },
  "long": {
    "decay": 0.99931,
    "scale": 24,
    "fail": {
      "startrange": 799713,
      "endrange": 1e+99,
      "withintarget": 138.78,
      "totalconfirmed": 147.56,
      "inmempool": 1,
      "leftmempool": 0
    },
    "errors": [
      "Insufficient data or no feerate found which meets threshold"
    ]
  }
}

estimaterawfee 36 ->
{
  "medium": {
    "feerate": 0.01254483,
    "decay": 0.9952,
    "scale": 2,
    "pass": {
      "startrange": 690822,
      "endrange": 1e+99,
      "withintarget": 37.33,
      "totalconfirmed": 38.19,
      "inmempool": 1,
      "leftmempool": 0
    },
    "fail": {
      "startrange": 596758,
      "endrange": 690822,
      "withintarget": 47.22,
      "totalconfirmed": 51.99,
      "inmempool": 12,
      "leftmempool": 0
    }
  },
  "long": {
    "decay": 0.99931,
    "scale": 24,
    "fail": {
      "startrange": 799713,
      "endrange": 1e+99,
      "withintarget": 139.47,
      "totalconfirmed": 147.66,
      "inmempool": 1,
      "leftmempool": 0
    },
    "errors": [
      "Insufficient data or no feerate found which meets threshold"
    ]
  }
}
```

I am also attaching fee_estimates.dat

[fee_estimates.dat.zip](https://github.com/bitcoin/bitcoin/files/1518545/fee_estimates.dat.zip)

Of course testnet is always "weird", but 36 block estimate being higher than 2 block estimate doesn't make sense, even on testnet.

The version of bitcoind is v0.15.0.0
Repository: go
Issue: sync: TestWaitGroupMisuse2 takes 45-90 seconds on netbsd, AIX
Labels: Testing,help wanted,OS-NetBSD,NeedsInvestigation,OS-AIX,compiler/runtime

TestWaitGroupMisuse2 on Linux with 8 cores takes 0.22s.

On NetBSD it does pass but takes 45-90 seconds. Why?

/cc @bsiegert
Repository: react
Issue: value|defaultValue={Symbol|Function} should be ignored, not stringified
Labels: Type: Bug,Difficulty: starter,Component: DOM,good first issue,React Core Team

Regression in master from https://github.com/facebook/react/pull/11534.
Found it thanks to the attribute fixture snapshots.
Repository: go
Issue: net: a better builtin DNS stub resolver
Labels: NeedsFix,umbrella

This is a meta bug for tracking the status of the issues regarding builtin DNS stub resolver.

- Refabrication
  - #16218
- Transport
  - #21160
  - #23866
  - #23873
  - #27552
- Labels
  - #7122
  - #9391
  - #10631
  - #10622
  - #17659
  - #22782
  - #22826
- RRs
  - #27546
- Error handling
  - #18588 
- Options
  - #6464
  - #13279
- Testing
  - #13295
Repository: go
Issue: x/net/publicsuffix: ICANN flag returns true for "za" domains not in the list 
Labels: NeedsInvestigation

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?
go version go1.9.2

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?
goos: darwin
goarch: amd64

### What did you do?

I tested domains such as "gli.za" not present in the public suffix list. 
https://play.golang.org/p/DaJICtp00J


### What did you expect to see?
I expected to have icann flag set to false, since the domain is not in the public suffix list.

// za : http://www.zadna.org.za/content/page/domain-information
ac.za
agric.za
alt.za
co.za
edu.za
gov.za
grondar.za
law.za
mil.za
net.za
ngo.za
nis.za
nom.za
org.za
school.za
tm.za
web.za

### What did you see instead?
icann flag set to true


I added debugging lines locally to check why the flag was being set and to see if there was a rule found. I saw that the code was going through the following steps (https://github.com/golang/net/blob/master/publicsuffix/list.go#L47):

1. Before the for loop icann flag is set to false
2. The for loop evaluates based on the nodes:
     - find za -> found -> icann is set to true
     - find gli -> not found -> break 
3. Return the last subdomain since no rules match (https://github.com/golang/net/blob/master/publicsuffix/list.go#L89)

Is this the expected behaviour? It seems like a corner case, given "za" is one of the rare domains in the list that does not include the base level ("za"), but only 2 level domains.
Repository: godot
Issue: Display a progress bar in the background of numerical properties in the Inspector and Project Settings
Labels: enhancement,topic:editor,usability

On the values of the Inspector and Project Settings, a progress bar in the background of numerical properties could be displayed. This would add some visual feedback (making visual grepping faster), as well as making adjustements by dragging the mouse more intuitive for users. The latter may require changing the dragging direction for adjustments (since bars are horizontal), though.

As seen in Blender:

![blender_slider_values](https://user-images.githubusercontent.com/180032/33496026-ec0d9a92-d6c8-11e7-9618-6c3bc89b9970.png)
Repository: go
Issue: cmd/go: add test -coverhtml
Labels: help wanted,Proposal,Proposal-Accepted,DevExp

(maybe this shouldn't be a proposal, it seems trivial enough that we should just do it?)

_Inspired by rakyll's suggestion in #16768._

I propose a small change to go test's "coverprofile" flag to output both the binary coverage format as well as HTML. The file extension passed in by the user would switch the output format (".html" for HTML, anything else for the existing behaviour).

This change is simple and highly unlikely to break existing users, unlike #16768, which suggests to add additional flags that overlap with "go tool cover" and can quickly descend into supporting more and more flags.

Before:
```
go test -coverprofile foo.out && go tool cover -html foo.out -o foo.html && rm foo.out
```

After:
```
go test -coverprofile foo.html
```
Repository: go
Issue: x/build: create mips32 soft-float builder
Labels: Builders,NeedsFix,new-builder

Commit 6be1c09 finished support for mips32 soft-float. We should have a builder configuration to test this.
Repository: go
Issue: encoding/json: bad encoding of field with MarshalJSON method 
Labels: NeedsDecision,early-in-cycle

Please answer these questions before submitting your issue. Thanks!

### What version of Go are you using (`go version`)?

version 1.9

### Does this issue reproduce with the latest release?

yes

### What operating system and processor architecture are you using (`go env`)?

windows/amd64

### What did you do?

```golang
package main

import (
	"encoding/json"
	"os"
)

type T bool

func (v *T) MarshalJSON() ([]byte, error) {
	return []byte{'1'}, nil
}

type S struct {
	X T
}

func main() {
	v := S{true}
	e := json.NewEncoder(os.Stderr)

	e.Encode(v)  // should print {"X":true}
	e.Encode(&v) // should print the same value
}
```

### What did you expect to see?

```json
{"X":true}
{"X":true}
```

### What did you see instead?

```json
{"X":true}
{"X":1}
```

### Issue

The `json.Marshal` documentation states that:

> Pointer values encode as the value pointed to. A nil pointer encodes as the null JSON value.

Thus, `&v` should be marshaled to the same JSON value as `v`:

```json
{"X":true}
```

Moreover, it states that:

> If an encountered value implements the Marshaler interface and is not a nil pointer, Marshal calls its MarshalJSON method to produce JSON.

Therefore, Marshal should not call the `MarshalJSON` method to produce JSON for the `X` field, because its `T` type does not implement the `json.Marshaler` interface. In fact, `MarshalJSON` has `*T` receiver and the Go documentation states:

> The method set of an interface type is its interface. The method set of any other type `T` consists of all methods declared with receiver type `T`. ... The method set of a type determines the interfaces that the type implements ...

As a final remark:

1. from the source code, the most relevant difference between cases `v` and `&v` is that `X` field becomes addressable in case `&v`, changing the encoding generated by `condAddrEncoder`;

1. implementing `MarshalJSON` with `T` value receiver makes `T` a `json.Marshaler` interface, with `X` values properly encoded by MarshalJSON:

    ```json
    {"X":1}
    {"X":1}
    ```

1. if the intended behavior is that Marshal should anyway call the `MarshalJSON` method on encoding `T` values, whenever `*T` implements the `json.Marshaler` interface, that should be clearly documented.