sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: QuickInfo misleading with signatures from higher order function type inference
Labels: Bug,Domain: Type Display,Domain: Quick Info

<!-- 🚨 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.20190313

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

**Code**

```ts
interface T1 {}

declare function pipe2<A, B, C, D>(ab: (a: A) => B, cd: (c: C) => D): (a: [A, C]) => [B, D];
declare function list<T extends T1>(a: T): T[];
declare function box<T extends T1>(x: T): { value: T };

const listBox = pipe2(list, box);
```

**Expected behavior:**

Propagated type parameters should be renamed if a different type with the same name is used in the constraint or initializer of any other propagated type parameter.

For example: `<T extends T1, T2 extends T1>`.

**Actual behavior:**

Hovering over `listBox` displays `const listBox: <T extends T1, T1 extends T1>(a: [T, T1]) => [T[], {value: T1;}]`

Note the `T1 extends T1` and `T extends T1` where `T1` refers to something completely different.

This is not limited to renamed type parameters. Hovering over `listBox` in the following code displays circular type parameter constraints (`<T extends V, V extends T>`) without any renaming going on:

```ts
interface T {}
interface V {}

declare function pipe2<A, B, C, D>(ab: (a: A) => B, cd: (c: C) => D): (a: [A, C]) => [B, D];
declare function list<T extends V>(a: T): T[];
declare function box<V extends T>(x: V): { value: V };

const listBox = pipe2(list, box);
```
Repository: kubernetes
Issue: Vsphere Cloud Provider: failed to detach volume from shutdown node
Labels: kind/bug,priority/important-soon,lifecycle/frozen,area/provider/vmware,sig/cloud-provider,needs-triage

**What happened**:
I have a pod with a pv attached to it running on node1.
When I shutdown node1 to simulate node-failure, Kubernetes detects the unhealthy node in the configured timeframe and tries to re-schedule the pod on node2 following the --pod-eviction timeout.
When trying to start the pod on node2, the pv can not be attached as it is still attached to the shutdown node1:
```
  Warning  FailedAttachVolume      6m               attachdetach-controller  Multi-Attach error for volume "pvc-db44144b-457f-11e9-a7b0-005056af6878" Volume is already exclusively attached to one node and can't be attached to another
```
Also, the pod on the shutdown node does not get deleted.

**What you expected to happen**:
As documented [here](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/high-availability.html):
The disk should be detached from the shutdown node and attached to the new node where the pod is scheduled on

**How to reproduce it (as minimally and precisely as possible)**:
1. Schedule single pod using pvc on node1
1. Shutdown node1
1. Watch FailedAttachVolume event on the new pod on node2

**Anything else we need to know?**:
Also, kube-controller-manager does not log anything about this failure.
Detachment and attachment to another nodes works fine, as long as all nodes are healthy.
Force-deletion of the pod on the shutdown node also does nothing.

**Environment**:
- Kubernetes version (use `kubectl version`): 1.12.5
- Cloud provider or hardware configuration: vsphere
- OS (e.g: `cat /etc/os-release`): Ubuntu 16.04
- Kernel (e.g. `uname -a`): Linux k8s-dev-master3 4.4.0-139-generic #165-Ubuntu SMP Wed Oct 24 10:58:50 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
- Install tools: Kubespray 2.8.3 using kubeadm
- Others: VSphere 6.5

Thanks in advance! :)
Repository: flutter
Issue: Provide a way to print the Navigator inner stack
Labels: c: new feature,framework,f: routes,customer: crowd,c: proposal,P3,team-framework,triaged-framework

It would be nice to have a way to print the `Navigator` current stack, so we can check if it's being built in the way we imagine, or if there are some stray screens there, that shouldn't, or if we are replacing the wrong screen in a `pushAndRemoveUntil`.

something like:

```
Navigator.of(context).printStack();
```
Repository: material-ui
Issue: Equivalent to Blueprint's RunningText
Labels: new feature,waiting for 👍,component: Typography

A `<RunningText>` component would apply typography styles to basic html elements in it, so something like this:

```
<RunningText>
  <h2>Foo</h2>
</RunningText>
```
Would behave like this:
```
<Typography variant="h2">Foo</Typography>
```

- [x] This is not a v0.x issue. <!-- (v0.x is no longer maintained) -->
- [x] I have searched the [issues](https://github.com/mui-org/material-ui/issues) of this repository and believe that this is not a duplicate.

## Expected Behavior 🤔
Within a `<RunningText>` all of the styles normally applied by `<Typography>` would be applied to the corresponding plain html elements.

## Current Behavior 😯
If you want to render markdown in Material-UI, you have to use something like https://github.com/remarkjs/remark-react and its `remarkReactComponents` to make transformations like `<h2>` => `<Typography variant="h2">`.  If you want to render arbitrary rich text from something like ProseMirror, you have to use something like https://github.com/remarkablemark/html-react-parser/ and its `replace` functionality to do the same.  If you want to render rich text from a contenteditable with WYSIWYG, you're out of luck because there's no way to use `<Typography>` in the editing control of things like ProseMirror.

## Examples 🌈

Blueprint.js is React component library unrelated to Material Design.  It has a feature like this, documented here as "RUNNING_TEXT": https://blueprintjs.com/docs/#core/components/html


## Context 🔦

I listed some specific use cases in Current Behavior, but basically any situation where you want to render basic document content that might be dynamically generated and where using lots of `<Typography>` elements would be difficult.

## Benchmark

- https://elastic.github.io/eui/#/display/text
- https://bulma.io/documentation/elements/content/
Repository: rust
Issue: C runtime library is not linked on macOS
Labels: A-linkage,O-macos

**Problem**
rustc is not default to link C runtime library on macOS. I'm trying to write rust binding for a C library. That C library is shipped with my crate by a git submodule. The C library uses functionality provide by C runtime library. When I run `cargo test` without any special cargo configuration, it failed at linking stage because it cannot find the symbol  `__emutls_get_address` which is provided in C runtime library.

The bug doesn't happen on Linux. On Ubuntu 18.04.2 LTS (GNU/Linux 4.15.0-46-generic x86_64). With the help of nightly `rustc -Z print-link-args`, I found out that rustc on linux has a link arg `-lgcc_s` which resolve to `/usr/lib/gcc/x86_64-linux-gnu/7/libgcc_s.so`.


**Steps**
<!-- The steps to reproduce the bug. -->

1. Get my repo
```
$ git clone git@github.com:lwshang/q-capi.git --single-branch --branch rustc-link
$ cd q-capi
$ git submodule update --init
```
2. disable my workaround in` .cargo/config`
```
$ mv .cargo .cargo.bk
```
3. Try to build the test executable
```
$ cargo test
...
  = note: Undefined symbols for architecture x86_64:
            "___emutls_get_address", referenced from:
                l004 in e.o
...
```


**Possible Solution(s)**
<!-- Not obligatory, but suggest a fix/reason for the bug, -->
<!-- or ideas how to implement the addition or change -->
Currently, I have a workaround to separately add link-args in `.cargo/config` which specify the path to a C runtime library. But this is just a temporary solution, since the path is version sensitive, it will be different on different version of macOS with different version of Xcode.

If we compile a C program, the final link process always links a C runtime library. Depends on the compiler, different lib will be linked.

1. If using macOS 10.14.3 system clang, it links `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/lib/darwin/libclang_rt.osx.a`. (This is what I have in `.cargo/config`)

2. If using brew gcc-8, there is a link arg
`-lgcc_ext.10.5` which resolve to  `/usr/local/Cellar/gcc/8.3.0/lib/gcc/8/libgcc_ext.10.5.dylib`.

If rustc default to link the first one (`libclang_rt.osx.a`), the special setting in `.cargo/config` will be non-necessary.

**meta**
```
rustc 1.33.0 (2aa4c46cf 2019-02-28)
binary: rustc
commit-hash: 2aa4c46cfdd726e97360c2734835aa3515e8c858
commit-date: 2019-02-28
host: x86_64-apple-darwin
release: 1.33.0
LLVM version: 8.0
```
Repository: go
Issue: cmd/compile: allow ; on the RHS of rewrite rules for side-effects
Labels: NeedsFix

Consider this rewrite rule:

```
(ADDQ x l:(MOVQload [off] {sym} ptr mem)) && canMergeLoadClobber(v, l, x) && clobber(l) -> (ADDQload x [off] {sym} ptr mem)
```

The `canMergeLoadClobber` condition is pure (free from side-effects). The `clobber` condition is not really a condition at all, but pretends to be one and is there for side-effects instead.

It'd be nice, for both clarity and reusability, to be able to put side-effects on the RHS of the rule. Something like:

```
(ADDQ x l:(MOVQload [off] {sym} ptr mem)) && canMergeLoadClobber(v, l, x) -> clobber(l); (ADDQload x [off] {sym} ptr mem)
```

`noteRule`, `warnRule`, and `clobberIfDead` all belong on the RHS.

[@mundaym's hypothetical `mergeSuccessor` function](https://github.com/golang/go/issues/30645#issuecomment-470612424) could also be naturally split into pure conditional LHS and impure RHS.

Thoughts?

cc @randall77 @cherrymui @mvdan @mundaym
Repository: ant-design
Issue: Avoid to remove tag when pressing backspace on select
Labels: Inactive,❓FAQ

- [x] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.


Hi, I have been trying to intercept on keydown and preventDefault / stopPropagation / return false but nothing works, I think it will be a great feature.


### What problem does this feature solve?
Avoid tag remove when pressing backspace on select, some users will not wish it

### What does the proposed API look like?
removeOnBackspace={false|true}


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: pytorch
Issue: Support 'bytes' type in torchscript
Labels: oncall: jit,triaged,jit-backlog

## 🚀 Feature

Need support for 'bytes' type in torchscript

## Motivation

While dealing with image data, we have use cases where we download a blob from a blobstore and need to pass it to a torchscript module for further processing (ex: torchvision.transforms).

Currently, there is no clean way to do this since pybind enforces that python strings be utf-8 encoded and as a result we can't pass in arbitrary bytes to a torchscript module.

Supporting the python 'bytes' type in torchscript would be a clean way to support use cases like this.

cc @suo
Repository: vscode
Issue: TerminalOptions.waitOnExit API
Labels: feature-request,api,api-proposal,terminal-process

```ts
enum WaitOnExitType {
    Never = 0,
    NonZeroExitCode = 1,
    Always = 2
}

export interface TerminalOptions {
    /**
     * Whether the terminal panel should wait before closing when a terminal's process exits.
     */
    waitOnExit?: WaitOnExitType;
}
```

waitOnExit was originally proposed as a boolean in https://github.com/Microsoft/vscode/issues/15583
Repository: godot
Issue: Textboxes trap the input using keyboard only
Labels: bug,topic:gui

**Godot version:**
3.1 stable

**OS/device including version:**
Windows 10

**Issue description:**
When the user  moves with only the keyboard or a joystick pad, if the current focused object is a lineedit or textedit, the user can't leave the textbox using left and right arrows in lineedit and left, right, up, down in case of textedit multiline
The user never should be locked in an input, this default behavior breaks the joystick only games by default, with textedit the only way to leave the textbox is using mouse o keyboard prev/next focus key.

**Steps to reproduce:**
Create a lineedit or textedit.
Add some other nodes at left, right, up, down from textbox.
In line edit case focus the lineedit and try to leave using only left, right.
In textedit case focus the textedit and try to leave using only arrows.

How I expect to be in all textboxes for consistency:
When the caret is after the last character if the user press right again, change focus to right object.
When the caret is before first character if the user press left again, change focus to left object.
When the caret is in the first line and before the first character, if the user press up again, change focus to top object.
When the caret is in the last line and after the last character, if the user press down again, change focus to bot object.

**Minimal reproduction project:**
I applied my idea as a script using the neighbour attributes for lineedit, but it should be the default behavior without using neighbour attributes.
And there are examples without the script with the default godot behavior.
[next_textbox_3.1.zip](https://github.com/godotengine/godot/files/2964602/next_textbox_3.1.zip)
Repository: go
Issue: x/image/tiff: unexpected EOF
Labels: ExpertNeeded,NeedsInvestigation

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.12 darwin/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
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/wh/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/wh/jobs/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/opt/go/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/opt/go/libexec/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/d7/9qx1qd7s6wb8hlmw9xtt9h_h0000gn/T/go-build488513078=/tmp/go-build -gno-record-gcc-switches -fno-common"
</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.
-->

```go
package main

import (
	"image"
	"os"
	"log"

	_ "golang.org/x/image/tiff"
)

func main() {
	f, err := os.OpenFile("1.tif", os.O_RDONLY, 0644)

	if err != nil {
		log.Fatal(err)
	}

	img, format, err := image.Decode(f)
	if err != nil {
		log.Fatal(err)
	}
	log.Printf("%v %s", img, format)
}
```

The image is here 
[1.tif.zip](https://github.com/golang/go/files/2964703/1.tif.zip)

### What did you expect to see?

### What did you see instead?

unexpected EOF
Repository: go
Issue: x/build: speed up large container start-up times without pre-pulling containers into VMs (CRFS)
Labels: Performance,Builders,NeedsInvestigation

Tracking bug for improving how we maintain & deploy our larger builder environment containers easily and quickly while also having them start up quickly.

Our current situation (building a container, pushing to gcr.io, then automating the creation of a COS-like VM images that has the image pre-pulled) is pretty gross and tedious.

I propose CRFS: a Container-Registry Filesystem. See design doc at https://github.com/golang/build/tree/master/crfs#crfs-container-registry-filesystem

The gist of it is that we can read bytes from gcr.io directly with a FUSE filesystem, rather than doing huge docker pulls. It's not very hard once you tweak the tarballs into a more amenable format.
Repository: godot
Issue: Soft bodies do not collide with each other
Labels: bug,confirmed,topic:physics

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if non-official. -->
3.1 Stable

**OS/device including version:**
<!-- Specify GPU model and drivers if graphics-related. -->
Windows 10 1809 64bit, ver 17763.316
GTX 1080, driver 418.81

**Issue description:**
<!-- What happened, and what was expected. -->
Soft bodies do not collide with other soft bodies. Expected them to collide.

**Steps to reproduce:**
1. Create a soft body and add a plane mesh (Godot internal).
2. Create a soft body sphere (mesh from Blender).
3. Pin the edges of the plane so it acts as a "net".
4. Move the ball on top of the plane and press play. Ball falls through without colliding/getting caught.

Spheres do not collide with each other either (minimal project has 2 spheres and 1 plane).

**Minimal reproduction project:**
<!-- Recommended as it greatly speeds up debugging. Drag and drop a zip archive to upload it. -->
[softbodytest.zip](https://github.com/godotengine/godot/files/2964990/softbodytest.zip)

(Performance is also fairly slow but I'm not sure if it's expected with soft bodies like these. Once both balls are on the ground in the example project I get a lot of lag with an r5 2400g and GTX 1080. Would it be fixed by #22448 ?)
Repository: go
Issue: cmd/go: 'build -o' overwrite behavior differs between Linux and Windows
Labels: OS-Windows,NeedsInvestigation

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.12 windows/amd64
go version go1.12 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
yes

### 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.
-->
When exec "build -o dst_file" on windows casually, i got an error：
`go build go-test: build output "dst_file" already exists and is not an object file.`
I found dst_file allready exists and is an empty file，but it works on linux in the same case.

After reviewed code related build, I found the code snippet:
`b.moveOrCopyFile(a.Target, a1.built, perm, false)`
force is false, and moveOrCopyFile rename src to dst on linux, and not check the param force.

### What did you expect to see?
It should be the same on different os, I think param force should be retain semantically, eg: 
<pre>			
if err := os.Chmod(src, mode); err == nil {
+	// Be careful about removing/overwriting dst.
+	// Do not remove/overwrite if dst exists and is a directory
+	// or a non-object file.
+	if fi, err := os.Stat(dst); err == nil {
+		if fi.IsDir() {
+			return fmt.Errorf("build output %q already exists and is a directory", dst)
+		}
+		if !force && fi.Mode().IsRegular() && !isObject(dst) {
+			return fmt.Errorf("build output %q already exists and is not an object file", dst)
+		}
+	}
	if err := os.Rename(src, dst); err == nil {
		if cfg.BuildX {
			b.Showcmd("", "mv %s %s", src, dst)
		}
		return nil
	}
}
</pre>

Can someone give me some advice?
 :) thanks.
Repository: godot
Issue: FileDialog and EditorFileDialog signals are not fired from EditorScript
Labels: discussion,topic:editor

**Godot version: 3.1 stable**
<!-- Specify commit hash if non-official. -->

**OS/device including version: macOS 10.14.3 (Mojave)**
<!-- Specify GPU model and drivers if graphics-related. -->

**Issue description:**
If created from `EditorScript`, none of the `FileDialog` or `EditorFileDialog` signals seem to ever fire, except for `about_to_show`.

List of signals that are never fired:
- `modal_closed`
- `hide`
- `popup_hide`
- `confirmed`
- `file_selected` 
- `dir_selected`
- `files_selected`

Neither do `pressed` signals of **ok** and **cancel** buttons, obtained from `FileDialog#get_ok()` and `FileDialog#get_cancel()` respectively

**Steps to reproduce:**

Example code to open `FileDialog` from the `EditorScript`:
```
tool
extends EditorScript

#var save_dialog:EditorFileDialog
var save_dialog:FileDialog

func _run():
	_open_save_res_dialog()

func _open_save_res_dialog():
	var ei:EditorInterface = get_editor_interface()	
	var vp = ei.get_editor_viewport()
	
	"""
	save_dialog = EditorFileDialog.new()
	save_dialog.mode = EditorFileDialog.MODE_SAVE_FILE
	save_dialog.access = EditorFileDialog.ACCESS_RESOURCES
	save_dialog.display_mode = EditorFileDialog.DISPLAY_LIST
	"""
	
	save_dialog = FileDialog.new()
	save_dialog.mode = FileDialog.MODE_OPEN_FILE
	save_dialog.access = FileDialog.ACCESS_RESOURCES
	
	vp.add_child(save_dialog)
	
	save_dialog.get_ok().connect("pressed", self, "_on_ok")
	save_dialog.get_cancel().connect("pressed", self, "_on_cancel")
	
	# the only one that actually fires
	save_dialog.connect("about_to_show", self, "_on_about_to_show")
	
	save_dialog.connect("modal_closed", self, "_on_modal_closed")
	save_dialog.connect("hide", self, "_on_hide")
	save_dialog.connect("popup_hide", self, "_on_popup_hidden")
	save_dialog.connect("confirmed", self, "_on_confirmed")
	
	save_dialog.connect("file_selected", self, "_on_file_selected") 
	save_dialog.connect("dir_selected", self, "_on_dir_selected")
	save_dialog.connect("files_selected", self, "_on_files_selected")
		
	save_dialog.popup_centered_ratio(0.75)
	
	print(save_dialog.current_dir)	

func _on_ok():
	print("_on_ok")

func _on_cancel():
	print("_on_cancel")

func _on_modal_closed():
	print("_on_modal_closed")

func _on_hide():
	print("_on_hide")

func _on_about_to_show():
	print("_on_about_to_show")

func _on_popup_hidden():
	print("_on_popup_hidden")
	
func _on_confirmed():
	print("_on_confirmed")
	
func _on_file_selected(path):
	print("_on_file_selected ", path)
	
func _on_files_selected(paths):
	print("_on_files_selected ", paths)
	
func _on_dir_selected(dir):
	print("_on_dir_selected ", dir)
```
None of the interactions with the file dialog created this way fire any signals mentioned above.

**Minimal reproduction project:**
<!-- Recommended as it greatly speeds up debugging. Drag and drop a zip archive to upload it. -->
[FileDialog_Test1.zip](https://github.com/godotengine/godot/files/2965883/FileDialog_Test1.zip)
Repository: neovim
Issue: create one-line window / remove local statusline
Labels: enhancement,ui,ui-extensibility,statusline

Some times, I need one line window, such like WinBar of vim8.1 or notebook tabs like gui.
But I found, I can not make one line window, the minimize window has 2 lines, 1 line content and 1 line statusline.
Can nvim provide an option to hide the statusline of the window?