sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Declaration emit reveals paths within dependency that were not referred to in the source file
Labels: Needs Investigation,Rescheduled

<!-- 🚨 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.
-->

Context:

- Generating declaration files

Declaration emit reveals paths within dependency that were not referred to in the source file:

```ts
export declare const instance: import("dependency/internal-types").TheInterface;
```

This is a problem because changing paths within a dependency can break a dependent package.

**TypeScript Version:**  3.9.0-dev.20200212

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

- [inline import declaration](https://github.com/microsoft/TypeScript/issues?q=is%3Aissue+is%3Aopen+inline+import+declaration)
- [declaration external relative path](https://github.com/microsoft/TypeScript/issues?q=is%3Aissue+is%3Aopen+declaration+external+relative+path+)

**Code**

`node_modules/@types/dependency/entrypoint.d.ts`
```ts
import { TheInterface } from "./internal-types";
export { TheInterface };
export declare function getInstance(): TheInterface;

```

`node_modules/@types/dependency/internal-types.d.ts`
```ts
export interface TheInterface {}
```

`node_modules/@types/dependency/index.d.ts`
```
// empty - doesn't matter for this example
```

`example.ts`
```ts
import { getInstance } from "dependency/entrypoint";
export const instance = getInstance();
```


`src/app/tsconfig.json`
```json
{
    "compilerOptions": {
        "declaration": true,
    }
}
```

**Expected behavior:**

`example.d.ts`
```ts
export declare const instance: import("dependency/entrypoint").TheInterface;
```

**Actual behavior:**

`example.d.ts`
```ts
export declare const instance: import("dependency/internal-types").TheInterface;
```

It seems that part of the solution could involve having the compiler avoid using relative paths in types (`import("<relativepath>").<typename>`) if the `relativepath` is outside the project.

**Repro Repo:** https://github.com/mheiber/repro-rel-import-inlining

**Related Issues:** <!-- Did you find other bugs that looked similar? -->

- Declaration emit should not inline type definitions - #37151
- Proposal: Bundling TS module type definitions - #4433

**Issue written with the help of**: @rricard, @robpalme and @mkubilayk
Repository: pytorch
Issue: Result parameters from Single-Process Multi-GPU DDP training on RNN do not match local training
Labels: oncall: distributed,triaged

The following code passes if `net = nn.Linear(2, 2).cuda()`

```python
ddp = nn.parallel.DistributedDataParallel(
    copy.deepcopy(net),
    process_group=process_group
)

net_opt = torch.optim.Adam(net.parameters(), lr=0.001)
ddp_opt = torch.optim.Adam(ddp.parameters(), lr=0.001)

for i, j in zip(ddp.parameters(), net.parameters()):
    self.assertTrue(i.allclose(j))

for _ in range(1):
    net_out = net(*inp)
    ddp_out = ddp(*inp)

    net_out.sum().backward()
    ddp_out.sum().backward()

    net_opt.step()
    ddp_opt.step()

for i, j in zip(ddp.parameters(), net.parameters()):
    self.assertTrue(i.allclose(j))
```

However,  if I set `net` to the following RNN model, the final parameter `allclose` check would fail. This requires multiple GPUs to reproduce.

```python
BATCH_SIZE = 4
INPUT_DIM = 256
OUTPUT_DIM = 256
HIDDEN_DIM = 256
N_LAYERS = 3
SEQ_LEN = 100

class Net(nn.Module):
    def __init__(self, input_dim, hidden_dim, output_dim, hidden_layers):
        super(Net, self).__init__()
        self.input_dim = input_dim
        self.hidden_dim = hidden_dim
        self.output_dim = output_dim
        self.hidden_layers = hidden_layers

        self.lstm = nn.LSTM(input_dim, hidden_dim, hidden_layers, batch_first=True)
        self.h2o = nn.Linear(hidden_dim, output_dim)

    def forward(self, x, y):
        self.lstm.flatten_parameters()
        h_t, _ = self.lstm(x)
        output = self.h2o(h_t)
        loss = F.mse_loss(output, y)
        return loss

net = Net(INPUT_DIM, HIDDEN_DIM, OUTPUT_DIM, N_LAYERS).cuda()
```

But as Single-Process Multi-GPU is not the recommended mode, we might end up getting rid of this mode soon.

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @xush6528 @osalpekar
Repository: TypeScript
Issue: Recognize property with name defined by constant in Object.defineProperty 
Labels: Suggestion,Awaiting More Feedback

## Search Terms
defineProperty
https://github.com/microsoft/TypeScript/issues/28694 is touching same domain

## Suggestion

(Note: I'm using TS in JS files, have basically no knowledge about "pure" TS)
Compiler should recognize prototype property added using Object.defineProperty with name defined not only by string constant but also a string variable, e.g.:

```
const propName = 'myProp';
Object.defineProperty(Test.prototype, propName, { get: () => 'myVal' });
```
[Playground Link](https://www.typescriptlang.org/play/?experimentalDecorators=true&target=99&ssl=1&ssc=1&pln=21&pc=50&useJavaScript=true#code/PTAEAcCcHtwU0gFwJZwM6gIYBNt26MgHah4BmxcACjPEgJ6gBQAxgDaZoYAq6ioAb1ABfJgHkARgCs4LRADpylGrASJ6ACl5oFUaIn314AGlAByaEThnTQgOZxEALlAaAlKAC8APlABGETcAblZLHVBEAHdoADlMAFs4L3Mo6DMQyRk5RTgKKxU6dS0+eT0DdRMI6LjE21AHZ1cPH1AAJkCQplCicOJwz1ArSNBtRHcQvoVLOAmehVSg0CWQQf1QSFloOyJkAC98UAlGFmh48DZUSC6VvBPITAMrsgBXIjlkS1JNjURMSAaPAImEslplZAolPlaGpNL9-o5SjBykY4KYzPF6AUbIJ6o4XO4vL4zAA3TBsMwdJiiJgAAVu0FYHC4oAAIpt7ogDkJqSc5l8TgBJPkDIas9kPfDjJj0oU6eQYgqLEErIhrDYnbZ7A5HUAnM7INgIIA)
(included also desired behavior for decorators, but as it's experimental feature, you won't propably even consider it)

I understand it's not always possible to make sure variable with property name is not reassigned during runtime, but it seems that TS compiler can handle detection of "static" variables that have known value during compilation.

## Use Cases

This way we could define class properties using "single source" and not duplicating code. For example a class providing access to key-value pairs object in a dotted notation instead of string values for keys, whilst the object can be used for another purpose.

## Examples

```
// i can use these somewhere else, e.g. as a type
export const defaults = {
    one: 1,
    two: 2
}

// properties added in defineProperty
export class Test { 
    // i don't want to repeat myself
    one = defaults.one;

    /** @param {keyof defaults} key */
    get(key) {
        return defaults[key];
    }
}
Object.keys(defaults).forEach((key) =>
    Object.defineProperty(Test.prototype, key, { get: () => defaults[key] })
);

const inst = new Test();
inst.one;   // who would not like this?
inst.get('one');    // instead of this
```
[Playground Link](https://www.typescriptlang.org/play/?useJavaScript=true#)

## 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: flutter
Issue: Define Default Device
Labels: c: new feature,tool,P3,team-tool,triaged-tool

<!-- Thank you for using Flutter!

     If you are looking for support, please check out our documentation
     or consider asking a question on Stack Overflow:
      * https://flutter.dev/
      * https://api.flutter.dev/
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     If you have found a bug or if our documentation doesn't have an answer
     to what you're looking for, then fill our the template below. Please read
     our guide to filing a bug first: https://flutter.dev/docs/resources/bug-reports
-->

## Use case

<!--
     Please tell us the problem you are running into that led to you wanting
     a new feature.

     Is your feature request related to a problem? Please give a clear and
     concise description of what the problem is.

     Describe alternative solutions you've considered. Is there a package
     on pub.dev/flutter that already solves this?
-->

Whenever I load up a project and run `flutter run` I sometimes forget to change the device. For projects such as my website where the default platform isn't mobile it is kinda a pain to have to change the device every time.

## Proposal

<!--
     Briefly but precisely describe what you would like Flutter to be able to do.

     Consider attaching images showing what you are imagining.

     Does this have to be provided by Flutter directly, or can it be provided
     by a package on pub.dev/flutter? If so, maybe consider implementing and
     publishing such a package rather than filing a bug.
-->

Define in your `pubspec.yaml` the default device or platform. For example `default: macOS`
Repository: flutter
Issue: odd behavior of Link in MemoryFileSystem on windows
Labels: tool,P2,team-tool,triaged-tool

```
final FileSystem fileSystem = MemoryFileSystem.test();
fileSystem.file('a/b.txt').createSync(recursive: true);
final Link link = fileSystem.link('a/c.txt').createSync('a/b.txt');
print(link.existsSync()); // prints true
print(fileSystem.typeSync('a/c.txt')); // prints "notFound"
```
Repository: rust
Issue: All debuginfo tests fail on sparc64 on Linux
Labels: A-testsuite,A-debuginfo,T-compiler,O-SPARC,C-bug

One of the few remaining issues on sparc64 on Linux are the debuginfo tests, they all fail which is why I assume we're missing some definitions here or there something regarding the debugging part is generally broken:

```
test [debuginfo-gdb] debuginfo/borrowed-c-style-enum.rs ... FAILED
test [debuginfo-gdb] debuginfo/borrowed-enum.rs ... FAILED
test [debuginfo-gdb] debuginfo/borrowed-basic.rs ... FAILED
test [debuginfo-gdb] debuginfo/function-call.rs ... FAILED
test [debuginfo-gdb] debuginfo/generic-enum-with-different-disr-sizes.rs ... FAILED
test [debuginfo-gdb] debuginfo/generic-struct.rs ... FAILED
test [debuginfo-gdb] debuginfo/evec-in-struct.rs ... FAILED
test [debuginfo-gdb] debuginfo/extern-c-fn.rs ... FAILED
test [debuginfo-gdb] debuginfo/gdb-pretty-struct-and-enums.rs ... FAILED
test [debuginfo-gdb] debuginfo/by-value-self-argument-in-trait-impl.rs ... FAILED
test [debuginfo-gdb] debuginfo/generic-struct-style-enum.rs ... FAILED
test [debuginfo-gdb] debuginfo/include_string.rs ... FAILED
test [debuginfo-gdb] debuginfo/generic-tuple-style-enum.rs ... FAILED
test [debuginfo-gdb] debuginfo/lexical-scope-in-unique-closure.rs ... FAILED
test [debuginfo-gdb] debuginfo/lexical-scope-in-stack-closure.rs ... FAILED
test [debuginfo-gdb] debuginfo/lexical-scope-in-match.rs ... FAILED
test [debuginfo-gdb] debuginfo/lexical-scope-in-unconditional-loop.rs ... FAILED
test [debuginfo-gdb] debuginfo/lexical-scope-in-for-loop.rs ... FAILED
test [debuginfo-gdb] debuginfo/destructured-local.rs ... FAILED
test [debuginfo-gdb] debuginfo/lexical-scope-in-while.rs ... FAILED
test [debuginfo-gdb] debuginfo/lexical-scope-in-if.rs ... FAILED
test [debuginfo-gdb] debuginfo/destructured-fn-argument.rs ... FAILED
test [debuginfo-gdb] debuginfo/lexical-scope-with-macro.rs ... FAILED
test [debuginfo-gdb] debuginfo/multi-cgu.rs ... FAILED
test [debuginfo-gdb] debuginfo/multiple-functions-equal-var-names.rs ... FAILED
test [debuginfo-gdb] debuginfo/multiple-functions.rs ... FAILED
test [debuginfo-gdb] debuginfo/shadowed-argument.rs ... FAILED
test [debuginfo-gdb] debuginfo/name-shadowing-and-scope-nesting.rs ... FAILED
test [debuginfo-gdb] debuginfo/static-method-on-struct-and-enum.rs ... FAILED
test [debuginfo-gdb] debuginfo/simd.rs ... FAILED
test [debuginfo-gdb] debuginfo/simple-lexical-scope.rs ... FAILED
test [debuginfo-gdb] debuginfo/shadowed-variable.rs ... FAILED
test [debuginfo-gdb] debuginfo/tuple-style-enum.rs ... FAILED
test [debuginfo-gdb] debuginfo/tuple-in-tuple.rs ... FAILED
test [debuginfo-gdb] debuginfo/tuple-struct.rs ... FAILED
test [debuginfo-gdb] debuginfo/struct-style-enum.rs ... FAILED
test [debuginfo-gdb] debuginfo/var-captured-in-sendable-closure.rs ... FAILED
test [debuginfo-gdb] debuginfo/tuple-in-struct.rs ... FAILED
```

Any pointers where I should start looking?

Full log at: https://buildd.debian.org/status/fetch.php?pkg=rustc&arch=sparc64&ver=1.42.0%2Bdfsg1-1&stamp=1586554512&raw=0

CC @psumbera
Repository: storybook
Issue: Addon-Docs: Changing the theme via api doesn't persist in Docs
Labels: feature request,theming,addon: docs

**Describe the bug**
I have an addon tool that handles the storybook theme through the api:
```
// inside my addon

api.setOptions ({
  theme: themes[base],
});
```
The Storybook matches, but Docs don't change.
Docs works with the dark theme just by adding through addParametes:
```
// config.js

import { themes } from '@storybook/theming';

addParameters({
  options: {
    theme: themes.dark,
},
```

**Expected behavior**
That when changing the theme through the storybook API, it trigger the Docs theme

**Screenshots**
![issue](https://user-images.githubusercontent.com/828776/80021314-affe2380-84b0-11ea-85d9-1c334ff79000.png)

**System:**
Environment Info:

  System:
    OS: macOS 10.15.4
    CPU: (4) x64 Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
  Binaries:
    Node: 10.16.0 - /usr/local/bin/node
    Yarn: 1.9.4 - /usr/local/bin/yarn
    npm: 6.13.7 - /usr/local/bin/npm
  Browsers:
    Chrome: 81.0.4044.122
    Firefox: 74.0
    Safari: 13.1
  npmPackages:
    @storybook/addon-a11y: ^5.3.18 => 5.3.18
    @storybook/addon-actions: ^5.3.18 => 5.3.18
    @storybook/addon-docs: ^5.3.18 => 5.3.18
    @storybook/addon-knobs: ^5.3.18 => 5.3.18
    @storybook/addon-storysource: ^5.3.18 => 5.3.18
    @storybook/addon-viewport: ^5.3.18 => 5.3.18
    @storybook/addons: ^5.3.18 => 5.3.18
    @storybook/react: ^5.3.18 => 5.3.18
    @storybook/storybook-deployer: ^2.8.3 => 2.8.5
Repository: go
Issue: x/tools/gopls: autocompletion is appended to typed word
Labels: help wanted,gopls,Tools

#### What did you do?
In VSCode, typed part of a word to autocomplete it, e.g. `cancel`, then selected `cancelCtx`.

#### What did you expect to see?
I expected the current word to be `cancelCtx`.

#### What did you see instead?
Current word became `canccancelCtx`.

![gopls](https://user-images.githubusercontent.com/50314/80025413-9bb92700-84ae-11ea-939d-a8a618ffe6b1.gif)

#### Build info

Also getting this behaviour with v0.4.0.

```
golang.org/x/tools/gopls v0.3.4
    golang.org/x/tools/gopls@(devel)
    github.com/BurntSushi/toml@v0.3.1 h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ=
    github.com/sergi/go-diff@v1.0.0 h1:Kpca3qRNrduNnOQeazBd0ysaKrUJiIuISHxogkT9RPQ=
    golang.org/x/mod@v0.1.1-0.20191105210325-c90efee705ee h1:WG0RUwxtNT4qqaXX3DPA8zHFNm/D9xaBpxzHt1WcA/E=
    golang.org/x/sync@v0.0.0-20190423024810-112230192c58 h1:8gQV6CLnAEikrhgkHFbMAEhagSSnXWGV915qUMm9mrU=
    golang.org/x/tools@v0.0.0-20200316194252-fafb6e2e8a4a => ../
    golang.org/x/xerrors@v0.0.0-20191011141410-1b5146add898 h1:/atklqdjdhuosWIl6AIbOeHJjicWYPqR9bpxqxYG2pA=
    honnef.co/go/tools@v0.0.1-2020.1.3 h1:sXmLre5bzIR6ypkjXCDI3jHPssRhc8KD/Ome589sc3U=
    mvdan.cc/xurls/v2@v2.1.0 h1:KaMb5GLhlcSX+e+qhbRJODnUUBvlw01jt4yrjFIHAuA=
```

#### Go info

```
go version go1.14 darwin/amd64

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/alex/Library/Caches/go-build"
GOENV="/Users/alex/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GONOPROXY="github.com/t11e/*,github.com/sanity-io/gradient"
GONOSUMDB="github.com/t11e/*,github.com/sanity-io/gradient"
GOOS="darwin"
GOPATH="/Users/alex/.go"
GOPRIVATE="github.com/t11e/*,github.com/sanity-io/gradient"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/opt/go/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/opt/go/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/alex/Code/golang-tools/gopls/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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/qs/wpmg19r12_9_nz7pvvs2_82r0000gn/T/go-build188118376=/tmp/go-build -gno-record-gcc-switches -fno-common"
```

#### VSCode

```
Version: 1.44.2
Commit: ff915844119ce9485abfe8aa9076ec76b5300ddd
Date: 2020-04-16T17:07:18.473Z
Electron: 7.1.11
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Darwin x64 19.3.0
```

VSCode-Go 0.14.1.

#### Log

[gopls.log.gz](https://github.com/golang/go/files/4518601/gopls.log.gz)
Repository: pytorch
Issue: Legacy fuser doesn't do remainder consistently with `aten::remainder`
Labels: oncall: jit,triaged

## 🐛 Bug

aten::remainder follows numpy.remainder implementation (https://docs.scipy.org/doc/numpy/reference/generated/numpy.remainder.html) Which is not from IEEE remainder -> remainderf (https://en.cppreference.com/w/cpp/numeric/math/remainder)

In legacy fuser, we are using remainderf: https://github.com/pytorch/pytorch/blob/5fc391a6465d1f7197008085bb521b6dfaccc8b3/torch/csrc/jit/codegen/fuser/codegen.cpp#L243

This yields different results between jitted module and torch module.

## To Reproduce

Steps to reproduce the behavior:
```
import torch

def t(x : torch.Tensor, y : torch.Tensor):
    o = torch.remainder(x, y)
    o = torch.relu(o)
    return o
t_jit = torch.jit.script(t)
x = torch.cuda.FloatTensor([-0.8])
y = torch.cuda.FloatTensor([-1.5])
jit_o = t_jit(x, y)
torch.cuda.profiler.start()
jit_o = t_jit(x, y)
torch.cuda.profiler.stop()
o = t(x, y)
print(o, jit_o)
assert(o.allclose(jit_o))
```

cc @suo
Repository: pytorch
Issue: [JIT] Use of global value creates confusing error message
Labels: oncall: jit,triaged,small

```
import torch

XYZ = 3

@torch.jit.script
def foo(x):
    return x + XYZ
====
python value of type 'int' cannot be used as a value:
  File "global.py", line 7
@torch.jit.script
def foo(x):
    return x + XYZ
               ~~~ <--- HERE
```

"cannot be used as a value" here doesn't really impart any information that would be useful to the user. We should at least improve the error message or make it so that these situations are better supported in our model of the world

cc @suo
Repository: rust
Issue: Implement TryInto<CString> for str and String
Labels: A-FFI,T-libs-api,C-feature-request

Higher-level FFI wrappers that need to present a `CString` to C don't have a convenient + efficient type to take on the Rust side.

```rust
ffi_string(arg: ???) {
   let c_string = CString::new(arg)?;
   ffify(c_string.as_ptr());
}
```

* Taking `CString` is cumbersome, as it doesn't work with simple `&str` and requires callers to do the conversion and handle NUL errors.

* Taking `String` or `Vec<u8>` is efficient only if it happens to have spare capacity, but `"foo".to_string()` doesn't have any spare capacity.

* Taking `&str` always needs to allocate.


Taking `impl TryInto<CString>` would be ideal, if that trait was implemented for common string-like types.
Repository: pytorch
Issue: pip install torch==1.4.0 is broken when using CUDA 10.1
Labels: module: build,triaged

## 🐛 Bug

The default CUDA version for the PyTorch 1.4.0 wheels is CUDA 10.1, but `pip install` defaults to CUDA 9.2 and does not let you install the 10.1 wheel.

Across Python 2.7, 3.6, 3.7, 3.8:

`pip install -f https://download.pytorch.org/whl/torch_stable.html torch==1.4.0`

will install the `cu92` wheel instead of the `cu101` wheel.


The following command complains that it can't find the requested version
`pip install -f https://download.pytorch.org/whl/torch_stable.html torch==1.4.0+cu101`

This makes sense as the 10.1 wheels for torch 1.4.0 don't have a suffix. Maybe this is related to the 1.5.0 release from yesterday?

## To Reproduce

Steps to reproduce the behavior:

1. `docker run -it --rm python:2.7 /bin/bash` (replacing `2.7` with each python version above)
2. `pip install -f https://download.pytorch.org/whl/torch_stable.html torch==1.4.0`

```
root@40e0b8aa1d83:/# pip install -f https://download.pytorch.org/whl/torch_stable.html torch==1.4.0
Looking in links: https://download.pytorch.org/whl/torch_stable.html
Collecting torch==1.4.0
  Downloading https://download.pytorch.org/whl/cu92/torch-1.4.0%2Bcu92-cp38-cp38-linux_x86_64.whl (640.6 MB)
     |▌                               | 10.3 MB 9.9 MB/s eta 0:01:04^C
ERROR: Operation cancelled by user
root@40e0b8aa1d83:/#
```

3. `pip install -f https://download.pytorch.org/whl/torch_stable.html torch==1.4.0+cu101`

```
root@40e0b8aa1d83:/# pip install -f https://download.pytorch.org/whl/torch_stable.html torch==1.4.0+cu101
Looking in links: https://download.pytorch.org/whl/torch_stable.html
ERROR: Could not find a version that satisfies the requirement torch==1.4.0+cu101 (from versions: 0.1.2, 0.1.2.post1, 0.1.2.post2, 1.4.0, 1.4.0+cpu, 1.4.0+cu100, 1.4.0+cu92, 1.5.0, 1.5.0+cpu, 1.5.0+cu101, 1.5.0+cu92)
ERROR: No matching distribution found for torch==1.4.0+cu101
root@40e0b8aa1d83:/#
```

## Expected behavior

`pip install -f https://download.pytorch.org/whl/torch_stable.html torch==1.4.0`

should install Torch 1.4.0 with CUDA 10.1 support


cc @malfet