sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: gccgo: oddity with export data and init functions
Labels: NeedsInvestigation

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

gccgo tip
<pre>
$ go version
go version go1.13 gccgo (GCC) 10.0.0 20190916 (experimental) linux/amd64
</pre>

### Does this issue reproduce with the latest release?

yes


### What operating system and processor architecture are you using (`go env`)?

linux/amd64

### What did you do?

Compile this package with gccgo:

<pre>
package c

import "sort"

func init() {
	sort.Sort(byMaskLength(xpolicyTable))
}

type byMaskLength []policyTableEntry

func (s byMaskLength) Len() int           { return len(s) }
func (s byMaskLength) Swap(i, j int)      { s[i], s[j] = s[j], s[i] }
func (s byMaskLength) Less(i, j int) bool { return s[i].Label < s[j].Label }

type policyTableEntry struct {
	Label int
}

type policyTable []policyTableEntry

var xpolicyTable = policyTable{}

//go:noinline
func F() int {
	return xpolicyTable[0].Label
}
</pre>

### What did you expect to see?

Expected a single entry

func F () <type -11>

in the export data for the package, since that is the only exported identifier.

## What did you see instead?

Export data includes the 'byMaskLength' type and its associated methods, which was a surprise.

I poked around at this and discovered that the lowering phase is running inlinabliity analysis on init functions, and it decides as part of this that the init() function is inlinable. This means that we include the types reachable from it in the export data (even though the init function itself is not emitted as an inline candidate.
Repository: kubernetes
Issue: Kubernetes API server stuck on metrics server API service discovery check failure
Labels: kind/bug,sig/api-machinery,sig/instrumentation,lifecycle/frozen,triage/accepted

**What happened**:

Occasionally, the metrics server API service `v1beta1.metrics.k8s.io` fails discovery after cluster creation.  The discovery checks often continue failing until the API service is deleted and recreated.  Sometimes, discovery will eventually succeed without intervention but this could take 30 or more minutes.  This problem primarily impacts Kubernetes v1.15, but has been seen at least once on Kubernetes v1.16.  In addition to recreating the API service to resolve the problem, adding a liveness and readiness probe to https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/metrics-server/metrics-server-deployment.yaml usually prevents the discovery failure loop.

Example `v1beta1.metrics.k8s.io` API service status:

```
status:
  conditions:
  - lastTransitionTime: "2019-09-28T20:11:14Z"
    message: 'failing or missing response from https://172.21.13.79:443/apis/metrics.k8s.io/v1beta1:
      Get https://172.21.13.79:443/apis/metrics.k8s.io/v1beta1: net/http: request
      canceled (Client.Timeout exceeded while awaiting headers)'
    reason: FailedDiscoveryCheck
    status: "False"
    type: Available
```

See comments for example Kubernetes API server and metric server pod log error messages during discovery failure loop.

**What you expected to happen**:

Metrics server API service `v1beta1.metrics.k8s.io` discovery succeeds after cluster creation. 

**How to reproduce it (as minimally and precisely as possible)**:

Reproducing the problem is not easy since it appears to be timing related with respect to API server discovery of metrics server API service.

**Anything else we need to know?**:

No.

**Environment**:
- Kubernetes version (use `kubectl version`): Primarily v1.15.x, although seen once on v1.16.0
- Cloud provider or hardware configuration: IBM Cloud Kubernetes Service
- OS (e.g: `cat /etc/os-release`): Ubuntu 18.04.3 LTS
- Kernel (e.g. `uname -a`): 4.15.0-64-generic
- Install tools: Cloud provider managed service install tools
- Network plugin and version (if this is a network-related bug): Calico v3.8.2
- Others: None.
Repository: flutter
Issue: [web] Support scrolling inside the text field
Labels: a: text input,framework,f: scrolling,platform-web,P2,team-web,triaged-web

There are 2 situations where the text field can scroll:
1. Very long text in a single-line text field (horizontal scrolling).
2. Many lines of text in a multi-line text field (vertical scrolling).

Currently, the scrolling works fine but the issue is that Flutter's field and the browser's field get out of sync, and they are scrolled to different positions.
Repository: flutter
Issue: [web] Support line height + word spacing in text fields
Labels: a: text input,c: new feature,framework,platform-web,P3,team-web,triaged-web

TextInput.setStyle method call informs the engine about the styling info of an editable text.

This method does not support line height and word spacing.
Repository: pytorch
Issue: [jit] Document what types can be traced
Labels: oncall: jit,triaged,jit-backlog

Our `torch.jit.trace` docs don't mention that `Dict[str, Tensor]` can be traced, nor that NamedTuples cannot be traced

cc @suo
Repository: TypeScript
Issue: Allow circular references of project references
Labels: Suggestion,Awaiting More Feedback

## Search Terms

circular reference project references graph

## Suggestion

Currently, project reference graphs are required to be acyclical because
 * Project references *imply* a `.d.ts` file is loaded, and `.d.ts` files can't exist before the build occurs
 * Only acyclic graphs can be topologically sorted

Both of these problems are solvable without too much work.

With the work done in #32028, we can effectively toggle the redirecting behavior, fixing the first issue. This would be done during the *initial* build phase only when an upstream project dependency isn't built yet.

The other problem is that project build order might not be predictable if we arbitrarily pick some starting point in the unsortable graph. This is fixable if we force solution authors to indicate which edges in the graph should be treated as ignored for the purposes of the topological sort:

```
    "references": [
        { "path": "../a" },
        { "path": "../b", "circular": true },
                          ^^^^^^^^^^^^^^^^
        { "path": "../c" }
    ],
```

The benefits of this are:
 * In case of suboptimal `.d.ts` generation or memory pressure, developers can control where the "weak" link occurs in the build process
 * The build ordering is fully deterministic regardless of starting point
 * Graphs can't become "accidentally" circular - this is a clear opt-in

## Use Cases

`npm` and other package managers *do* allow circularities in dependency graphs, so this is apparently a thing.
We've also gotten feedback from some industry partners that they want to move to project references, but their dependency graph is circular in a way that would require a lot of work to "fix".

## Examples

Given the graph:
```
A -> B -> C -(circular)-> A
```

The build order is deterministically `C`, `B`, `A`. During `C`'s compilation, source file redirects from `C` to `A` are not active.

## 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: pytorch
Issue: [c10] c10 dispatch doesn't support tracing of scalars
Labels: module: internals,triaged,module: dispatch

Example:
```
import torch

def foo(x):
    return torch.ops.quantized.add_scalar(x, 3)

x = torch.quantize_per_tensor(torch.rand(3, 4), 0.01, 0, torch.qint8)

torch.jit.trace(foo, (x,))
```

Results in the following error
```
RuntimeError: unsupported input type: Scalar
```

That traces back to this line: https://github.com/pytorch/pytorch/blob/master/torch/csrc/jit/register_c10_ops.cpp#L175

However, normal ATen ops support this functionality. Take `__ilshift__` as an example:

```
import torch

def foo(x):
    return x << 3

#x = torch.quantize_per_tensor(torch.rand(3, 4), 0.01, 0, torch.qint8)
x = torch.rand(3, 4)

traced = torch.jit.trace(foo, (x,))
print(traced.graph)
```
Which works and prints the following graph:
```
graph(%x : Float(3, 4)):
  %1 : int = prim::Constant[value=3]() # trace_sa2.py:4:0
  %2 : Float(3, 4) = aten::__lshift__(%x, %1) # trace_sa2.py:4:0
  return (%2)
```

We should have this functionality in tracing c10 ops

cc @ezyang @gchanan @zou3519 @jerryzh168 @jianyuh @dzhulgakov @raghuramank100
Repository: pytorch
Issue: Support implicit RRef type conversion
Labels: triaged,module: rpc

Currently, `dist.rpc` and `dist.remote` only matches arguments with exact types. We should support implicit RRef type conversion as described in #23110 (i.e. `T->RRef[T]` and `RRef[T] -> T`). 

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini
Repository: react
Issue: Devtools Inspect Button Doesn't Work with Repeat Selections
Labels: Component: Developer Tools,React Core Team

Maybe we can detect this case by checking $0 and if not we can temporarily select null before reselecting. (?)
Repository: godot
Issue: GLES2 MSAA implementation relies on platform-defines instead of feature-based ones
Labels: bug,enhancement,discussion,topic:rendering,topic:porting,confirmed

**Godot version:**
master

**Issue description:**
in https://github.com/godotengine/godot/blob/bd74084e2fb431e8ef0ea3150ca82a4499f54bfb/drivers/gles2/rasterizer_storage_gles2.cpp#L4687 , there's a bunch of platform specific blocks to implement MSAA differently depending on the platform. We need to change it to be platform independent, by naming the features and not the platforms. For example:

```
#ifdef MSAA_FEATURE_1
// do msaa using feature 1
#elif MSAA_FEATURE_2
// do msaa using feature 2
#endif
```

Then in platform_config.h for each platform, we enable the right define to get the desired code for the platform. This allows new platforms to be implemented without having to touch this code, which should be platform-independent.

I'm opening an issue instead of a pull request because I don't know the specifics of what's being used there, I'll talk to @clayjohn and @Faless about it
Repository: go
Issue: cmd/go: error for unset $GOPATH when GOROOT is $HOME/go is unhelpful
Labels: NeedsInvestigation,GoCommand

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.13.1 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN="/home/user/bin"
GOCACHE="/home/user/.cache/go-build"
GOENV="/home/user/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/user"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/user/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/user/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build291059786=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->
Unset GOPATH and have the go source tree located at $HOME/go.
Then run the go tool to do something, e.g. `go env`.

### What did you expect to see?
An informative error message.

### What did you see instead?
"missing $GOPATH"

### Additional information

See https://groups.google.com/d/topic/golang-nuts/D7wk6Mb6bZI/discussion

Note that while this is superficially similar to #29341, the fix at https://golang.org/cl/158257 will not fix this.
Repository: TypeScript
Issue: Allowing subsequent property declarations of compatible types
Labels: Suggestion,Needs Proposal

## Search Terms

TS2717, subsequent property declarations

## Suggestion

Let's assume following code:

Library typings:

```typescript
interface Dictionary<T> {
   [key: string]: T;
}
interface Foo {
   methods: Dictionary<Function>;
}
```

User extension:
```typescript
declare module "@awesome/library" {
     interface BagOfFunctions extends Dictionary<Function> {
         wellKnownFunction(foo: number): number;
     }
     
     interface Foo {
           methods: BagOfFunctions;
      }
}

````

Currently, it results in TS2717.  After this change, such code will be allowed.

## Use Cases

Use case: Hapi allow user to define global functions with shared cache ([`server.method`](https://hapi.dev/api/?v=18.4.0#-servermethodname-method-options)).

Unfortunely, `server.methods` is currently defined as `Dictionary<ServerMethod>` and end users aren't able to get type safety when calling them.

## 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: scrcpy
Issue: MediaCodec$CodecException: Error 0xfffffff4
Labels: codec

Hi,

I am facing the following error on a custom ROM ... and i am connected over wifi adb 

```
$ scrcpy
INFO: scrcpy 1.10 <https://github.com/Genymobile/scrcpy>
/usr/local/share/scrcpy/scrcpy-server.jar: 1 file pushed. 0.1 MB/s (22546 bytes in 0.146s)
adb: error: more than one device/emulator
ERROR: "adb reverse" returned with value 1
WARN: 'adb reverse' failed, fallback to 'adb forward'
27183
INFO: Initial texture: 1536x2048
[server] ERROR: Exception on thread Thread[main,5,main]
android.media.MediaCodec$CodecException: Error 0xfffffff4
	at android.media.MediaCodec.native_configure(Native Method)

```
Repository: TypeScript
Issue: Array.isArray refinement loses the array's type
Labels: Suggestion,Needs Proposal,Fix Available

I realize there are a number of related issues. However, some where about ReadonlyArray, some didn't see directly related at all even though it was pointed there.

Also, this is a much smaller example, just a single line of code really:

[Playground link](http://www.typescriptlang.org/play/index.html#code/GYVwdgxgLglg9mABAEwKYFs4AoZQFyICSUqATgIYBGANqgDxgjqVkB8AlAY82QNoC6iAN4AoROMQQEAZyiJypCgE9EAXkQBBReSUA6GNK3KcUdogD8iXIgK9d93PwDcIsRID07xABFU1GCwUJFy6tGAA5lAAFlbS8oiypDARiOio0XDIADSIlCByYHCIZKRwpLmoEOQg0qiIcMCIUEoADnUARORgSu2IwGWIYG7ipOkgpEgKyrro5C1YSKqsg6GoEdHsLgC+IkA)

I know people will point to this ir that implementation or design decision detail — honestly guys, you got it REVERSED. The tool should serve the purpose, not the other way around!

That the array loses all it's type information in such a simple example is A BUG.

And it is possible to do much better: See here! I'm only pointing this out because at times the responses sound like "We tried everything but it is just not possible" when the competition shows that it is actually quite possible.

Related(?): #17002
Repository: go
Issue: proxy.golang.org: improve the last FAQ entry about module retention
Labels: NeedsFix,proxy.golang.org

The last entry currently states that 

> **Why did a previously available module become unavailable in the mirror?**
> proxy.golang.org does not save all modules forever. There are a number of reasons for this, but one reason is if proxy.golang.org is not able to detect a suitable license. In this case, only a temporarily cached copy of the module will be made available, and may become unavailable if it is removed from the original source and becomes outdated.
>

- Clarify what "suitable" licenses are and how license detection works.
- Provide a way to easily check whether the mirrored copy is available or not.
- Link to other potential solutions for module versions proxy.golang.org cannot retain forever.

@myitcv @katiehockman @heschik
Repository: vscode
Issue: API to toggle between flat tree (list) and tree for custom view
Labels: feature-request,api,tree-views

Context: https://github.com/microsoft/vscode-references-view/pull/54
Repository: godot
Issue: Multi-threading related crash during play in Label::regenerate_word_cache
Labels: bug,topic:core,confirmed,crash,topic:gui

**Godot version:** 3.1.1 Mono

**OS/device including version:** Windows 10 64bit

**Issue description:**
I am using Mono in a project right now. It worked fine until lately. The player is now randomly crashing without any of my C# code running. The player just crashes after a few seconds - minutes. Its unpredictable when it happens and it gives no real error message, just the standard socket exception:
```
drivers/unix/net_socket_posix.cpp:190 - Socket error: 10054
** Debug Process Stopped **
```
The latest things I added to the project before it happened:
- A few more multitasking with Tasks - but unrelated as it can happen before it gets there
- New sound playback system

Things I changed on my system:
- Installed new version of RivaTuner - Tested without it running -> still crashing
- Disabled GSync - That shouldn't affect it
- Automated cleaning of standby RAM every 5 minutes - Happens more often than that

Verbose logging of the player is activated, but that does not indicate any error

mono logs often have a `GC_MAJOR_CONCURRENT_START: (LOS overflow) (in domain Mono, info)` at the end whenever a crash happend though

It seems to happen more often when you resize the window. It also seems like to happen more often when you change the size of GUI elements, like a box container or a label.

**Steps to reproduce:**
 - unknown -

**Minimal reproduction project:**
 - unknown -
There is only my current project which has the error
Repository: pytorch
Issue: CUDAPytorchToCaffe2.MutualResizes is flaky
Labels: caffe2-op,module: cuda,module: tests,triaged,module: flaky-tests

```
Oct 01 01:05:15 [       OK ] CUDAPytorchToCaffe2.SharedStorageWrite (0 ms)
Oct 01 01:05:15 [ RUN      ] CUDAPytorchToCaffe2.MutualResizes
Oct 01 01:05:15 /var/lib/jenkins/workspace/aten/src/ATen/test/cuda_tensor_interop_test.cpp:151: Failure
Oct 01 01:05:15 Expected equality of these values:
Oct 01 01:05:15   at_tensor[0][2].item().to<float>()
Oct 01 01:05:15     Which is: 1
Oct 01 01:05:15   345
Oct 01 01:05:15 [  FAILED  ] CUDAPytorchToCaffe2.MutualResizes (0 ms)
Oct 01 01:05:15 [----------] 3 tests from CUDAPytorchToCaffe2 (2 ms total)
Oct 01 01:05:15 
```

https://app.circleci.com/jobs/github/pytorch/pytorch/3014740
Repository: flutter
Issue: Text layout without blocking the UI
Labels: framework,engine,c: performance,dependency: skia,a: typography,perf: speed,P2,team-engine,triaged-engine

There are a number of bugs that I've seen that boil down to this: if you have a large chunk of text, laying it out may be expensive enough where it blocks the UI for an unacceptable amount of time.  One work around for this is to try to break up your text into smaller chunks, which works if you already have natural breaks (e.g. many small paragraphs laid out individually instead of all at once), but doesn't work as well if you just have a really long paragraph you want to layout and you don't know where the line breaks will fall. This may be a problem for, e.g. a reader for an academic journal that just has long paragraphs, or perhaps in some other languages where longer paragraphs may be more common.

It is not currently possible to layout text in a separate isolate, as all dart:ui methods must run in the main isolate. We should explore either making it possible to run in another isolate, or creating some async text layout methods.

Here are some example issues:

#23718
#30604
#41536 (not as strongly related but may be helped by such an API)

/cc @GaryQian @jason-simmons
Repository: flutter
Issue: [camera] Add macOS support
Labels: c: new feature,platform-mac,p: camera,package,a: desktop,P3,team-macos,triaged-macos

Since laptops commonly have cameras built in, this would be potentially useful.

~Blocked on #30717~
Repository: flutter
Issue: [camera] Add Linux support
Labels: c: new feature,platform-linux,p: camera,package,a: desktop,P3,team-linux,triaged-linux

Since laptops commonly have cameras built in, this would be potentially useful.

~Blocked on https://github.com/flutter/flutter/issues/64188~
Repository: pytorch
Issue: torch::jit::script::Module has no zero_grad()
Labels: oncall: jit,triaged,jit-backlog

## 🐛 Bug

I'm writing a C++ program that loads a module from disk and tries to work with it.  Unlike `nn::Module`, it appears that `torch::jit::script::Module` has no `zero_grad()` method.  This makes it impossible to do optimization.

## Environment

 - PyTorch Version (e.g., 1.0): Nightly build downloaded Sept. 29, 2019
 - OS (e.g., Linux): Linux
 - How you installed PyTorch (`conda`, `pip`, source): Downloaded from https://download.pytorch.org/libtorch/nightly/cu101/libtorch-cxx11-abi-shared-with-deps-latest.zip
 - Build command you used (if compiling from source): n/a
 - Python version: n/a
 - CUDA/cuDNN version: n/a
 - GPU models and configuration: n/a
 - Any other relevant information:


cc @suo