sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Autocomplete on extends keyof generic
Labels: Suggestion,Domain: Completion Lists,Experience Enhancement

<!-- 🚨 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.3.0-dev.20181122

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
- autocomplete
- autocomplete generic
- generic extends
- autocomplete keyof extends
- autocomplete keyof generic

**Code**

```ts
type Except<T, K extends keyof T> = Pick<T, { [P in keyof T]: P extends K ? never : P }[keyof T]>;

interface I1 {
    foo: string;
}
function F1<T extends I1>(): Except<T, ''> { // error is shown but autocomplete is not provided
    //code
    return null;
}
```

**Expected behavior:**
Having autocomplete showing when extending a generic

**Actual behavior:**
Even if error is correctly displayed, no autocomplete is shown for a `T extends` with a known type on the right hand.

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->
https://www.typescriptlang.org/play/index.html#src=type%20Except%3CT%2C%20K%20extends%20keyof%20T%3E%20%3D%20Pick%3CT%2C%20%7B%20%5BP%20in%20keyof%20T%5D%3A%20P%20extends%20K%20%3F%20never%20%3A%20P%20%7D%5Bkeyof%20T%5D%3E%3B%0A%0Ainterface%20I1%20%7B%0A%20%20%20%20foo%3A%20string%3B%0A%7D%0Afunction%20F1%3CT%20extends%20I1%3E()%3A%20Except%3CT%2C%20''%3E%20%7B%0A%20%20%20%20%2F%2Fcode%0A%20%20%20%20return%20null%3B%0A%7D

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
#16740 - but this one is quite different because it's a keyof issue
Repository: react
Issue: API for display name on forwardRef, memo and potential future exotic components
Labels: Type: Feature Request

TL;DR: Can you expose [shared/getComponentName](https://github.com/facebook/react/blob/master/packages/shared/getComponentName.js)?

<!--
  Note: if the issue is about documentation or the website, please file it at:
  https://github.com/reactjs/reactjs.org/issues/new
-->

**Do you want to request a *feature* or report a *bug*?**
Expose an API to get the display name of every component (in `__DEV__` only).

**What is the current behavior?**
Most of the ecosystem still uses `Component.displayName || Component.name || someFallbackName` 
 (with some branching depending on the type of `Component`) when setting the display name of an enhanced component i.e. `connect()(WrappedComponent)` will result in `"connect(WrappedComponent)"` as a `displayName`.

**If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle (https://jsfiddle.net/Luktwrdm/) or CodeSandbox (https://codesandbox.io/s/new) example below:**
Since components created by `forwardRef` or `memo` are not actual functions these higher-order components are not able to determine a proper display name while `react-devtools` is able to:

https://codesandbox.io/s/zqj9v50243

- `react-redux` creates `"connect(Component)"`
- `react-router` creates `"withRouter(undefined)"`

**What is the expected behavior?**
The new "exotic-components" should work with the existing 3rd party libraries WRT to `displayName`.

Now there are a couple of solutions to this issue:
1. **Edit:** Expose [shared/getComponentName](https://github.com/facebook/react/blob/master/packages/shared/getComponentName.js)
2. This is the responsibility of the ecosystem. It should provide a solution and maintain it. Somewhat blocked by #12882, related: #12932
3. Grant access to the functionality used in `react-devtools` (or would this only work on the fibers?)
4. Set a `name` (or `displayName` no preference here) property on those "exotic-components" (don't know how to call them). Naive implementation e.g.: `name: 'ForwardRef(' + fn.name + ')'`.

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**
I guess this started with `forwardRef` in 16.3.
Repository: flutter
Issue: ModalRoute.of(context).pop(value)
Labels: c: new feature,framework,f: routes,P3,team-framework,triaged-framework

There's currently no good way for a dialog to pop itself when it's not sure that it's on top.
Repository: pytorch
Issue: [libtorch] Catkin_make compilation error
Labels: needs reproduction,module: build,triaged,has workaround

I am trying to use libtorch to my catkin project. 

One of my package A links with libtorch.so and can be successfually compiled as a static library A.a. 

Then I try to linked A.a to another package B. 

When I run catkin_make, the following error comes out:

> -- Configuring done
> CMake Error:
>   Error evaluating generator expression:
> 
>     $<TARGET_PROPERTY:caffe2,INTERFACE_SYSTEM_INCLUDE_DIRECTORIES>
> 
>   Target "caffe2" not found.
> 
> 
> CMake Error:
>   Error evaluating generator expression:
> 
>     $<TARGET_PROPERTY:caffe2_gpu,INTERFACE_SYSTEM_INCLUDE_DIRECTORIES>
> 
>   Target "caffe2_gpu" not found.
> 
> 
> CMake Error:
>   Error evaluating generator expression:
> 
>     $<TARGET_PROPERTY:caffe2,INTERFACE_SYSTEM_INCLUDE_DIRECTORIES>
> 
>   Target "caffe2" not found.
> 
> 
> CMake Error:
>   Error evaluating generator expression:
> 
>     $<TARGET_PROPERTY:caffe2_gpu,INTERFACE_SYSTEM_INCLUDE_DIRECTORIES>
> 
>   Target "caffe2_gpu" not found.
> 
> 
> -- Generating done
> -- Build files have been written to: /home/panpan/workspace/catkin_ws/build
> Makefile:4460: recipe for target 'cmake_check_build_system' failed
> make: *** [cmake_check_build_system] Error 1
> Invoking "make cmake_check_build_system" failed

My CMakeLists.txt in package A contains something like
```
project(A CXX CUDA) 
find_package(Torch REQUIRED)
...
target_link_libraries("${PROJECT_NAME}" "${TORCH_LIBRARIES}")
```
And CMakeLists.txt in package B calls:
```
target_link_libraries(B
   ${catkin_LIBRARIES}
   A
)
```
The error comes during the cmake generation stage where the configuration is done but the compilation hasn't started yet.
Only package A in my catkin workspace is using libtorch.

System configuration:
- Ubuntu 18.04
- Cmake 3.12.4
- CUDA 9.0.176
- gcc g++ 5.5
- libtorch 1.0.0.dev20181121
- Catkin comes with ROS melodic

_Originally posted by @cindycia in https://github.com/pytorch/pytorch/issue_comments#issuecomment-441210189_
Repository: rust
Issue: "the type parameter is not constrained" but it is needed
Labels: A-type-system,T-compiler,C-bug,T-types

I would expect the following code to compile:
```rust
#![allow(unused)]

trait AllocExtra<MemoryExtra> {
    fn create(x: &MemoryExtra) -> Self;
}

struct Alloc<Extra> {
    extra: Extra,
    other: u32,
}

impl<MemoryExtra, Extra: AllocExtra<MemoryExtra>> Alloc<Extra> {
    fn new(x: &MemoryExtra) -> Self {
        Alloc {
            extra: AllocExtra::create(x),
            other: 42,
        }
    }
}
```
but [it does not](https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=2d912f58d2bd63ebbc633c02ddd15cfd).

I will now try to hack around this by moving the where-clause to every function, but I will have to repeat it *at lot*.
Repository: go
Issue: cmd/compile: teach prove about slice expressions
Labels: Performance,compiler/runtime

```
$ cat f.go
package p

func f(s string) {
        if len(s) >= 2 {
                s = s[1:]
                _ = s[0]
        }
}
$ go version
go version devel +6d5caf38e3 Thu Nov 22 02:59:55 2018 +0000 linux/amd64
$ go build -gcflags=-d=ssa/check_bce/debug=1 f.go
# command-line-arguments
./f.go:6:8: Found IsInBounds
```

The bounds check disappears as soon as we rewrite the code to not reslice `s`. This shows up in real code fairly often, for example, I encountered it in a somewhat hot function in the `encoding/json` decoder:

```
if len(s) >= 2 && (s[0] == 'e' || s[0] == 'E') {
        s = s[1:]
        if s[0] == '+' || s[0] == '-' { // bounds check isn't eliminated here
```

I'm not sure how easy it would be to make the prove pass aware of slice expressions. I think handling the simple `x = x[N:]` case (where `N` is constant) should be doable, and hopefully remove a few dozen bounds checks across the standard library.

/cc @aclements @rasky @josharian
Repository: rust
Issue: rustdoc does not highlight non-rust code fragments
Labels: T-rustdoc,A-docs,C-feature-request

In this example, the Rust fragment is highlighted, but the C one is not:

    //! ```rust
    //! // This is Rust.
    //! fn main() {}
    //! ```
    //!
    //! ```c
    //! /* This is C.  */
    //! int main() { return 0; }
    //! ```
Repository: go
Issue: cmd/compile: BCE is better with reslicing than index variables
Labels: Performance,compiler/runtime

Take this piece of code:

```
$ cat f.go
package p

func slice(p []byte) {
        for len(p) > 4 {
                // zero bounds checks.
                _ = p[0]
                _ = p[1]
                _ = p[2]
                _ = p[3]

                p = p[4:] // reslicing is expensive.
        }
}

func index(p []byte) {
        i := 0
        for i < len(p) {
                _ = p[i+3] // BCE hint; bounds check

                _ = p[i]   // unexpected bounds check
                _ = p[i+1] // unexpected bounds check
                _ = p[i+2] // unexpected bounds check
                _ = p[i+3]

                i += 4 // incrementing i is cheap.
        }
}
$ go version
go version devel +6d5caf38e3 Thu Nov 22 02:59:55 2018 +0000 linux/amd64
$ go build -gcflags=-d=ssa/check_bce/debug=1 f.go
# command-line-arguments
./f.go:18:8: Found IsInBounds
./f.go:20:8: Found IsInBounds
./f.go:21:8: Found IsInBounds
./f.go:22:8: Found IsInBounds
```

It's easy to see why the first variant has zero bounds checks. However, reslicing can be expensive in a hot loop, so sometimes the code is rewritten to use indexes.

This is what the second variant does. I do realise that the two loops aren't equivalent - for example, if `len(p) == 5`, the second loop will panic since the length is not a multiple of 4. So I understand why the compiler needs to insert one bounds check.

Still, it seems to me like it should insert one, not four, since I've added the BCE hint. My first thought was that it couldn't prove that `i >= 0`, but changing the index to be unsigned still doesn't remove all the bounds checks that I'd expect.

I encountered this in the base64 encoder:

```
di, si := 0, 0
n := (len(src) / 3) * 3
for si < n {
        // Convert 3x 8bit source bytes into 4 bytes
        val := uint(src[si+0])<<16 | uint(src[si+1])<<8 | uint(src[si+2]) // 3 bounds checks

        dst[di+0] = enc.encode[val>>18&0x3F] // bounds check
        dst[di+1] = enc.encode[val>>12&0x3F] // bounds check
        dst[di+2] = enc.encode[val>>6&0x3F]  // bounds check
        dst[di+3] = enc.encode[val&0x3F]     // bounds check

        si += 3
        di += 4
}
```

Rewriting the loop to use reslicing like `for len(src) >= 3 { ...; src = src[3:] }` does remove the bounds checks, but slows down the encoder noticeably. Just like in my simple example above, BCE hints like `_ = src[si+2]` and unsigned indexes didn't help either.

I think there's probably a way to rewrite the loop index logic to trick BCE, but I think the compiler could be made smarter here. I'm not sure whether that should be an enhancement in the prove pass, or in the bounds check elimination pass.

/cc @aclements @rasky @josharian
Repository: go
Issue: net: support for RFC 4592 (lookup for wildcard dns)
Labels: FeatureRequest

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.10.3 darwin/amd64
</pre>
### 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/qiufeng/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/qiufeng/go"
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/pr/1blgkr1j60bbscwnp21g4bqr0000gn/T/go-build995562236=/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.
-->
<pre>package main

import (
	"net"
	"context"
	"log"
)
func main() {

	host:="*.qzone.qq.com"
	log.Println(net.LookupHost(host))

	r := net.Resolver{
		PreferGo:true,
		StrictErrors:true,
		Dial: DNSDialer,
	}
	ctx := context.Background()

	ipaddr, err := r.LookupHost(ctx, host)
	if err != nil {
		log.Println(err)

	}
	log.Println(ipaddr)
}


func DNSDialer(ctx context.Context, network, address string) (net.Conn, error) {
	d := net.Dialer{}
	return d.DialContext(ctx, "udp", "8.8.8.8:53")
}</pre>


### What did you expect to see?
<pre>
$ go run test2.go
2018/11/26 10:47:27 [180.163.21.59] <nil>
2018/11/26 10:47:27 [180.163.21.59] <nil>
</pre>


### What did you see instead?
<pre>
$ go run test2.go
2018/11/26 10:47:27 [180.163.21.59] <nil>
2018/11/26 10:47:27 lookup *.qzone.qq.com: no such host
2018/11/26 10:47:27 []
</pre>
Repository: go
Issue: x/build/cmd/coordinator: use cmd/go's build caching
Labels: Performance,Builders,NeedsFix,FeatureRequest

Now that cmd/go has good caching, cmd/coordinator should use it, somehow.

We'd likely need some hooks in cmd/go to accommodate our needs, but Russ said he was fine with that when I asked him maybe a year ago.

/cc @dmitshur @bcmills
Repository: vue-element-admin
Issue: 使用Tinymce时报错Error in nextTick: "TypeError: Cannot read property 'parse' of undefined"
Labels: enhancement :star:

点击编辑回显数据
`this.$refs.editor.setContent(this.temp.intr)`
功能没问题，就是报了一个错，好像是tinymce初始化没有完成
[Vue warn]: Error in nextTick: "TypeError: Cannot read property 'parse' of undefined"
Repository: go
Issue: cmd/compile: consider teaching prove about unexported integer fields
Labels: Performance,compiler/runtime

Consider the following program:

```
$ cat f.go
package p

type T struct {
	intOff  int
	uintOff uint
	data    []byte
}

func (t *T) reset(data []byte) {
	t.intOff = 0
	t.uintOff = 0
	t.data = data
}

func withIntVar(data []byte) {
	i := 0
	for i < len(data) {
		_ = data[i] // no bounds check
		i++
	}
}

func (t *T) withIntField(data []byte) {
	for t.intOff < len(t.data) {
		_ = t.data[t.intOff] // bounds check!
		t.intOff++
	}
}

func (t *T) withUintField(data []byte) {
	for t.uintOff < uint(len(t.data)) {
		_ = t.data[t.uintOff] // no bounds check
		t.uintOff++
	}
}
$ go version
go version devel +048c9164a0 Sat Nov 24 23:55:07 2018 +0000 linux/amd64
$ go build -gcflags=-d=ssa/check_bce/debug=1 f.go
# command-line-arguments
./f.go:25:13: Found IsInBounds
```

Lengths are signed, `int` is simple, and it's the default integer type, so it's understandable why most indexes and offsets are signed. This works fine in our first example; we get no bounds checks.

However, this breaks down when we start using struct field integers, if the loop logic is split between multiple methods. We can see that the second example has a bounds check. Only making the field unsigned is enough to convince prove/BCE that the offset is always within the bounds of the slice, presumably because in the signed integer field case the compiler isn't smart enough to figure out that `t.intOff >= 0` in all cases.

For example, see https://go-review.googlesource.com/c/go/+/150919, where the JSON decoder gets ~1.5% faster by just making the offset field unsigned, but at the cost of adding more type conversions in a bunch of places.

I presume that we could prove that a signed integer field is never negative, granted that it's an unexported field and is only ever assigned non-negative values, such as:

* `t.field = N`, where N is bounded to be non-negative
* `if t.field < N { t.field++ }`, where N is bounded to be non-negative

The JSON example above does use `d.off = len(d.data) + 1` to mark an EOF, which could get the field to overflow if `len(d.data)` is the maximum integer value, but I presume we could rewrite it to use `d.off  = len(data)`. Otherwise, all the assignments seem to keep the offset within non-negative bounds.

Ideally, the prove pass would be smart enough to also work with variations of these rules, such as the code below. But that could be tracked as a separate issue.

```
i := t.intOff
data := t.data
for i < len(data) {
    _ = data[i]
    i++
}
t.intOff = i
```

If there's a good reason why the prove pass can't ever deal with fields, please feel free to close this issue. I'm working with the assumption that it's possible, but hasn't been implemented yet.

/cc @aclements @rasky @josharian @bradfitz
Repository: pytorch
Issue: How to use model.net.Clip?
Labels: caffe2

I want to clip loss using Clip op like this model.net.Clip([input,output],  0,10)  but it dosen't work!!
the Operators Catalog of caffe2 is too simple. Does anyone can help me? Thank you very much!!!
Repository: pytorch
Issue: Error: DeviceGuardImpl for cpu is not available (static linking PyTorch)
Labels: module: build,triaged,module: static linking,has workaround

 I am getting this:

```
Error: unhandled exception: p ASSERT FAILED at /data/Storage/Development/nimtorch/aten/include/c10/impl/DeviceGuardImplInterface.h:130, please report a bug to PyTorch. DeviceGuardImpl for cpu is not available (getDeviceGuardImpl at /data/Storage/Development/nimtorch/aten/include/c10/impl/DeviceGuardImplInterface.h:130)
```

I wonder if there is some forgotten initialization code that is not getting called when linked statically?
Static library build not being tested and broken?


## Previous content

Hi
I followed the steps given in the following tutorial https://pytorch.org/tutorials/advanced/cpp_export.html to port my pytorch code to C++ and have been successfully able to run the model in C++. I compiled my C++ code as mentioned in the tutorial using the CMakeLists.txt file. 
However, I want to now run my code on a different platform(having similar configuration) and thus want to compile the code for static linking of the libraries.  I tried using the following command for building the application:
```cmake -D CMAKE_PREFIX_PATH=/home/pytorch/libtorch -D OpenCV_DIR=/home/opencv/build -D BUILD_SHARED_LIBS=OFF -DCMAKE_EXE_LINKER_FLAGS="-static"  ..``` 
which gave the following error:
`/usr/bin/ld: attempted static link of dynamic object /home/pytorch/libtorch/lib/libtorch.so`

Can anyone help me by explaining what should be the best way for doing static linking of the library?
Repository: rust
Issue: Oh rust doctest lints, where art þou? (Add a way to run clippy on doctests)
Labels: T-rustdoc,A-lints,A-doctests,A-clippy

Currently, doctests benefit from being code in numerous ways, such as being tested. However, this unfortunately does not (yet?) apply to clippy lints. For (an atmittedly contrived) example:

```rust
/// is the given number odd?
///
/// # Examples
///
/// ```rust
///# use testdoclints::is_odd;
/// let mut a = 1;
/// a = a + 1; // this should lint `clippy::assign_op_pattern`
/// assert!(!is_odd(a));
/// ```
pub fn is_odd(x: usize) -> bool {
    (x & 1) == 1
}
```

Running `cargo clippy` shows no lint.

To solve this, we'd need to be able to hook into the test code generation and present the resulting AST and HIR to our lints. I am unsure where to put this issue, but as clippy is not the only source of custom lints, I think solving it within rust/rustdoc makes sense.

cc @Manishearth @oli-obk
Repository: pytorch
Issue: [c10d] Configurable timeout per operation for MPI backend
Labels: oncall: distributed,feature,triaged,distributed-backlog

Also see #14297.

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @xush6528 @osalpekar @jiayisuse @agolynski
Repository: terminal
Issue: Showing Schemes doesn't work on WSL
Labels: Product-Colortool,Help Wanted,Area-Interop,Issue-Bug,Priority-3

From #22:
> 
> 
> @Falcury `-q -x` works for me, though showing schemes does not:
> 
> ```shell
> [rofrol@DESKTOP-NBALJ88 ~]$ pushd ~/rofrol/installed/colortool/ &> /dev/null
> [rofrol@DESKTOP-NBALJ88 ~/rofrol/installed/colortool]$ ./colortool.exe -s
> 
> Unhandled Exception: System.IO.IOException: The handle is invalid.
> 
>    at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
>    at System.Console.GetBufferInfo(Boolean throwOnNoConsole, Boolean& succeeded)
>    at System.Console.get_WindowWidth()
>    at ColorTool.Program.PrintSchemes()
>    at ColorTool.Program.Main(String[] args)
> ```


This should be fixed. 
* [ ] We need to add support for `-s -x` to print the scemes in linux-y mode
* [ ] We should probably also catch this exception for the `-s` flag and properly display an error along the lines of "You should try `-s -x`"
Repository: vscode
Issue: terminal stays open after process exit
Labels: feature-request,debug

Initially I thought this was an issue with MIEngine, but they report that it is up to VSCode to properly close the external console after debugging

https://github.com/Microsoft/MIEngine/issues/807

Version: 1.29.1
Commit: bc24f98b5f70467bc689abf41cc5550ca637088e
Date: 2018-11-15T19:07:43.495Z
Electron: 2.0.12
Chrome: 61.0.3163.100
Node.js: 8.9.3
V8: 6.1.534.41
Architecture: x64

repro
1. debug cpp with external terminal
2. when the program ends, the terminal remains open

"Press any key to continue.." is holding these zombie terminals open (we get a new one with each run/debug run)