sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Rename a symbol of a named export: Do not create export alias
Labels: Suggestion,In Discussion

- VSCode Version: 1.30
- OS Version: Win 10

When I rename a symbol which is a named export in a module, then there is just an alias created in the module `export` (VS Code 1.30). What I would expect is that the symbol is renamed in the module export AND all in all modules that are importing it (that is the bevavior of 1.29.1). Or an option by which I can specify the old behavior. This feature is soo useful to rename a bunch of modules.

Release notes of 1.30 only include some [rename changes for destructuring ](https://code.visualstudio.com/updates/v1_30#_renames-handle-jsts-destructuring-properly), but I did not have any destructuring in code.

Old (1.29.1):

![vscode_1 29 1](https://user-images.githubusercontent.com/16099458/50003130-e82f5100-ffa2-11e8-8f9e-eb7de99e3beb.gif)

New (1.30):

![vscode_1 30](https://user-images.githubusercontent.com/16099458/50003146-fc734e00-ffa2-11e8-8d7c-b1cbfa39380f.gif)


Does this issue occur when all extensions are disabled?: Yes, running clean versions of 1.30, 1.29.1

~~PS: Typescript 3.2.2 in both tests.~~

// EDIT:

Actually, after all VS Code 1.29.1 did use Typescript *3.1.4* in the first test, not 3.2.2. Switching to TS 3.2.2 with the old 1.29.1 version,  the same behavior (just aliasing the export instead of renaming in the whole workspace) reoccurs.
I am not sure, if there are interdependencies between VS Code and TS and therefore leave the issue open or not?
Repository: go
Issue: html/template: ambiguous errors when style tag is not closed
Labels: 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.11.3 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes


### What operating system and processor architecture are you using (`go env`)?
<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/george/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/george/.go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/george/tmp/resume/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-build336466026=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?
Ran the following program: https://play.golang.org/p/BtMWAAxnb3o


### What did you expect to see?
Program not returning an error, or at least an error informing that the style tag was not closed.


### What did you see instead?
```
html/template:test:11:17: {{.}} appears in an ambiguous context within a URL
```
Repository: rust
Issue: For *-apple-ios targets, if license agreement is not agreed to (yet), better behaviour is necessary
Labels: O-ios,T-compiler,A-licensing

Currently if one attempts to use `*-apple-ios` targets right after XCode is installed, it will appear that the target does not exist. This happens because `xcrun` says something about license, sudo and whatnot.

We should have a better behaviour here.

![bad behaviour](https://user-images.githubusercontent.com/679122/50029796-b054f780-fffc-11e8-90fa-805a16dd9bef.png)
Repository: pytorch
Issue: Gather backward is faster than integer indexing on GPU
Labels: module: performance,triaged,module: determinism

## 🚀 Feature

When x is a tensor of shape (N, D) and idx is a tensor of indices of shape K, the backward pass of x[idx] is much slower than the equivalent operation implemented using gather. Here is a benchmarking script:

https://gist.github.com/jcjohnson/b03a0275e64681bb7587bbc7399a645a

On a P100 GPU with PyTorch 1.0 stable, across a variety of problem shapes I get the following results:

```
Forward gather speedup:
  Min:  0.7549055905220289
  Max:  5.590410529614541
  Mean:  0.9328673787035276
  Median:  0.880012936610608
Backward gather speedup:
  Min:  1.6313537996980372
  Max:  23.95120218579235
  Mean:  3.340551245050125
  Median:  1.8802246977054176
```

Basically this says that on the forward pass index is sometimes faster and gather is sometimes faster. However on the backward pass, gather is always faster than integer indexing.

This is surprising, and suggests that although the two operations perform the same computation their implementations have very different performance characteristics. Integer indexing is much more intuitive than gather, so I suspect that many users are unknowingly leaving a lot of performance on the table by choosing integer indexing over gather. In one of my own applications, replacing integer indexing with gather resulted in a more than 2x speedup on my overall training iteration times!

Would it be possible to somehow unify the implementation of the two operations, or otherwise ensure that integer indexing always performs at least as well as gather?
Repository: TypeScript
Issue: querySelector return type could be more specific for compound selectors
Labels: Suggestion,In Discussion,Domain: lib.d.ts

## Search Terms

querySelector, return, type, selector

## Suggestion

This issue closely follows #8114, which applies only to **type selectors** ("single-element selectors"). Related to #12568.

The return type of [ParentNode#querySelector](https://developer.mozilla.org/en-US/docs/Web/API/ParentNode/querySelector) is `Element` by default, but when the string argument matches exactly a lower-case element name, the return type is the interface of that element.

For example, `.querySelector('#hero.wide')` returns an `Element` type, but `.querySelector('img')` returns an `HTMLImageElement` type.

This helpful behavior fails beyond **simple type selectors** (a selector containing only an element name). When the argument becomes a [compound selector](https://www.w3.org/TR/selectors-4/#structure), such as `.querySelector('img#hero.wide')`, the return type is the more generic `Element`. This is unhelpful when the element name, `img`, remains in the selector.

My suggestion is to improve parsing of the string argument, so that when it is a **compound selector that contains a type selector**, the return type can still be a specific interface. Obviously, this would not apply to selectors *not* containing a type selector, e.g. there is no way to know for sure that `.querySelector('#hero.wide')` is indeed an `HTMLImageElement`.

## Use Cases
```ts
document.querySelector('#hero.wide').src = '//example.com/hero.png' // Element
// Error: Property 'src' does not exist on type 'Element'

document.querySelector('img').src = '//example.com/hero.png' // HTMLImageElement
// no error, but cannot specify *which* image

document.querySelector('img#hero.wide').src = '//example.com/hero.png' // Element
// Error: Property 'src' does not exist on type 'Element'

(document.querySelector('img#hero.wide') as HTMLImageElement).src = '//example.com/hero.png'
// no error, and can specify which image, but must assert type manually
```
**Summary: It would be nice for TS to infer that `img#hero.wide` selects an `HTMLImageElement`, based on the tag name `img` in the selector. This would eliminate the need to assert the type manually.**

## 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). *(Specifically: Goals 5, 6, and 9)*
Repository: pytorch
Issue: [caffe2] controlled forward pass
Labels: caffe2

## ❓[caffe2] I am in need of running a controlled forward pass for a model I am working on. As in execute a layer collect its output do some manipulation on it and feed the data to the next layer. 

How do we do this in caffe2 ? caffe does allow caffe.forward(start=<>, end=<>) python API. Can we do the same in caffe2

- [Discussion Forum](https://discuss.pytorch.org/)
Repository: TypeScript
Issue: Improve signature help when completing object argument
Labels: Suggestion,Needs Proposal,Domain: Signature Help

From https://github.com/Microsoft/vscode/issues/56270

<!-- 🚨 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.20181214

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

**Code**
For a simple TS File:

```js
function foo(x: number, i: { ab: number, cd: number }) { }

foo(1, {
```

Trigger signature help on  last line.

**Problem:**
We currently just display the entire type in signature help:

![screen shot 2018-12-14 at 5 40 27 pm](https://user-images.githubusercontent.com/12821956/50037548-630a6300-ffc7-11e8-871b-64c9602f7dd8.png)

Some possible quality of life improvements:

* Underline which parameter you are currently typing and show its documentation
* Show which parameters have already been completed vs which ones are missing

This is likely not supported by the current VS Code api. Opening this issue for further discussion on how this could be improved

/cc @DanielRosenwasser
Repository: pytorch
Issue: [Feature Request] cdist: pairwise distances between two sets of tensors with batch mode
Labels: triaged,module: batching,function request,module: distance functions

Now we've already had [F.pdist](https://pytorch.org/docs/stable/nn.html?highlight=pdist#torch.nn.functional.pdist), which computes pairwise distances between each pair in **a single set** of vectors.

However, in retrieval problems, we often need to compute the pairwise distances between each pair consisting one sample from a probe/query set and another sample from a gallery/database set, in order to evaluate the performances of a retrieval model. 

Specifically, if the database tensor has size N-by-D and the query M-by-D, the tensor returned by a *cdist* function should have size N-by-M where the (i, j)-th element is the distance between the i-th sample from the database and the j-th sample from the query.

Currently, a plausible way (ok, I use this method because I had no idea about GPU programming to achieve better performance) to do this evaluation is:
1. transform the tensor to a numpy array: query_np = query.cpu().numpy(), database_np = database.cpu().numpy()
2. using [cdist](https://docs.scipy.org/doc/scipy/reference/generated/scipy.spatial.distance.cdist.html) provided by scipy: dist_matrix = cdist(query_np, database_np)

which is really far from elegent and could not utilize GPU power and thus inefficient. So, could we develop some efficient cdist function which can use GPU, and hopefully act like [cdist in scipy](https://docs.scipy.org/doc/scipy/reference/generated/scipy.spatial.distance.cdist.html)?
Repository: pytorch
Issue: err:torch.nn.CrossEntropyLoss
Labels: module: docs,triaged

pytorch 1.0
DOC err:torch.nn.CrossEntropyLoss
if weight=NONE
loss(x,class)=−x[class]+log(j∑​exp(x[j])) ,The result is correct.

if weight!=NONE
loss(x,class)=weight[class]*(−x[class]+log(j∑​exp(x[j]))) ,The result is wrong?
```
import torch
import torch.nn.functional as F
a=[[-5.,-6.],[3.,2.],[3.,2.]]
c=[1,0,1]
b=[3.,2.]
input=torch.tensor(a,requires_grad=True)
target = torch.tensor(c)
weight = torch.tensor(b)
output = F.cross_entropy(input,target,weight,reduce=True,size_average=True)
z=output.sum()
z.backward()
print(output,input.grad)
--------------------------
tensor(0.8847, grad_fn=) tensor([[ 0.2089, -0.2089],
[-0.1153, 0.1153],
[ 0.2089, -0.2089]])
```



cc @brianjo @mruberry
Repository: pytorch
Issue: MultiGPU for gru
Labels: module: rnn,triaged,module: data parallel

## 🐛 Bug

<!-- A clear and concise description of what the bug is. -->

During runtime of GRU under multi-GPU environment, there is a RuntimeError: Expected hidden size (3, 64, 12), got (3, 16, 12) where the first, second, and third arguments are the number of GRU layers, batch size and number of hidden units respectively. My model run well under single-GPU environment.

In Pytorch Forum, a question "DataParallel LSTM/GRU wrong hidden batch size (8 GPUs)" has been asked. One solution is to set batch_first to True for gru. But the error was still there after the setting. The correct solution is to store the hidden state inside the model rather than return it like the below code block(from user AnodyneCodeAsher Newcomer):

```python
class LSTM(nn.Module):
    def __init__(self, initial_state):
        super(LSTM, self).__init__()

        self.lstm = nn.LSTM(
            ...
            batch_first=True)
        self.hn = initial_state
            
    def forward(self, input):
        output, hn = self.lstm(input, self.hn)
        self.hn = hn
        return output
```


<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->
My wrong code sample:
```python
class LSTM(nn.Module):
    def __init__(self, initial_state):
        super(LSTM, self).__init__()

        self.lstm = nn.LSTM(
            ...
            batch_first=True)
            
    def forward(self, input, hidden):
        output, hn = self.lstm(input, hidden)
        return output, hn
```
Please help to fix this bug. Thanks a lot.

## Environment
 - PyTorch Version 1,0:
 - OS Ubuntu 16.04:
 - How you installed PyTorch`pip`:
 - Python version: 3.6
 - CUDA/cuDNN version: 9.0





cc @zou3519
Repository: TypeScript
Issue: Separate type application from function application
Labels: Suggestion,Awaiting More Feedback

As discussed in #28931, currently the type application for the function with generic parameters is tied to that function application. 

Specialize the value of the function with generics is only possible during the call. So the following compiles fine:
```ts
function id<V> (v : V) { return v }

const some : Date = id<Date>(new Date())
```
But this does not:
```ts
function id<V> (v : V) { return v }

type IdDate         = typeof id<Date> // TS1005: ';' expected 

const dateId        = id<Date> // TS1109: Expression expected.
```
It would be very beneficial to separate type application from function application. For example (the original reason of this request), it will allow mixins with generic parameters:
```ts
export type Constructable<T extends any> = new (...args : any[]) => T
export type AnyFunction             = (...input: any[]) => any
export type Mixin<T extends AnyFunction> = InstanceType<ReturnType<T>>

export const Atom = <V, T extends Constructable<Object>>(base : T) =>

class Atom extends base {
    value               : V

    hasValue () : boolean {
        return this.hasOwnProperty('value')
    }
}

export type Atom = Mixin<typeof Atom> // this currently works, but does not have generic argument

export type Atom<V> = Mixin<typeof Atom<V>> // this is the goal
```
Repository: TypeScript
Issue: Vscode suggests wrong ts auto import path with js extension after having a json import
Labels: Bug,Domain: TSServer

<!-- 🚨 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.1.6, but also tried with 3.3.0-dev.201xxxxx

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** auto import json wrong module path js extension issue bug

**Code**

https://stackblitz.com/edit/typescript-json-import-issue

**I am not using any vscode extension for managing imports and as far as I know vscode depends on typescript to show the module import suggestions, so I hope this is the right place for this issue.**

tsconfig.json
```
{
	"compilerOptions": {
		"module": "es2015",
		"moduleResolution": "node",
		"resolveJsonModule": true,
		"esModuleInterop": true
	}
}
```

**Expected behavior:**

When we have: 
`import packageJson from './package.json';`
in VSCode auto import modules autocomplete to suggest: 
`import { testing } from './test';`

**Actual behavior:**

in VSCode auto import modules autocomplete suggests: 
`import { testing } from './test.js';`

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: go
Issue: runtime: exceeded thread wakeup limitation on iOS
Labels: mobile,compiler/runtime

We found my gomobile iOS application crash with the below message:

```
Event:           wakeups
Action taken:    none
Wakeups:         45001 wakeups over the last 64 seconds (704 wakeups per second average), exceeding limit of 150 wakeups per second over 300 seconds
Wakeups limit:   45000
Limit duration:  300s
Wakeups caused:  45001
Duration:        17.04s
Steps:           18

Hardware model:  iPhone8,1
Active cpus:     2
Boot args: 
```

I guess Go runtime switched threads so many times that iOS complained, but I am not sure. It is hard to create a minimal code to reproduce this problem, but I'd like to report this (potential) problem in gomobile.
Repository: TypeScript
Issue: Document quick fix (or whatever it's officially called)
Labels: Suggestion,In Discussion

<!-- 🚨 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.201xxxxx

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
code fix
quick fix
suggestion

**Code**
not entirely applicable, but this is what I had which caused me to get confused
```ts
const fs = require("fs");
```

**Expected behavior:**
Commandline `tsc` should behave the same as editor integrations

**Actual behavior:**
The "quick fix" feature, which appears to be called "code fixes" in the codebase and googling the messages led me to the json file which refers to them as "suggestions", only appears to exist in the typescript server.

As a newcomer this had me extremely confused. I was running `tsc` on the commandline and getting no errors, but seeing squiggly lines and messages in my editor (atom, in this case).

I was unable to find any documentation about where the message `'require' call may be converted to an import` was coming from, or that this was a hint that typescript was able to fix my code for me.

It would also be helpful if the `tsc` client was able to list the code fix suggestions, even if giving it a way to apply them would be too complex.

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->
n/a

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
none that I could find
Repository: rust
Issue: rustc should output a warning when it encounters problems locating cross-crate sources for error messages
Labels: C-enhancement,A-diagnostics,T-compiler

See #53081 - currently it is hard to diagnose what path it is actually looking for.

Problems might include:
- can't find the file
- the file has the wrong hash.
Repository: godot
Issue: [Bullet] Rigidbody doesn't appear to apply rotation
Labels: bug,confirmed,topic:physics

Godot 3.1 alpha calinou 6f9aa87 (downloaded 12/4/2018) Windows 10 64-bit

I am applying a rotation on my rigidbody. It appears correct in the viewport. When I actually play my project, the rotation seems to only apply to the collisionshape, but not the mesh. I am attaching a sample project.

You will see the viewport has a different rotation than the actual gameplay. If you select the floor object and rotate it back to 0, everything works as expected again. 

potentially related to this ticket... https://github.com/godotengine/godot/issues/22904

[rigidbody-rotate-test.zip](https://github.com/godotengine/godot/files/2683063/rigidbody-rotate-test.zip)
Repository: rust
Issue: prelude path should not appear in error messages
Labels: C-enhancement,A-diagnostics,T-compiler,D-papercut

(Split off from discussion on #56188.)

There are a few places where the path `std::prelude::v1` appears in diagnostic messages.

```
zmd@ReflectiveCoherence:~/Code/rust/src/test/ui$ ag std::prelude
[...]
27 matches
9 files contained matches
```

I argue that this is bad because the point of the prelude is to relieve the ordinary programmer from having to think about where necessities like `Some` and `Vec` live; the module `std::prelude::v1` is an implementation detail that should be mentioned in places like the Book, but which I don't want to see cluttering up error messages.

We are manually stripping off the `std::prelude::v1::` in a couple places ([one](https://github.com/rust-lang/rust/commit/80c603fc6589aaf70df7c142723eef9a1d28aec5), another proposed in open PR #56188), but we should:

 - [ ] strip `std::prelude::v1::` for _all_ diagnostic messages
 - [ ] do so in a unified [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) way, rather than having that hardcoded string littering the codebase in several places