sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Add `import type "mod"`
Labels: Suggestion,In Discussion,Awaiting More Feedback

## Search Terms
type-only import

## Suggestion
The new type-only import syntax supports most variations of `import` statement but not this one:
`import type 'mod'`
It may seem stupid because no type is actually imported?! But it's in fact useful if `mod` contains some global declarations that you need.

Global declarations are currently only imported from: `typeroots` (`@types/*` by default) or `types` configs; and referenced modules.

~This syntax is even more useful because it can't be emulated today. If you do `import 'mod'` then typing works _but_ TS assumes you import the module for side-effects and will _not_ erase it.~(EDIT: see triple-slash comment)

## Use Cases
I encountered this today. 
One package I use provides some dependency injection and basically defines the following module augmentation:
`inject(x: 'myType'): MyType`
which is a strongly typed overload of
`inject<T = unknown>(x: string): T`.
Inject itself comes from another library so code that wants to use this import needs to do this:
```ts
import { inject } from 'other-lib';
import type 'my-lib';

let my = inject('myType'); // correctly typed as MyType
```

Current work-arounds include:
- Importing a type `import { MyType } from 'my-lib'` but if you don't use it in code it'll be a warning;
- Import without type `import 'my-lib'` but it won't be erased;
- ~Add this lib to `typeroots` or `types` and do nothing (might be better in some cases).~ (EDIT: not really working, see [my comment below](https://github.com/microsoft/TypeScript/issues/36812#issuecomment-586526700) for an alternative solution.)
- Use `/// <reference types="mod" />`, which works but I think most people have forgotten about? (I have 😜)

## 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: Make it easier to add new messages in RPC layer
Labels: triaged,better-engineering,module: rpc

## 🚀 Feature
As more features are implemented in the RPC layer there will likely be a need to add new message types and custom logic for responding to those messages.

Currently, there is a lot of scaffolding that needs to be written which is sort of duplicated across message types, for example we need to:

1) define the message type 
2) define whether it is a request or response
3) define its serdes methods
4) define how we should respond to the message

All of these hooks need to be added in separate files and it's quite easy to miss certain hooks and spend extra time debugging. It would be good to consolidate, such as by implementing some of the ideas below:

1) Have all RPC commands define an `execute()` method, and call this in `request_callback_impl.cpp`. This will save us the giant switch statement there (there is a TODO for this in the code currently)
2) Encapsulate the message type and whether it is a request/response into a single point of truth,
3) Provide a `registerMessage()` or similar interface where the user can just define their message type, any custom logic needed to convert from message --> command, and how to respond to the message. The framework will take care of instantiating the concrete objects via lambda functions that the developer can pass in.

## Motivation

It takes quite a bit of time to add new messages/commands currently.


cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @rohan-varma @xush6528 @jjlilley @osalpekar
Repository: PowerToys
Issue: [PowerRename] Warn when renaming results in equivalent names
Labels: Idea-Enhancement,Product-PowerRename

# Summary of the new feature/enhancement
Show a warning when renaming files results in some of them getting equivalent names.

# Details

Right now the files which should get equal names actually get enumerated, for example, if we have ab.txt and ba.txt and we replace b by a, we get aa.txt and aa (2).txt. Not just this, but no warning appears if files with the same target name already exist in that folder.
Repository: TypeScript
Issue: Support symbol properties on namespaces
Labels: Suggestion,In Discussion

## Search Terms

- namespace symbol
- namespace symbol property
- namespace symbol properties

## Suggestion

The&nbsp;ability to&nbsp;declare symbol&nbsp;properties on&nbsp;**TypeScript**&nbsp;namespaces.

## Use Cases

See&nbsp;<https://github.com/DefinitelyTyped/DefinitelyTyped/pull/42154#discussion_r376739320>.

## Examples

```ts
// doSomething.d.ts
import { promisify } from "util";

declare function doSomething(
	foo: any,
	onSuccessCallback: (result: string) => void,
	onErrorCallback: (reason: any) => void
);
declare namespace doSomething {
	function [promisify.custom](foo: any): Promise<string>;
}

export = doSomething;
```

## 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: rust
Issue: Bad quality code for `Clone` on enum types
Labels: I-slow,C-enhancement,A-codegen,T-compiler

For this Rust code, we get some pretty bad assembly:

```rust
#[derive(Clone)]
pub enum Foo {
    A(u8),
    B(bool),
}

#[derive(Clone)]
pub enum Bar {
    C(Foo),
    D(u8),
}

pub fn clone_foo(f: &Foo) -> Foo {
    f.clone()
}

pub fn clone_bar(b: &Bar) -> Bar {
    b.clone()
}
```

([Playground](https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=c14facc15a40601a2eb8dd10e122e421))

Assembly:

```
playground::clone_bar:
	movb	1(%rdi), %al
	cmpb	$1, (%rdi)
	jne	.LBB1_2
	xorl	%ecx, %ecx
	movl	$1, %edx
	jmp	.LBB1_3

.LBB1_2:
	movzbl	2(%rdi), %edx
	xorl	%ecx, %ecx
	testb	%dl, %dl
	setne	%cl
	cmpb	$1, %al
	sete	%al
	cmovnel	%edx, %ecx
	shll	$16, %ecx
	xorl	%edx, %edx

.LBB1_3:
	orl	%edx, %ecx
	movzbl	%al, %eax
	shll	$8, %eax
	orl	%ecx, %eax
	retq
```

To see that it's possibly to do better, we can simply add a `Copy` instance to the types. Then the code _even for `Clone`_ gets much better:

```rust
#[derive(Clone, Copy)]
pub enum Foo {
    A(u8),
    B(bool),
}

#[derive(Clone, Copy)]
pub enum Bar {
    C(Foo),
    D(u8),
}

pub fn clone_foo(f: &Foo) -> Foo {
    f.clone()
}

pub fn clone_bar(b: &Bar) -> Bar {
    b.clone()
}
```

([Playground](https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=4215a15ed3879563d06ab23e548ff8b1))

Assembly:

```
playground::clone_bar:
	movzwl	(%rdi), %ecx
	movzbl	2(%rdi), %eax
	shll	$16, %eax
	orl	%ecx, %eax
	retq
```

It's still not perfect (why are there two 2-byte loads instead of a single 4-byte load?) but it's much better.
Repository: pytorch
Issue: Expose `internal::GRAIN_SIZE` through Python API.
Labels: triaged,enhancement,module: multithreading

## 🚀 Feature

Currently the `internal::GRAIN_SIZE` is visible only via the C++ API. Its hard to know how many threads will be spawned by a given method for purposes of debugging or performance analysis purely through the Python API.

Having a way to do this using something like `torch.GRAIN_SIZE` should serve as a simple way of doing this.

## Motivation

I'm working on https://github.com/pytorch/pytorch/issues/33065 and find that I can't easily get the grain size from the python API and need to put a `cout` in the C++ code and then recompile it.

## Pitch

`torch.GRAIN_SIZE` should return the `internal::GRAIN_SIZE` number.
Repository: flutter
Issue: [web]: Platform.isAndroid and Platform.isIOS crash and can't be caught
Labels: c: crash,framework,dependency: dart,platform-web,P2,team-web,triaged-web

Internal: b/207023188

Supporting web is difficult because I can't detect whether the web platform is in use.

I tried `!Platform.isAndroid && !Platform.isIOS`, but it crashes. I used a try-catch around it. It freezes. I have to fully stop the emulator to recover. It still crashes on re-attempt.
Repository: go
Issue: x/tools/gopls: support advanced query syntax for Symbol
Labels: help wanted,FeatureRequest,gopls,Tools

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version devel +b7689f5aa3 Fri Jan 31 06:02:00 2020 +0000 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.0.0-20200214144324-88be01311a71
$ go list -m golang.org/x/tools/gopls
golang.org/x/tools/gopls v0.1.8-0.20200214144324-88be01311a71
</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=""
GOCACHE="/home/myitcv/.cache/go-build"
GOENV="/home/myitcv/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/myitcv/gostuff"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/myitcv/gos"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/myitcv/gostuff/src/github.com/myitcv/govim/go.mod"
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-build646330205=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

This is a request/proposal more than an issue.

We were discussing with @findleyr a means by which symbol search can be made more useful (in Vim). With #37236 fixed, the existing Symbol method will return matches from within the workspace (main module). But a fairly common query is to find symbols matching the query within the "current" package, where "current" is defined by the file within which the cursor is located. i.e. I want to jump to the definition of the method `(*T).M`.

Because the editor/client knows nothing about packages, I think this will require a query similar to the following. Imagine we are searching using the term `hello`, with the cursor in the file `main.go`

```
package:/path/to/main.go hello
```

`gopls` would then translate the file URI to a package and suitably constrain the results.


---

cc @stamblerre @findleyr 

FYI @leitzler
Repository: pytorch
Issue: torch.clamp_ not inplace during backward
Labels: module: autograd,module: memory usage,triaged

I use torch.clamp_ to avoid forward overflow for fp16 calculation. 
It does not consume extra memory during forward pass. 
However, it has the **same gpu memory cost** as torch.clamp during backward pass. 
In comparison, torch.relu_ does not take extra gpu memory during both forward and backward pass.

torch version: 1.3.0
torch.version.cuda: 10.1.243

```
_conv3d = nn.Conv3d
class Conv3dWrapper(_conv3d):
  def __init__(self, in_channels, out_channels, kernel_size, stride=1, padding=0, dilation=1,
               groups=1, bias=True, padding_mode='zeros'):
    super(Conv3dWrapper, self).__init__(in_channels, out_channels, kernel_size, stride,
                             padding, dilation, groups, bias, padding_mode)

  def forward(self, input):
    return torch.clamp_(super(Conv3dWrapper, self).forward(input), -65504, 65504)

_conv_trans3d = nn.ConvTranspose3d
class ConvTranspose3dWrapper(_conv_trans3d):
  def __init__(self, in_channels, out_channels, kernel_size, stride=1, padding=0,
            output_padding=0, groups=1, bias=True, dilation=1, padding_mode='zeros'):
    super(ConvTranspose3dWrapper, self).__init__(in_channels, out_channels, kernel_size,
            stride, padding, output_padding, groups, bias, dilation, padding_mode)

  def forward(self, input):
    return torch.clamp_(super(ConvTranspose3dWrapper, self).forward(input), -65504, 65504)

```


cc @ezyang @SsnL @albanD @zou3519 @gqchen
Repository: TypeScript
Issue: Variable initializer omits an error on destructuring assignment
Labels: Bug

<!-- 🚨 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 the latest published version. It may have already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly
-->
**TypeScript Version:**  3.7.x-dev.20200213

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

**Code**

```ts
const [[{ data: a }]] = [] as [Text[]] | []; // error
const [[{ data: b }] = []] = [] as [Text[]] | []; // no error
```

**Expected behavior:**

```ts
const [[{ data: a }]] = [] as [Text[]] | []; // error
const [[{ data: b }] = []] = [] as [Text[]] | []; // error
```

**Actual behavior:**

```ts
const [[{ data: a }]] = [] as [Text[]] | []; // error
const [[{ data: b }] = []] = [] as [Text[]] | []; // no error
```

**Playground Link:** http://www.typescriptlang.org/play/index.html?ts=3.9.0-dev.20200213&ssl=2&ssc=50&pln=1&pc=1#code/MYewdgzgLgBA2nA3jAJgQymgXDNMC+AuoTALzwloTwAqApgB5RzEwA+FA3AFCiSwJk6TDgBGBEuRaSKuanHpNp7LkA

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: neovim
Issue: Concurrent startup/exit corrupts shada on windows
Labels: bug,multiproc,editor-state

<!-- Before reporting: search existing issues and check the FAQ. -->

- `nvim --version`: bb331a9
- Operating system/version: Windows 10

### Steps to reproduce using `nvim -u NORC`

Install Firefox Nightly, Neovim and NodeJS in a [Windows 10 VM](https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/). Then, install Firenvim [from source](https://github.com/glacambre/firenvim#from-source) and run its testsuite (`npm run test`) a few times.

### Actual behaviour

Neovim eventually corrupts the shada file. I can only reproduce this by running the Firenvim testsuite (which starts and kills lots of neovim process very quickly) on a Windows VM (which is pretty slow). I know reproducing this would be a lot of effort so feel free to ask for more information, I'll be happy to run whatever steps need to be ran.

Using `-i NONE` is an acceptable workaround for my usecase.

Here are two example corrupted shada directories: https://file.io/DpD6xJ
https://file.io/J2daeD
In both cases, the error message is `E576: Error while reading ShaDa file: last entry specified that it occupies 99 bytes, but file ended earlier.`.
Repository: go
Issue: x/crypto/ssh: TCP/IP port forwarding expects IP addresses
Labels: NeedsInvestigation

[`(*ssh.Client).ListenTCP`](https://github.com/golang/crypto/blob/034e5325b6ab92faa14d15c30e86919e911cf8e0/ssh/tcpip.go#L101-L139) expects an IP address (via `*net.TCPAddr`) and therefore [`(*ssh.Client).Listen`](https://github.com/golang/crypto/blob/034e5325b6ab92faa14d15c30e86919e911cf8e0/ssh/tcpip.go#L19-L37) attempts to resolve addresses.

However, [section 7.1 of RFC 4254](https://tools.ietf.org/html/rfc4254#section-7.1) states:

> The 'address to bind' and 'port number to bind' specify the IP
> address (or domain name) and port on which connections for forwarding
> are to be accepted.  Some strings used for 'address to bind' have
> special-case semantics.
> 
>    -  "" means that connections are to be accepted on all protocol
>       families supported by the SSH implementation.
> 
>    -  "0.0.0.0" means to listen on all IPv4 addresses.
> 
>    -  "::" means to listen on all IPv6 addresses.
> 
>    -  "localhost" means to listen on all protocol families supported by
>       the SSH implementation on loopback addresses only ([RFC3330] and
>       [RFC3513]).
> 
>    -  "127.0.0.1" and "::1" indicate listening on the loopback
>       interfaces for IPv4 and IPv6, respectively.

There are two consequences of the current interface:

1. You can only provide resolvable names. This prohibits two of the strings with special-case semantics from working (`""`, reported in #33227, and `"::"`).

2. Resolution happens client side. This changes the meaning of the string `"localhost"` from being "all protocol families supported by the SSH implementation on loopback addresses only" to being only one of those and may provide a different result for other names (AWS hostnames resolving to internal addresses inside a data center comes to mind).

Outside of defining a new public interface, I think the least breaking change would be to extract an unexported `listenTCP` function taking a string address and call this from `Listen` which can then drop resolution but of course if you're relying on that behavior, it will still be surprising.

I'm happy to submit a pull request but I'd appreciate some thoughts on how to best evolve the interface into something that both supports the scope of the RFC and doesn't disregard current users.
Repository: terminal
Issue: WT -? -help --help window should include a link to the command line arguments
Labels: Product-Terminal,Issue-Task,Area-Commandline


# including a perma link into the help window

currently the help output is very basic.

Usually commands in cmd / powershell will not open a Win32 message box for help (except some few like slmgr, msiexec but print it in the console


# including a link or output in console session

Please consider to output the help content into the console session and / or include a permanent link to 
https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingCommandlineArguments.md

for further documentation. . This will help new users 

currently the output is a Win32 message box.
---------------------------
Help
---------------------------
wt - the Windows Terminal
Usage: [OPTIONS] [SUBCOMMAND]

Options:
  -h,--help                   Print this help message and exit

Subcommands:
  new-tab                     Create a new tab
  split-pane                  Create a new split pane
  focus-tab                   Move focus to another tab

---------------------------
OK   
---------------------------
Repository: pytorch
Issue: Illegal instruction: 4 - OSX 10.13.6 install from source
Labels: module: build,triaged,module: macos

## 🐛 Bug

<!-- A clear and concise description of what the bug is. -->

## To Reproduce

Steps to reproduce the behavior:

1. git clone --recursive https://github.com/pytorch/pytorch
... 
2. export CMAKE_PREFIX_PATH=${CONDA_PREFIX:-"$(dirname $(which conda))/../"}
3. MACOSX_DEPLOYMENT_TARGET=10.13.6 CC=clang CXX=clang++ python setup.py install

Illegal instruction: 4

## Expected behavior

This installation was already done some days before and it worked, but without cudnn. 
Pytorch was removed with pip and cudnn files were added.

The same install command, as before and the message "**_Illegal instruction: 4_**" was displayed. Hardware is not changed.

cuddn files removed, install retried - same message.

## Environment

from collect_env:

PyTorch version: N/A
Is debug build: N/A
CUDA used to build PyTorch: N/A

OS: Mac OSX 10.13.6
GCC version: Could not collect
CMake version: version 3.14.0

Python version: 3.6
Is CUDA available: N/A
CUDA runtime version: Could not collect
GPU models and configuration: Could not collect
Nvidia driver version: 1.1.0
cuDNN version: Probably one of the following:
/usr/local/cuda/lib/libcudnn.7.dylib
/usr/local/cuda/lib/libcudnn_static.a

Versions of relevant libraries:

[pip3] numpy==1.18.1
[pip3] numpydoc==0.9.2
[conda] blas                      1.0                         mkl  
[conda] mkl                       2019.4                      233  
[conda] mkl-include               2020.0                      166  
[conda] mkl-service               2.3.0            py36hfbe908c_0  
[conda] mkl_fft                   1.0.15           py36h5e564d8_0  
[conda] mkl_random                1.1.0            py36ha771720_0


--
from conda info:
 
conda version : 4.8.2
conda-build version : 3.18.11
python version : 3.6.10.final.0
virtual packages : __cuda=10.1

--

kextstat | grep -i cuda
  147    0 0xffffff7f8197c000 0x2000     0x2000     com.nvidia.CUDA (1.1.0) 5CF5D7EC-2985-32A1-9150-1BE18678BFC6 <4 1>

cudnn: 7.6.3.30

--

Hardware: 

MacPro 5.1 
NVIDIA GeForce GTX 960
Repository: pytorch
Issue: Sobol engine generates out-of-bounds samples after drawing too many samples
Labels: triaged,module: random

## 🐛 Bug

The SobolEngine should always produce points between [0, 1]. However, after drawing about a billion samples, it produces points far outside this range.

## To Reproduce

```
import torch

i = 1
sobol = torch.quasirandom.SobolEngine(dimension=2)
while True:
  X = sobol.draw(1000000)
  print('iteration: %d, min=%0.9f, max=%0.9f, mean=%0.9f'% (i, X.min(), X.max(), X.mean()))
  i += 1
```

## Expected behavior

The first few iterations are correct (all values between 0 and 1):

```
iteration: 1, min=0.000000954, max=0.999999046, mean=0.499999553
iteration: 2, min=0.000000477, max=0.999999523, mean=0.499999940
iteration: 3, min=0.000000238, max=0.999999762, mean=0.500000298
```

At iteration 1074, the bug appears:

```
iteration: 1072, min=0.000000286, max=0.999998808, mean=0.500000775
iteration: 1073, min=0.000000955, max=0.999999821, mean=0.499999911
iteration: 1074, min=0.000000001, max=131019.000000000, mean=16913.619140625
iteration: 1075, min=0.000000955, max=131019.000000000, mean=65512.328125000
```

## Environment

 - PyTorch Version (e.g., 1.0): 1.4.0
 - OS (e.g., Linux): Linux
 - How you installed PyTorch (`conda`, `pip`, source): pip
 - Build command you used (if compiling from source): N/A
 - Python version: 3.7.5
 - CUDA/cuDNN version: not relevant
 - GPU models and configuration: not relevant
Repository: go
Issue: x/crypto/ssh: add support for hostkeys@openssh.com
Labels: help wanted,Proposal,Proposal-Accepted,NeedsFix,FeatureRequest,Proposal-Crypto

The `hostkeys@openssh.com` extension lets a server notify a client of all its host keys to enable a smooth transition if they have [UpdateHostKeys](https://manpages.debian.org/buster/openssh-client/ssh_config.5.en.html#UpdateHostKeys) enabled. We should offer it server-side.