sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: The `@` operation uses too much memory on GPU
Labels: needs reproduction,module: memory usage,triaged

## 🐛 Bug

<!-- A clear and concise description of what the bug is. -->

## To Reproduce

#### A

```py
>>> x = torch.randn(100, 128, 512, requires_grad=True)
>>> y = torch.randn(100, 128, 512, requires_grad=True)
>>> w = torch.randn(50, 512, 512, requires_grad=True)
>>> s = (x.unsqueeze(1) @ w @ y.unsqueeze(1).transpose(-1,-2))
```

#### B

```py
>>> x = torch.randn(100, 128, 512, requires_grad=True)
>>> y = torch.randn(100, 128, 512, requires_grad=True)
>>> w = torch.randn(50, 512, 512, requires_grad=True)
>>> s = torch.einsum('bxi,oij,byj->boxy', x, w, y)
```

The above two operations are equivalent. But **A** uses 10224M of memory on GPU and **B** uses only 4024M. And increasing the size of the last dimension quickly causes an OOM error.

Seems to be a problem similar to #18862. 

## Environment

 - PyTorch Version (e.g., 1.0): 1.3.0
 - OS (e.g., Linux): Linux
 - How you installed PyTorch (`conda`, `pip`, source): `conda`
 - Python version: 3.7
 - CUDA/cuDNN version: 9.0
Repository: rust
Issue: FnAbi computation should be cached.
Labels: C-enhancement,A-codegen,I-compiletime,T-compiler

We might be spending a non-trivial amount of time creating `FnAbi`s and adjusting them, so we should investigate caching them, similar to how we cache LLVM `Type`s we compute from Rust `Ty`s.

After #65947, this is what's left:
* `FnAbi::of_instance`: takes `ty::Instance`, easy to cache
  * we should be able to make this a query, like `layout_of` is
* `FnAbi::of_fn_ptr`: takes `ty::PolyFnSig`, might be more expensive
  * well, `inputs_and_outputs` is compared/hashed by pointer nowadays, isn't it?
  * creating LLVM `Type`s for `fn` pointers is already cached itself, but calls of `fn` pointers also require `FnAbi`s
  * this is likely used less than `FnAbi::of_instance`, so it's lower priority
Repository: pytorch
Issue: [feature request] Some activations modules missing inplace argument
Labels: module: nn,triaged,enhancement

E.g. nn.Tanh and nn.Sigmoid are missing inplace argument, though torch.Tensor.sigmoid_ exists (although torch.nn.functional.sigmoid does not support inplace/out argument either)

https://pytorch.org/docs/master/tensors.html?highlight=sigmoid_#torch.Tensor.sigmoid_

consistency wrt out arguments is nice to easier support inplace mode like in https://github.com/pytorch/pytorch/issues/26644#issuecomment-534762427

In the wild one then has to implement custom consistent wrappers: https://github.com/rwightman/gen-efficientnet-pytorch/blob/master/geffnet/activations/activations.py#L40
Repository: vue
Issue: Trigger a warning when v-show and other incompatible directives are used on <template>
Labels: discussion,warnings

### What problem does this feature solve?
Hi,

I lost quite some time trying to figure out when my code didn't work.
The error was on my part, not vue, but i think Vue should trigger an error in this case.

The problem is that you CANNOT use `v-show` on a `<template>` tag, which make sense since `v-show` add inline style to the node and the `<template>` tag does not render a node.

### What does the proposed API look like?
A Vue warning/error should suggest changing the `v-if` (if possible) or change the `<template>` tag for a DOM element (like a `<div>`)

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: rust
Issue: Using thread-local state inside proc-macro causes ICE
Labels: A-diagnostics,I-ICE,A-macros,T-compiler,A-thread-locals,E-needs-mcve,A-proc-macros

ICE will be produced on any channel.

Error:
```
thread 'rustc' panicked at 'use-after-free in `proc_macro` handle', src/libcore/option.rs:1190:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.39.0-beta.1 (968967007 2019-09-24) running on x86_64-apple-darwin

note: compiler flags: -C debuginfo=2 -C incremental --crate-type bin

note: some of the compiler flags provided by cargo are hidden

error: custom attribute panicked
 --> proc_macro_bug/src/main.rs:7:1
  |
7 | #[some_macro(0)]
  | ^^^^^^^^^^^^^^^^
  |
  = help: message: use-after-free in `proc_macro` handle

error: aborting due to previous error

error: could not compile `proc_macro_bug`.
```

`LocalKey` used in macro generation:
```rust
extern crate proc_macro;
extern crate quote;
extern crate syn;

use proc_macro::TokenStream;
use quote::quote;
use syn::{parse_quote, Path};

thread_local! {
    static DEFAULT_CRATE_PATH: Path = parse_quote! { ::std };
}

#[proc_macro_attribute]
pub fn some_macro(_: TokenStream, _: TokenStream) -> TokenStream {
    TokenStream::from(DEFAULT_CRATE_PATH.with(|default_crate_path| {
        quote! {
            use #default_crate_path::boxed::Box;
        }
    }))
}
```

Macro calls (should be 2 at least) which produce error:
```rust
#[some_macro(0)]
struct Abc {}

#[some_macro(0)]
struct Cde {}

fn main() {}
```

Repo with minimal code sample: https://github.com/olegnn/proc-macro-ICE.
Repository: go
Issue: cmd/go: TestScript/mod_import failure on darwin-amd64-nocgo
Labels: help wanted,OS-Darwin,NeedsInvestigation

`darwin-amd64-nocgo` (https://build.golang.org/log/b64b26f0f1ea99d0a15dbe847285ee310af7fae9):

```
go test proxy running at GOPROXY=http://127.0.0.1:57008/mod
go proxy: no archive rsc.io v1.1.0: file does not exist
go proxy: no archive rsc.io v1.5.2: file does not exist
go proxy: no archive rsc.io v1.0.0: file does not exist
go proxy: no archive rsc.io v1.0.0: file does not exist
go proxy: no archive rsc.io v1.0.0: file does not exist
go proxy: no archive rsc.io v1.0.0: file does not exist
go proxy: no archive rsc.io v1.5.1: file does not exist
go proxy: no archive example.com/newcycle v1.0.0: file does not exist
go proxy: no archive rsc.io v1.5.2: file does not exist
--- FAIL: TestScript (0.01s)
    --- FAIL: TestScript/mod_import (0.79s)
        script_test.go:192: 
            # latest rsc.io/quote should be v1.5.2 not v1.5.3-pre1 (0.648s)
            > go list
            [stdout]
            x
            > go list -m all
            [stdout]
            x
            > stdout 'rsc.io/quote v1.5.2'
            FAIL: testdata/script/mod_import.txt:6: no match for `(?m)rsc.io/quote v1.5.2` found in stdout
            
FAIL
FAIL	cmd/go	251.813s
```

I'm not sure what to make of this, but the `file does not exist` error suggest perhaps filesystem flakiness.
(There is precedent for the filesystem being flaky in #33041.)

CC @jayconrod
Repository: pytorch
Issue: torch.mean(x, dims=[]) has incorrect gradient in 1.2
Labels: high priority,module: autograd,triaged,quansight-nack,module: reductions

## 🐛 Bug

```
import torch
torch.__version__
x = torch.ones(3, requires_grad=True)
out = x.mean([])  # gives 1, as expected
out.backward()
x.grad  # gives tensor([1., 1., 1.]) which is incorrect!
```
`torch.mean(x, [])` should be equivalent to `torch.mean(x)` unless I am missing something. Compare the above code to the following code:
```
y = torch.ones(3, requires_grad=True)
out = y.mean()
out.backward()
y.grad  # gives tensor([0.333, 0.333, 0.333]) as expected
```

This is on PyTorch 1.2. One can't actually run this code on PyTorch 1.3 (it says the gradient is not implemented).

cc @ezyang @gchanan @zou3519 @jerryzh168 @SsnL @albanD @gqchen
Repository: flutter
Issue: Support FragmentActivity for plugins
Labels: platform-android,engine,P3,a: plugins,team-android,triaged-android

This is a documentation ticket that explains why `FragmentActivity` is not currently supported for plugin access. Other tickets that reference this limitation can link to this one, and developers can thumbs up this issue if they run into use-cases that are significantly hampered by the lack of `FragmentActivity` support.

**Why not make `FlutterActivity` a `FragmentActivity` in all cases?**

Flutter's use of `FragmentActivity` requires the inclusion of the Fragment support library. The Fragment support library adds a 100k binary size increase (when optimized). Most full-Flutter apps do not require any use of Fragments, making that 100k binary size increase unnecessary. Therefore, a standard Flutter project uses `FlutterActivity`, which extends a regular `Activity`.

A `FlutterFragmentActivity` is made available within the Android embedding for those projects that require a `FragmentActivity`. However, the `ActivityAware` plugin API only exposes a regular `Activity` via `getActivity()`. This is because the only thing the embedding knows for sure is that an `Activity` is available, but not necessarily a `FragmentActivity`.

Some plugins really do require a `FragmentActivity`. The current solution for those plugins is to attempt to cast the `Activity` to a `FragmentActivity`. It then becomes the responsibility of the app developer to manually switch from `FlutterActivity` to `FlutterFragmentActivity`.

This ticket exists to collect issues and concerns about this approach. If a strong enough argument is made to add some kind of support for `FragmentActivity` exposure in the plugin APIs then the ecosystem team and the embedding team should work together to design the appropriate solution.
Repository: go
Issue: x/build/maintner/maintnerd: Gerrit events are slow to pick up
Labels: Builders,NeedsInvestigation

I've noticed a huge delay lately starting TryBots.

Something's stuck or being slow in the pubsubhelper and/or maintner Gerrit code.
Repository: TypeScript
Issue: Provide metadata about TypeScript's available refactorings and quick fixes
Labels: Suggestion,Committed,Rescheduled

## Problem
We are working on improving discoverability of JS/TS refactorings and quick fixes in VS Code. As part of this, we'd like to put together documentation and a new [contribution points](https://code.visualstudio.com/api/references/contribution-points) that lists out the code actions provided by TypeScript

At the moment, the only way I know to determine this list is to look through the TypeScript codebase. 

## Proposal
We'd like a way to get metadata about all the current TS quick fixes and code actions. The main information we are interested in:

- Identifier for the quick fix
- Human readable name / description for the quick fix
- (possibly) A way to map this description to the localized description that TS ships with

Two ideas on how this could be exposed:

- In the TS repo, check in a generated `CodeActions.json` file. This file would be updated whenever the refactorings or quick fixes change. VS Code would not need this to be published as part of the TypeScript package

- Expose a command line option or tool to dump out all known refactorings and quick fixes.


/cc @orta Ryan mentioned you may also find this useful for the website
Repository: pytorch
Issue: torch.stack does not yet support named tensors 
Labels: feature,triaged,module: named tensor

## 🚀 Feature
tensor.stack outputs named tensors.

## Motivation

Stack is one of those times when you are mushing together a bunch of tensors and getting the end result to match what you intended can be surprisingly tedious and finicky. Named tensors is a beautiful idea that provides names for each dimension.

## Pitch

The input tensors should be named and the names should match in all the dimensions.
e..g.
```
test1 = torch.from_numpy(np.array([[4,1,5,3],[0,6,-1,3.]])).refine_names('H', 'W')
test2 = torch.from_numpy(np.array([[1,1,2,2],[1,1,3,8.]])).refine_names('H', 'W')
newstack = torch.stack((test1,test2), dim=0,  names=('B', 'H', 'W'))
```
'B' is the new dimension you are stacking, other dimensions should match by name.
 
## Alternatives

The alternative is the current implementation where you get a clear error.
`RuntimeError: stack is not yet supported with named tensors. Please drop names via `tensor = tensor.rename(None)`, call the op with an unnamed tensor, and set names on the result of the operation.`

## Additional context

Write up about named tensors. [Named Tensors for Deep Learning](http://nlp.seas.harvard.edu/NamedTensor2)

cc @zou3519
Repository: TypeScript
Issue: Missing JSDoc description when using arrow functions in --allowJs + --declaration
Labels: Bug,Domain: Comment Emit

I was trying to use `--allowJs --declaration` in a javascript only project and noticed that the JSDoc descriptions for arrow functions aren't properly attaching to the type defs.

**TypeScript Version:**  3.8.0-dev.20191031

**Search Terms:** arrow function, allowJs, declaration

**Code**

https://github.com/hipstersmoothie/typescript-jsdoc-bug

```js
/**
 * This isn't included
 *
 * @param bar a test param
 */
export const foo = bar => {};

/**
 * This is included
 *
 * @param baz a test param
 */
export function fob(baz) {}
```

**Expected behavior: (At least something like)**

```ts
/**
 * This isn't included
 *
 * @param bar a test param
 */
export function foo(bar: any): void;
/**
 * This is included
 *
 * @param baz a test param
 */
export function fob(baz: any): void;
```

**Actual behavior:**

```ts
/**
 * This is included
 *
 * @param baz a test param
 */
export function fob(baz: any): void;
export function foo(bar: any): void;
```

If I switch the file to `.ts` the output is expected

```ts
/**
 * This isn't included
 *
 * @param bar a test param
 */
export declare const foo: (bar: string) => void;
/**
 * This is included
 *
 * @param baz a test param
 */
export declare function fob(baz: string): void;
```
Repository: tensorflow
Issue: Porting gradients to C++ from python
Labels: stat:contribution welcome,stat:community support,type:feature,stale,comp:runtime

**System information**
- TensorFlow version (you are using): v2
- Are you willing to contribute it (Yes/No): Yes

**Describe the feature and the current behavior/state.**
I'm writing a Java gradient optimizer to allow training models on the JVM. I've got pretty much everything working, but some of the gradients can't be calculated as they aren't available in C++, and so I get errors of the form `Exception in thread "main" org.tensorflow.TensorFlowException: No gradient defined for op: SparseSoftmaxCrossEntropyWithLogits.`. What's the roadmap for porting gradients from Python to C++? If there isn't a roadmap, would a pull request to add this gradient be accepted (and is there any relevant guidance for working in the TF C++ codebase)? The relevant issues according to GitHub are all from 2016/7 and the internals might be quite different after the v2 release.

**Will this change the current api? How?**
It will expand the set of models that can be trained using languages other than python. It should only add API endpoints and won't change any of the existing ones.

**Who will benefit with this feature?**
Users of the the TF Java API, users of the C API, and other languages which bind the C API. Without the ability to train models using a specific language binding it's very hard to say Tensorflow actually supports that language.
Repository: go
Issue: x/build/maintner/maintnerd: don't sync GitHub issues once we get a 410 that they're disabled
Labels: Builders,NeedsFix

Seen in maintnerd logs:

```
2019/11/01 01:47:40 sync github golang/arch: Beginning sync.
2019/11/01 01:47:40 sync github golang/arch: 2 missing github issues.
2019/11/01 01:47:40 sync github golang/arch: After page 1: 2 issues, 0 changes, 2 issues in memory
2019/11/01 01:47:40 sync github golang/arch: remaining issues: [1 2]
2019/11/01 01:47:40 sync github golang/arch: getting issue 1 ...
2019/11/01 01:47:40 sync github golang/arch: sync = GET https://api.github.com/repos/golang/arch/issues/1: 410 Issues are disabled for this repo []; sleeping
2019/11/01 01:47:56 sync github golang/debug: Beginning sync.                                                                                                                                   2019/11/01 01:47:57 sync github golang/debug: 1 missing github issues.
2019/11/01 01:47:57 sync github golang/debug: After page 1: 2 issues, 0 changes, 2 issues in memory
2019/11/01 01:47:57 sync github golang/debug: remaining issues: [1]
2019/11/01 01:47:57 sync github golang/debug: getting issue 1 ...
2019/11/01 01:47:57 sync github golang/debug: sync = GET https://api.github.com/repos/golang/debug/issues/1: 410 Issues are disabled for this repo []; sleeping
2019/11/01 01:48:10 sync github golang/review: Beginning sync.
2019/11/01 01:48:10 sync github golang/review: 9 missing github issues.
2019/11/01 01:48:10 sync github golang/review: After page 1: 3 issues, 0 changes, 3 issues in memory
2019/11/01 01:48:10 sync github golang/review: remaining issues: [2 3 4 5 6 7 8 9 10]
2019/11/01 01:48:10 sync github golang/review: getting issue 2 ...
2019/11/01 01:48:10 sync github golang/review: sync = GET https://api.github.com/repos/golang/review/issues/2: 410 Issues are disabled for this repo []; sleeping
```

Once we see that they're disabled, we should stop polling.
Repository: PowerToys
Issue: [FancyZones] distinguish between "drop" and "resize to" zone
Labels: Idea-Enhancement,FancyZones-Dragging&UI,Product-FancyZones

I suggest that to make FancyZones really useful it should distinguish between the zone that you drag a window to, what we might call a "Drop Zone", and the zone that window will be resized to, represented by a "Resize to" zone.

For example, you could drag a window to some small zone on monitor 1 and have that window resize to cover all of monitor 1 and monitor 2.

This is indeed the way [GridMove](https://www.dcmembers.com/jgpaiva/) works. (Edit: The current problem with GridMove: setting up these zones is cumbersome; and currently there are unintended gutters).
Repository: youtube-dl
Issue: Option to daemonize youtube-dl
Labels: request

- [x] I'm reporting a feature request
- [x] I've verified that I'm running youtube-dl version **2019.10.29**
- [x] I've searched the bugtracker for similar feature requests including closed ones

## Description

There has been one mention of adding an option to daemonize youtube-dl in the past - however I am interested in this option because:

- I use newsbeuter as a text-based RSS aggregator and start watching a desired YT video by pressing "O" (capital o - not zero) as a keyboard hot-key to create the new tab in Chrome - as long as I have an existing Chrome window open, the playing of the video starts almost immediately . . 
- However, I nearly always get advertisments to click through before the desired video starts playing.

BUT when I config mpv to be the newsbeuter "browser":

- There are a number of seconds delay before mpv starts playing the video

When I raised the issue on the mpv IRC (thinking it was an mpv problem), a helpful person pointed out that the delay is the time it takes to load youtube-dl and that daemonizing that program might solve my problem.

So, is adding code to youtube-dl to allow it to daemonize a possibility?

Thanks,
Phil.
Repository: neovim
Issue: Extra blank line when using confirm()
Labels: enhancement

<!-- Before reporting: search existing issues and check the FAQ. -->

- `nvim --version`: v0.5.0-68-gfe9d54f41
- `vim -u DEFAULTS` (version: ) behaves differently?
- Operating system/version: macos
- Terminal name/version: kitty
- `$TERM`:

### Steps to reproduce using `nvim -u NORC`

1. nvim -u NONE
2. ~:map <silent><c-k> :call confirm('hello', "&Yes\n&No", 0)<cr>~
2. `:map <silent><c-k> :call confirm('hello', "&Yes\n&No", 0)<cr>`
3. send `<C-L>`
4. send `<c-k>`, show as follow:
![image](https://user-images.githubusercontent.com/19503791/68009377-c921d680-fcbc-11e9-918b-a831d23aa8f4.png)

### Actual behaviour

### Expected behaviour
remove the Extra blank line
Repository: pytorch
Issue: Named Tensors: size of a named dimension
Labels: module: docs,triaged,module: named tensor

how do we get the size of a particular named dimension ? Today, I get it as shown below, but it seems round about. Is there a better way to doing the same ?

```
>>> t = torch.zeros((3, 224, 400), names=('C', 'H', 'W'))
>>> 
>>> t.shape[t.names.index('H')]
224


cc @zou3519
Repository: pytorch
Issue: Named Tensors: Slicing based on name
Labels: triaged,module: advanced indexing,module: named tensor

How do we slice tensors based on their names ? Are there named equivalents for 

- t[0,:,:] = blabla

- x= t.narrow(0, 0, 1)

cc @zou3519
Repository: pytorch
Issue: RuntimeError: !t.is_cuda() INTERNAL ASSERT FAILED at /pytorch/aten/src/ATen/native/sparse/SparseTensorMath.cpp:591
Labels: module: sparse,triaged,module: assert failure

## 🐛 Bug

RuntimeError: !t.is_cuda() INTERNAL ASSERT FAILED at /pytorch/aten/src/ATen/native/sparse/SparseTensorMath.cpp:591

## To Reproduce
File "/home/jinzhu/pro/UIL/GraphMatch/layers.py", line 42, in forward
    output = torch.spmm(adj, support) 
RuntimeError: !t.is_cuda() INTERNAL ASSERT FAILED at /pytorch/aten/src/ATen/native/sparse/SparseTensorMath.cpp:591, please report a bug to PyTorch. 




cc @vincentqb
Repository: TypeScript
Issue: Provide a code action to replace a string with a template string
Labels: Suggestion,Experience Enhancement

## Suggestion

Provide a code action on a string to replace the string with a template string.

## Use Cases

Often you start with a normal string and notice that it should better be a template string. See the example below. When the cursor is inside the string, there should be code action provided 'Replace with template string'

<img width="300" alt="image" src="https://user-images.githubusercontent.com/172399/68016015-db3b4f00-fc93-11e9-88aa-b5677dc813fb.png">

The code action replace the string with a template string
<img width="300" alt="image" src="https://user-images.githubusercontent.com/172399/68016231-661c4980-fc94-11e9-9193-ca9737abe81c.png">


## 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).