sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: runtime: TestLldbPython failing with 'no intvar'
Labels: Testing,NeedsFix

During all.bash, I 100% reproducibly get:

```
--- FAIL: TestLldbPython (7.82s)
    runtime-lldb_test.go:187: Unexpected lldb output:
        Created target
        Created breakpoint
        Process launched
        Hit breakpoint
        Stopped at main.go:10
        no intvar
FAIL
FAIL	runtime	35.143s
```

On macOS.

```
$ lldb --version
lldb-1001.0.12.1
  Swift-5.0
```

The builders aren't failing because of https://github.com/golang/go/issues/31123.

cc @heschik @aarzilli @thanm @dr2chase
Repository: pytorch
Issue: Add build tests for feature environment vars
Labels: todo,module: ci,triaged

We have quite a few feature toggle env vars. Sometimes, build error only emerges by setting specific feature vars (#18691 #18582). Shall we have build CI tests to cover all of them?
Repository: rust
Issue: Synchronization primitives not robust against unwinding
Labels: A-concurrency,C-bug,T-libs

Various synchronization primitives in `std` are not robust against unwinding triggered inside the `std` implementation. This may result in

* double panics
* deadlocks
* Mutexes being poisoned that shouldn't be

Such unwinding may be triggered in many different ways, for example:

* pthread_cancel on certain pthread implementations
* assertion/unwrap failure due to a variety of causes:
  * The kernel may return an unexpected error value from a system call
  * The libc implementation may return an unexpected error from a call
  * An unexpected return value due to the use of Linux [seccomp](https://lwn.net/Articles/656307/)
  * [Iago attacks](https://hovav.net/ucsd/dist/iago.pdf)

I've identified at least the following cases. Fixes for some of these have been proposed and rejected in #58042 and #58461.

| Primitive    | Unwind during blocking in | Failure occurs in     | Test case |
| ------------ | ------------------------- | --------------------- | --------- |
| MPSC oneshot | recv/recv_timeout         | Receiver drop         | https://github.com/jethrogb/rust/blob/95e8613d4e92f5f4b5487f2e7b4b936ea17d96d2/src/test/run-fail/mpsc-recv-unwind/oneshot.rs |
| MPSC sync    | recv/recv_timeout         | Receiver drop         | https://github.com/jethrogb/rust/blob/95e8613d4e92f5f4b5487f2e7b4b936ea17d96d2/src/test/run-fail/mpsc-recv-unwind/sync.rs |
| MPSC shared  | recv/recv_timeout         | Receiver drop         | https://github.com/jethrogb/rust/blob/95e8613d4e92f5f4b5487f2e7b4b936ea17d96d2/src/test/run-fail/mpsc-recv-unwind/shared.rs |
| MPSC stream  | recv/recv_timeout         | Receiver drop         | https://github.com/jethrogb/rust/blob/95e8613d4e92f5f4b5487f2e7b4b936ea17d96d2/src/test/run-fail/mpsc-recv-unwind/stream.rs |
| Condvar      | wait/wait_timeout         | wait                  | https://github.com/jethrogb/rust/blob/dd20f165ded66619ee040f5d819a4490fad3bd5c/src/test/run-pass/condvar-wait-panic-poison.rs |
| thread       | park/park_timeout         | park/ThreadInfo::with | https://github.com/rust-lang/rust/pull/58461#issuecomment-471787169 |
Repository: flutter
Issue: Add ability for text field TextInputAction to be dynamic
Labels: a: text input,c: new feature,framework,f: material design,P2,team-framework,triaged-framework

The textInputAction for a text field is hardcoded at creation of the field. I would like the ability for the text input action to change dynamically based on the content of the field. E.g. if the text field  has valid text in it, make the action show send, but if the field is blank, switch to done.
Repository: go
Issue: cmd/compile, runtime: reduce function prologue overhead
Labels: Performance,NeedsInvestigation,compiler/runtime

As of Go 1.12, the stack bound check in every function prologue looks like

```
MOVQ FS:0xfffffff8, CX
CMPQ 0x10(CX), SP
JBE 0x4018e4
```

(or some variation thereof). This involves a chain of three dependent instructions, the first two of which are memory loads and the last of which is a conditional branch. I don't have hard data for this, but I suspect this is really bad for the CPU pipeline. The two loads are absolutely going to be in cache, but the CPU still has to wait for the first load before issuing the second, and has to wait for the second before resolving the branch. The branch is highly predictable and can probably be speculated over, but since almost every single function has such a branch, it's probably somewhat likely the branch predictor cache will fail us here.

Function prologue overhead was also reported to be high in [The benefits and costs of writing a POSIX kernel in a high-level language](https://www.usenix.org/conference/osdi18/presentation/cutler) by Cutler et al.

One way we could address this is by putting the stack bound in a dedicated register (leveraging our new ability to change the internal ABI, #27539). This would make the prologue a single register/register compare and a branch. The branch would still probably have poor prediction cache locality, but the register/register comparison would happen so quickly that we would lose very little to a speculation failure. We're already moving toward implementing goroutine preemption using signals, which would make it easy to poison this stack bound register when requesting a preemption.

/cc @dr2chase @randall77 @josharian
Repository: TypeScript
Issue: 3.4 Regression on Type inference with union types
Labels: Needs Investigation

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.4.0-dev.201xxxxx

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** Type inference, discriminated union types

**Code**

```ts
type AllBoxes = ABox | BBox;

export interface ICanFindBoxes {
    findBoxes<T extends AllBoxes, K extends string>(boxName: K): T extends { type: K } ? T[] : never;
}

class Box<T extends string = string> implements ICanFindBoxes{
    type: T;
    
    public findBoxes<T extends AllBoxes, K extends string>(boxName: K): T extends { type: K } ? T[] : never {
      throw 'argg';
    }
   
}

export class ABox extends Box<'a'>{

}

export class BBox extends Box<'b'>{}
```

**Expected behavior:**
It compiles
**Actual behavior:**
Compile time error:
```sh
 Property 'findBoxes' in type 'Box<T>' is not assignable to the same property in base type 'ICanFindBoxes'.
  Type '<T extends AllBoxes, K extends string>(boxName: K) => T extends { type: K; } ? T[] : never' is not assignable to type '<T extends AllBoxes, K extends string>(boxName: K) => T extends { type: K; } ? T[] : never'. Two different types with this name exist, but they are unrelated.
    Type '(T extends { type: K; } ? T[] : never) | ({ type: K; } & ABox)[] | ({ type: K; } & BBox)[]' is not assignable to type 'T extends { type: K; } ? T[] : never'.
      Type '({ type: K; } & ABox)[]' is not assignable to type 'T extends { type: K; } ? T[] : never'.

11     public findBoxes<T extends AllBoxes, K extends string>(boxName: K): T extends { type: K } ? T[] : never {
```

The compiler is incorrectly identifying that the signatures are different when they are not.  If I simplify the union type to only one it works (but this defeats the purpose of the signature).

This was working in < 3.4.1
Repository: rust
Issue: Tracking issue for HashMap::extract_if and HashSet::extract_if
Labels: A-collections,T-libs-api,proposed-final-comment-period,C-tracking-issue,disposition-merge

The feature gate for the issue is `#![feature(hash_extract_if)]` (previously `hash_drain_filter`)

Currently only Vec and LinkedList have a drain_filter method, while other collections such as HashMap and HashSet do not.

This means that currently, removing items from a collection, and getting ownership of those items is fairly...unidiomatic and cumbersome.

For references, see https://github.com/rust-lang/rfcs/issues/2140


### Implementation History

- #76458
- removed drain-on-drop behavior, renamed to extract_if
   - #104455
   - https://github.com/rust-lang/libs-team/issues/136
Repository: go
Issue: strconv: document exact grammar of Parse{Float,Int,Uint}
Labels: Documentation,NeedsFix

`strconv.Parse{Float,Int,Uint}` is frequently used in the implementation of other grammars (e.g., [JSON](https://json.org/)), which may be a subset or superset of what `strconv.ParseX` currently does today. However, what `strconv.Parse` does today is not well-specified. What exactly is the input grammar that is accepted?

For example, the documentation for `ParseFloat` only says "If s is well-formed", but does not specify what "well-formed" means. I suspect that the answer to this is whether the input is well-formed according to the [grammar in the Go specification](https://golang.org/ref/spec#Floating-point_literals). If so, this needs to be documented.

Furthermore, this also opens the question for whether the input grammar is stable. Apparently, this is not the case since `strconv.ParseX` was recently augmented to support the new number literal grammars ([CL/160241](https://go-review.googlesource.com/c/160241) and [CL/160244](https://go-review.googlesource.com/c/160244)). This change is going to silently break a number of use-cases that were assuming that the input of `ParseX` was constrained to the grammar prior to Go1.13. If so, the instability of the input grammar should also be documented.

(BTW, I think the change in semantics is entirely reasonable and I support it; but I see a lot of code silently broken by this change. Documenting this better would help dissuade future abuse.)

\cc @cybrcodr, @griesemer, @rsc
Repository: TypeScript
Issue: Support custom typeof functions
Labels: Suggestion,Awaiting More Feedback

## Search Terms

- custom typeof
- custom typeof function
- custom type guard

## Suggestion

When using a&nbsp;custom `typeof`&#x2011;like function, I’d like TypeScript compiler to be able to infer the correct type in the scope guarded by the custom `typeof`&#x2011;like function.

## Use Cases

I need this to provide proper type information for the [`type` function from Blissfuljs](https://blissfuljs.com/docs.html#fn-type) and similar projects.

The&nbsp;current approach requires defining the&nbsp;`type(…)`&nbsp;function as&nbsp;<code>type(obj:&nbsp;any):&nbsp;string</code> and&nbsp;then doing a&nbsp;type&nbsp;cast every time `something` is&nbsp;accessed within the `if`&nbsp;block:
```ts
/// <reference types="blissfuljs"/>
declare var something: any;
if ($.type(something) === "array") {
	(something as any[]).forEach(v => {/* stuff */})
}
```

## Examples

<details><summary><code>type-func.d.ts</code></summary>
<br/>

```ts
/**
 * @param obj The variable to check the type of.
 * @return The result of `typeof obj` or the class name in lowercase for objects.
 *         In the case of numbers, if the value is `NaN`, then the result is `nan`.
 */
declare function type(obj: null): "null";
declare function type(obj: undefined): "undefined";

// This is to ensure that the type system short-circuits when it encounters primitive types.
declare function type(obj: number): "number" | "nan";
declare function type(obj: string): "string";
declare function type(obj: symbol): "symbol";
declare function type(obj: boolean): "boolean";

// Needed to ensure proper return values when wrapper objects are used.
/* tslint:disable:ban-types */
declare function type(obj: number | Number): "number" | "nan";
declare function type(obj: string | String): "string";
declare function type(obj: symbol | Symbol): "symbol";
declare function type(obj: boolean | Boolean): "boolean";
declare function type(obj: Function): "function";
/* tslint:enable:ban-types */

declare function type(obj: any[]): "array";
declare function type(obj: RegExp): "regexp";
declare function type(obj: any): string;
export = type;
```
</details>

`example.ts`
```ts
import type = require("./type-func");
declare var something: any;

if (type(something) === "array") {
	// $ExpectType any[]
	something;
} else if (type(somthing) === "number") {
	// $ExpectType number
	something;
}
```

## Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: go
Issue: cmd/compile: unexpected difference in compiled code for returned array
Labels: NeedsInvestigation,binary-size,compiler/runtime

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.12 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes.

### What did you do?
I compiled this code:
```go
package test

func test() [16]byte {
    x := [16]byte{0}

    return x
}
```

### What did you expect to see?
I expected the generated assembly code to be similar to this program's code:
```go
package test

func test() [16]byte {
    x := [16]byte{1}

    return x
}
```

### What did you see instead?
Instead, the generated code is much more bloated than I anticipated, even involving stack movement.
```asm
        subq    $24, SP
        movq    BP, 16(SP)
        leaq    16(SP), BP

        xorps   X0, X0
        movups  X0, "".~r0+32(SP)
        movups  X0, "".x(SP)
        movups  "".x(SP), X0
        movups  X0, "".~r0+32(SP)
        movq    16(SP), BP
        addq    $24, SP
        ret
```

As pointed out by @vcabbage, this issue is probably related to the assignment to "x", given that the compiler produces better code for the following program:
```go
package test

func test() [16]byte {
    return [16]byte{0}
}
```

Another interesting case is the one below, where the "good" case above becomes as bad as the "bad" one:
```go
package test

func test() [16]byte {
    x := [16]byte{1}
    y := x

    return y
}
```
Repository: go
Issue: cmd/compile: add line numbers for function exit paths?
Labels: NeedsInvestigation,Debugging,compiler/runtime

Noticed while looking at https://github.com/golang/go/issues/31193.

```go
func count(x uint) {
	if x != 0 {
		count(x - 1)
	}
}
```

compiles to:

```
"".count STEXT size=70 args=0x8 locals=0x10
	0x0000 00000 (count_test.go:8)	TEXT	"".count(SB), ABIInternal, $16-8
	0x0000 00000 (count_test.go:8)	MOVQ	(TLS), CX
	0x0009 00009 (count_test.go:8)	CMPQ	SP, 16(CX)
	0x000d 00013 (count_test.go:8)	JLS	63
	0x000f 00015 (count_test.go:8)	SUBQ	$16, SP
	0x0013 00019 (count_test.go:8)	MOVQ	BP, 8(SP)
	0x0018 00024 (count_test.go:8)	LEAQ	8(SP), BP
	0x001d 00029 (count_test.go:9)	MOVQ	"".x+24(SP), AX
	0x0022 00034 (count_test.go:9)	TESTQ	AX, AX
	0x0025 00037 (count_test.go:9)	JNE	49
	0x0027 00039 (<unknown line number>)	MOVQ	8(SP), BP
	0x002c 00044 (<unknown line number>)	ADDQ	$16, SP
	0x0030 00048 (<unknown line number>)	RET
	0x0031 00049 (count_test.go:10)	DECQ	AX
	0x0034 00052 (count_test.go:10)	MOVQ	AX, (SP)
	0x0038 00056 (count_test.go:10)	CALL	"".count(SB)
	0x003d 00061 (count_test.go:10)	JMP	39
	0x003f 00063 (count_test.go:8)	CALL	runtime.morestack_noctxt(SB)
	0x0044 00068 (count_test.go:8)	JMP	0
```

Note the `<unknown line number>` entries. It seems to me that those could be attributed to the closing brace of the function: It is code executed as the function exits.

I don't know whether adding line numbers here would be good or bad for debugging, or good or bad for binary size. I just thought I'd mention it in case @dr2chase sees an opportunity here. If not, we can close.
Repository: godot
Issue:  Opengles 2.0 BUG BackBufferCopy child node, change the ZIndex buffer to screen cache. BackBuffer Copy cannot be sampled correctly
Labels: bug,topic:rendering,confirmed

**Godot version:**
3.2 dev


**OS/device including version:**
windows N 1080ti  opengles 2.0


**Issue description:**

BackBufferCopy child node, change the ZIndex buffer to screen cache. BackBuffer Copy cannot be sampled correctly
Repository: rust
Issue: Thread locals keep Rust shared library from unloading `dlclose`.
Labels: O-linux,A-thread-locals,C-bug,T-libs

OS: Ubuntu 18.04
Doesn't seem to happen on Windows, untested on MacOS.

I created [`cr-sys`](https://github.com/Neopallium/cr-sys) crate to wrap [cr.h: A Simple C Hot Reload Header-only Library](https://github.com/fungos/cr).

It works, except that each version of the plugin isn't unloaded correctly, if the plugin uses TLS destructors registered with `__cxa_thread_atexit_impl`.

C++ plugins can be compiled with `-fno-use-cxa-atexit` to disable the use of `__cxa_thread_atexit`.  But I can't find away to do this with Rust plugins.

Right now the only work around is to not unload old plugin and make sure to use a different name for each plugin version.

Is there any way to run the TLS destructors registered by the plugin or to disable TLS destructors for a Rust shared library?

Related issue on `cr.h`:
https://github.com/fungos/cr/issues/35
Repository: scrcpy
Issue: flatpak package
Labels: distrib

Hi，I have packaged scrcpy with flatpak.You can find it in https://github.com/12wk34/scrcpy-flatpak
Could you add it to flathub.org cause they require the developer to do it.
The more information about app submission: https://github.com/flathub/flathub/wiki/App-Submission
Repository: kubernetes
Issue: single-use controller config defaults should auto-apply
Labels: priority/backlog,kind/cleanup,lifecycle/frozen,wg/component-standard

The functions added in https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/apis/config/v1alpha1/defaults.go#L68-L105 should be normal defaults. The "RecommendedDefaults" helper function approach was only needed for config structs used in multiple contexts (like client configuration, rate limiting, leader election, etc).

The controller-specific config structs should use normal defaulting functions so we don't have to remember to wire them up in every use.

/cc @stewart-yu
Repository: go
Issue: x/tools/cmd/goimports: do not prefix packages from GOROOT if it is inside a module
Labels: help wanted,NeedsFix,Tools

### What version of Go are you using (`go version`)?

<pre>
go version go1.12beta2 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes.

### What operating system and processor architecture are you using (`go env`)?

<details>
<pre>
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/dottedmag/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/dottedmag/go"
GOPROXY=""
GORACE=""
GOROOT="/Users/dottedmag/tectonic/_deps/go-1.12beta2"
GOTMPDIR=""
GOTOOLDIR="/Users/dottedmag/tectonic/_deps/go-1.12beta2/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/bw/6hyp_vyj68v973qbhlbcvlcr0000gn/T/go-build721712428=/tmp/go-build -gno-record-gcc-switches -fno-common"
</pre>
</details>

### What did you do?

I have a `GOROOT` inside a module (a per-repository Go installation for a hermetic build).

I run `goimports`, it tries to resolve a package (say, `reflect`), it loads packages from `GOROOT`, and they end up being prefixed with a path inside the current module.

### What did you expect to see?

```
package mypkg

import "reflect"

type x reflect.Type
```

### What did you see instead?

```
package mypkg

import "my.module/_deps/go-1.12beta2/src/reflect"

type x reflect.Type
```

### How to fix

[Patch redacted by @bcmills. Please send a PR or CL so that we can verify CLA compliance.]
Repository: pytorch
Issue: MaxPool with n-dimensional tensors
Labels: module: nn,triaged,enhancement,module: pooling

## 🚀 Feature: 
Currently `MaxPoolxd(...)` accepts only up to `x+2`-dimensional input tensors. 
The idea is to make `MaxPool` to work with any `n`-dimensional tensor, such that the maxpooling operation is applied only on the last `x` dimensions.

## Motivation

It can be useful to avoid verbose reshaping from/to the required shape of `MaxPool`.


## Alternatives

For `MaxPool2d`, this is what I'm currently doing. It's pretty verbose and it can be better rewritten but it does work with any `n`-dimensional input tensor.

```python
import torch
from torch.nn.modules.pooling import _MaxPoolNd

class GenericMaxPool2d(_MaxPoolNd):
    def forward(self, input):
        input_shape = input.shape
        c = input.shape[-3]
        h_in = input.shape[-2]
        w_in = input.shape[-1]
        input = input.view(-1, c, h_in, w_in)
        output = torch.nn.functional.max_pool2d(input, self.kernel_size, self.stride,
                            self.padding, self.dilation, self.ceil_mode,
                            self.return_indices)
        h_out = output.shape[-2]
        w_out = output.shape[-1]
        return output.view(*input_shape[:-3], c, h_out, w_out)
```



cc @albanD @mruberry
Repository: pytorch
Issue: Numerical instability KL divergence RelaxedOneHotCategorical
Labels: module: numerical-stability,module: distributions,triaged

## 🐛 Bug

It seems that computing the KL divergence RelaxedOneHotCategorical leads to numerical instabilities.

## To Reproduce

```python
import torch
from torch.distributions import RelaxedOneHotCategorical


p_m = RelaxedOneHotCategorical(torch.tensor([2.2]), probs=torch.tensor([0.1, 0.2, 0.3, 0.4]))
batch_param_obtained_from_a_nn = torch.rand(2, 4)
q_m = RelaxedOneHotCategorical(torch.tensor([5.4]), logits=batch_param_obtained_from_a_nn)

z = q_m.rsample()

kl = - torch.mean(q_m.log_prob(z).exp() * (q_m.log_prob(z) - p_m.log_prob(z)))

z                                                                                                                                                                                                                                                                       
tensor([[0.2671, 0.2973, 0.2144, 0.2212],
        [0.2431, 0.2550, 0.3064, 0.1954]])

kl                                                                                                                                                                                                                                                                      
tensor(-766.7020)
```

## Expected behavior

KL divergence grows to much


## Environment

 - PyTorch Version (e.g., 1.0): 1.1
 - OS (e.g., Linux): Mac
 - How you installed PyTorch (`conda`, `pip`, source): pip
 - Python version: 3.7