sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: [jit] Traced `cat` on GPU doesn't support negative indexing
Labels: oncall: jit,triaged

```python
import torch.nn as nn
import torch

class MyNet(nn.Module):
    def __init__(self):
        super().__init__()
        self.param = nn.Linear(3, 5)
    
    def forward(self, x):
        # change dim=-1 to dim=0 or dim=1 works
        return torch.cat((self.param(x), self.param(x)), dim=-1)
        
    def input_prototype(self):
        return torch.tensor([[1.0, 2.0, 3.0]])

# work on cpu
a = MyNet()
input_prototype = a.input_prototype()
print(a(input_prototype))
b = torch.jit.trace(
    a, input_prototype
)
print(b(input_prototype))


# not working on gpu
a = MyNet().cuda()
input_prototype = a.input_prototype().cuda()
print(a(input_prototype))
b = torch.jit.trace(
    a, input_prototype
)
print(b(input_prototype))
```

throws

```
TracingCheckError: Tracing failed sanity checks!
Encountered an exception while running the trace with test inputs.
Exception:
	vector::_M_range_check: __n (which is 18446744073709551615) >= this->size() (which is 2)
	The above operation failed in interpreter, with the following stack trace:
	
	Exception type: std::runtime_error
```

scripting fixes the issue

cc @suo
Repository: go
Issue: x/mobile: when a panic happens, a long enough traceback deadlocks the runtime on Android
Labels: NeedsInvestigation,mobile

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.13.1 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
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/<hidden>/.cache/go-build"
GOENV="/home/<hidden>/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/opt/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
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-build557544076=/tmp/go-build -gno-record-gcc-switches"

</pre></details>

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->

I have an Go application compiled for Android with gomobile. When a panic happens, the runtime prints a traceback and quits. However, when this traceback is long enough, the application freezes and never quits.

[Gomobile redirects `stderr` to Android](https://github.com/golang/mobile/blob/master/internal/mobileinit/mobileinit_android.go#L74-L82) (Android log tag being "GoLog"). When a panic happens, the world is frozen, so:

- the goroutine `lineLog` does not consume anymore the pipe `dup`-ed to `stderr`;
- at some point the pipe becomes full;
- [the runtime continues to write the long traceback in `stderr`](https://github.com/golang/go/blob/master/src/runtime/write_err_android.go#L49) and blocks until `stderr` is writable;
- deadlock.

Disabling the gomobile's redirection from `stderr` makes the application crashes "properly".

Note that [the runtime already redirect logs to Android](https://github.com/golang/go/blob/master/src/runtime/write_err_android.go#L51-L83) (with the tag "Go"), so the redirection of `stderr` by gomobile seems redundant to me?

To reproduce, you can modify the runtime to `println` lot of lines when a panic is caught, until the runtime freezes.

### What did you expect to see?

When a panic happens, and the resulting traceback is long enough, I expect the runtime to print the full traceback and quit.

### What did you see instead?

When a panic happens, and the resulting traceback is long enough, I see the runtime prints a truncated traceback and freezes.
Repository: vue
Issue: Allow accessing events registered via `vm.$on(...)` via a property, similar to `$listeners`
Labels: discussion

### What problem does this feature solve?

Currently, if an event is registered via `vm.$on('event-name', handler)`, it does not appear in the `this.$listeners` object (Vue 2.6.x)

In some instances you only want to handle the event processing if there is indeed a listener registered (for performance reasons).  But when component event listeners are registered programatically via `this.$on` (or `vmReference.$on`) it is not currently possible to see them in `this.$listeners`, e.g.:

```js
if (this.$listeners['event-name']) {
  // Do something computationally intensive
  // then emit event
  this.$emit('event-name', resultOfComputation)
}
```

![image](https://user-images.githubusercontent.com/2781561/68885711-1013c100-06ec-11ea-8c4b-a447d3612629.png)

### What does the proposed API look like?

No new API for the public.

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: storybook
Issue: React - Browser error: fn.apply is not a function
Labels: question / support,react

**Describe the bug**
Most of my components produce the following error in the browser.
`TypeError: fn.apply is not a function
`

**To Reproduce**
Steps to reproduce the behavior:
1. `npm run storybook`
2. Error shows up in browser

**Expected behavior**
No error, show my component

**Screenshots**
<img width="1202" alt="Screen Shot 2019-11-14 at 11 05 09 AM" src="https://user-images.githubusercontent.com/12503822/68887875-a0dba400-06ce-11ea-90be-3909b3c93b33.png">

**System:**
```
Environment Info:

  System:
    OS: macOS 10.15.1
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
  Binaries:
    Node: 10.15.3 - ~/.nvm/versions/node/v10.15.3/bin/node
    Yarn: 1.19.0 - /usr/local/bin/yarn
    npm: 6.4.1 - ~/.nvm/versions/node/v10.15.3/bin/npm
  Browsers:
    Chrome: 78.0.3904.97
    Safari: 13.0.3
  npmPackages:
    @storybook/react: ^5.2.6 => 5.2.6 
```
Repository: rust
Issue: Fix `trait_ref_to_existential` as trait aliases is stabilized
Labels: T-compiler,C-bug,F-trait_alias,requires-nightly,T-types,A-trait-objects,A-dyn-compatibility

https://github.com/rust-lang/rust/pull/66392#discussion_r346112428

There appears to be a missing filter on top of `expand_trait_aliases`, which picks up non-supertraits where clauses - but also, the object safety completely ignores trait aliases, which could be object safety hazards. We now use `delay_span_bug` there to avoid an ICE in stable even when the feature is disabled.
Repository: godot
Issue: Loading FPS Demo cause of using nan values
Labels: bug,topic:core

**Godot version:**
3.2.beta.custom_build.7d836a7cc
**OS/device including version:**
Ubuntu 19.10
**Issue description:**
Loading FPS tutorial, cause that Godot use in Image::set_pixel, p_color variable with NaN values inside it
![Zrzut ekranu z 2019-11-14 21-23-33](https://user-images.githubusercontent.com/41945903/68893260-12464180-0725-11ea-9d8b-c0b9179df2d8.png)


![Zrzut ekranu z 2019-11-14 21-21-05](https://user-images.githubusercontent.com/41945903/68893137-ca271f00-0724-11ea-82c7-ec3db920105b.png)

**Steps to reproduce:**
1. Just run minimal project with breakpoints like from above

**Minimal reproduction project:**
https://github.com/TwistedTwigleg/Godot_FPS_Tutorial
Repository: TypeScript
Issue: Type narrowing for optional chaining in OR expression in AND expression
Labels: Bug

**TypeScript Nightly** version 3.8.0-dev.20191113
[Playground link](http://www.typescriptlang.org/play/index.html?ts=3.8.0-dev.20191113&ssl=1&ssc=1&pln=1&pc=79#)

Compiler Options:
```json
{
  "compilerOptions": {
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "useDefineForClassFields": false,
    "alwaysStrict": true,
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,
    "downlevelIteration": false,
    "noEmitHelpers": false,
    "noLib": false,
    "noStrictGenericChecks": false,
    "noUnusedLocals": false,
    "noUnusedParameters": false,
    "esModuleInterop": true,
    "preserveConstEnums": false,
    "removeComments": false,
    "skipLibCheck": false,
    "checkJs": false,
    "allowJs": false,
    "experimentalDecorators": false,
    "emitDecoratorMetadata": false,
    "target": "ES2017",
    "module": "ESNext"
  }
}
```

**Input:**
```typescript
const f = (a: { b: boolean, c: number } | undefined) => (a?.b || null) && a.c;
```

**Output:**
Compiler error: `Object is possibly 'undefined'.(2532)`

**Expected behavior:**
Successful compilation

**Note:**
```typescript
const f = (a: { b: boolean, c: number } | undefined) => (a?.b || false) && a.c;
```
(using `false` instead of `null`) works as expected.

**Related issues:**
https://github.com/microsoft/TypeScript/issues/34570
https://github.com/microsoft/TypeScript/issues/33806
Repository: pytorch
Issue: Fold DispatchStub into c10 dispatcher
Labels: triaged,module: dispatch

Right now we have two levels of dynamic dispatch: c10 dispatcher does a first level of dispatch, and then DispatchStub does a second level of dispatch. For CUDA/HIP dispatch, DispatchStub's extra dispatch is completely unnecessary. However, for CPU dispatch, DispatchStub supports dispatching to AVX/AVX2/default CPU kernels at runtime depending on what instruction set is supported by the processor. We should adjust c10 dispatcher to support this use-case; combined with an extra dispatch step for backend common code (the other reason why people commonly use DispatchStub), so we can eliminate DispatchStub entirely.

We will achieve this by adding a priority and conditional registration to the dispatch registration API.

**Kernel priorities.** Every kernel will be associated with a priority, described as a closed enum type:

```
enum class DispatchPriority {
  Default,
  AVX,
  AVX2,
  // Enum supports other priorities, e.g.,
  // PrivateUse_HighestPriority,
};
```

`DispatchPriority::Default` is used if none is specified. If a kernel registration occurs where another kernel already exists, we compare priorities and only take the kernel with highest priority.

The intended use of this mechanism is to associate kernels with higher vectorization layers with higher priority, so we prefer to use them.

**Conditional registration.** Conditional registration is simple: instead of unconditionally registering a kernel, we test a condition in our static initializer. If the condition is false, we don't register the kernel (we still may register the schema it corresponds to).

The intended use of this mechanism is to avoid registering kernels for CPU capabilities which we don't actually have.
Repository: rust
Issue: #[must_use] does not yield warning in pattern match
Labels: A-lints,T-lang,C-feature-request

The following code does not warn that `_f` in `use_foos` is marked as `#[must_use]`:

```rust
#[must_use]
pub struct Foo;
pub enum Foos {
    F(Foo)
}

pub fn use_foos(f: Foos) {
    match f {
        Foos::F(_f) => {}
    }
}
```

If we change `_f` to `f`, we get a warning that `f` is unused, but still no `#[must_use]` warning.

Adding `#[must_use]` to the enum and variant does not make produce the warning either:

```rust
#[must_use]
pub struct Foo;

#[must_use]
pub enum Foos {
    F(#[must_use] Foo)
}

pub fn use_foos(f: Foos) {
    match f {
        Foos::F(_f) => {}
    }
}
```
Repository: terminal
Issue: Open a new pane by prompting the user for which profile to use
Labels: Help Wanted,Area-UserInterface,Area-Settings,Product-Terminal,Issue-Task

Bear with me for a second. Somebody suggested this in another issue, and I wonder if we should consider it here.

![image](https://user-images.githubusercontent.com/14316954/60481298-9fd73800-9c41-11e9-92a5-61b8f7e61ecf.png)

The new pane is focused, and put in a [number entry] or [search for profiles by name] mode, just like one of our earlier issues suggested.

We probably want that UI _anyway_, since it has some benefits. Thoughts?

_Originally posted by @DHowett-MSFT in https://github.com/microsoft/terminal/issues/1756#issuecomment-507507450_

<hr>

See also #998, #1756, #1000
Repository: TypeScript
Issue: Consider some way of serializing open projects in tsserver, potentially leveraging `.tsbuildinfo` files
Labels: Suggestion,Needs Proposal,In Discussion,Domain: TSServer,Domain: Performance,Experimentation Needed,Domain: --incremental

One thing that users often hit is that file navigation might trigger opening an entire project. Opening an entire project involves

1. File loading
1. Scanning/parsing
1. Resolving dependencies
1. Keep repeating file loading on dependencies until no new files are found

This is a lot of work! If a user jumps back and forth from this file, it can re-trigger this work even if nothing has changed!

A `.tsbuildinfo` file is used to save time on cold compiler invocations doing this exact set of work, and to reduce work when something actually has changed. It would be interesting to see whether generating a `.tsbuildinfo` file after project loads could help cut down on this work.
Repository: TypeScript
Issue: Grace period strategy for unloading projects
Labels: Domain: Performance

Today, navigating to a file in another project might involve a full project load. Bad! Users often navigate back to the original project, and then dive right back into the loaded project. Unfortunately, by the time that they do that, that project is unloaded and all the work has to be done **all over again**.

We might want to consider something like a "grace period" for unloading projects when the last open file of a project is closed.
Repository: electron
Issue: [Bug]: will-navigate doesn't fire when navigating to about: URLs
Labels: platform/windows,bug :beetle:,5-0-x,7-1-x,10-x-y,has-repro-gist,20-x-y,22-x-y

### Preflight Checklist
<!-- Please ensure you've completed the following steps by replacing [ ] with [x]-->

* [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
* [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
* [x] I have searched the issue tracker for an issue that matches the one I want to file, without success.

### Issue Details

* **Electron Version:** 5.0.7
* **Operating System:** Windows 10

### Expected Behavior
Based on the documentation, I expect that navigating to `"about:blank"` will trigger the webcontent's `will-navigate` event.

### Actual Behavior
`will-navigate` does not get triggered.

The [docs](https://electronjs.org/docs/api/web-contents#event-will-navigate) make no mention of `"about:blank"` being an exception, and so I expect that `will-navigate` should get emitted when navigating to it.

Either this is a documentation error, or it's a bug with `will-navigate`.

### To Reproduce
```
const { app, BrowserWindow, BrowserView } = require('electron')

async function onReady() {
	const mainWindow = new BrowserWindow();
	const view = new BrowserView();
	view.webContents.addListener("will-navigate", (e, url) => {
		console.log("navigating to: " + url);
	});
	mainWindow.setBrowserView(view);
	await view.webContents.loadURL("https://google.com");
	view.webContents.openDevTools();
}

app.on('ready', onReady)
```

After `npm start`ing, in the devtools, run `location = "https://google.com"`. Notice that we log it.

Then run `location = "about:blank"`. Notice, that there's no log.
Repository: pytorch
Issue: torch.save/load shows raw path on the pickle_module arg
Labels: module: docs,module: serialization,triaged

The doc now looks like below. I would assume the path was not intended to be there?

<img width="877" alt="Screen Shot 2019-11-14 at 4 12 15 PM" src="https://user-images.githubusercontent.com/16999635/68906684-fb3e2a00-06f9-11ea-812a-90e66aecc787.png">
Repository: pytorch
Issue:  n-dimensional non-constant padding functional
Labels: module: nn,triaged,enhancement,module: padding

## 🚀 Feature

It'd be nice to have n-dimensional non-constant padding functional available.

```
import torch
n = 2
a = torch.randn(4, 3)
torch.nn.functional.pad(a, (n,n), mode='replicate')

# NotImplementedError: Only 3D, 4D, 5D padding with non-constant padding are supported for now
```

## Motivation

Non-constant would simplify `compute_deltas` in pytorch/audio#337.

## Additional context

n-dimensional constant padding was introduced in #2657.


cc @albanD @mruberry @jbschlosser
Repository: TypeScript
Issue: Investigate making the binding phase lazy
Labels: Domain: Performance

Today, any semantic or language service operations **must** be preceded by a phase of our compiler called binding. This phase does two things:

* creates symbol tables as well as symbols per scope
* sets parent pointers (because it's already walking the tree anyhow)

However, this can end up being a of unnecessary up-front work. For type-checking a given file, the only files that need to be bound are

* files that affect global namespaces (e.g. global files or files containing module augmentations, global augmentations, and UMD namespaces)
* any file that needs to be checked to check the current file

Recently, I spent a bit of time on a plane ride wondering if we could do less work based on this. Instead of forcing all files to be bound, we could bind only global-affecting files up-front, and then force a bind prior to checking or resolving a given file. This has the advantage that something like quick info only needs to bind the minimal set of dependencies before coming back with an answer, making checking significantly lazier. It also means that `skipLibCheck` could end up working faster in command-line scenarios by binding fewer `.d.ts` files that are automatically included (e.g. why bind `.d.ts` files for Jest if you're compiling app code instead of test code?).

The flip side of this is that making this lazy can complicate a lot of other operations. Many language service operations don't actually care about binding, but they do care about parent pointers being set. They'll be preceded by a call to `getTypeChecker()` just to ensure files are bound before performing specific steps.

> Yeah, I know, weird design!

The other issue is that certain type-checker APIs likely need to be guarded against to ensure a requested file is bound. I haven't dived deep here, so this is more of a speculative concern.

Finally, while laziness means that we can partially amortize each operation into incremental chunks of work, there's no telling when pulling on a thread of work will trigger TypeScript to do ALL of the work. Currently TypeScript does ALL the work up front, but that might be good for avoiding frustrating delays later on. For example, if not all files are bound yet, TypeScript can't immediately respond to *go to symbol*, *find all references*, or even some cases of *get completions* (thanks to auto-imports!) before ensuring every file is bound.

On the other hand, once that work gets done, it's done! Only re-parsed files need to be re-bound. So TypeScript might start out slow on some operations, warming up, and eventually staying hot going forward. There are also other possibilities of making this easier. For example, the services layer could also potentially bind unbound files in the background on idle time if it turned out we really needed to.
Repository: TypeScript
Issue: Investigate implicit excludes
Labels: Domain: Performance

Today, TypeScript will implicitly set `exclude` to `./node_modules` and something like `.*/**/*` to avoid dot files.

Unfortunately, there are two problems I believe I've found from chatting with users.

First, users often end up setting `exclude` which overrides the defaults. This often means that users accidentally over-include files, and that can cause performance issues.

Next, these defaults don't work out well enough, and end up going a bit off the rails in certain scenarios. For example, consider the following `.js` monorepo.

```
packages
+- package-aaa
|  +- node_modules    <- the cute tiny 10MB node_modules
|
+- jsconfig.json
+- node_modules        <- the slightly bigger 10GB node_modules
                         shared by each package
```

Notice that `jsconfig.json` or not, one of these `node_modules` is going to be crawled through unless `exclude` is set appropriately. And regardless of whether `exclude` is implicitly or explicitly on, it's usually wrong. In this case, it should (probably) be `**/node_modules/**/*`. For example, check out https://github.com/IBM/report-toolkit/pull/44/files

What I'm suggesting is to harden `exclude` to **always** contain the following paths regardless of whether `exclude` is set.

* `**/node_modules/**/*`
* `.*/**`

To disable this, users will have to turn off a setting like `enableImplicitExcludePatterns`.
Repository: ant-design
Issue: the prev and next button not work as expected when carousel stay in another carousel in some case
Labels: Inactive,🚌 External Dependency

- [x] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### Reproduction link
[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/s/wizardly-hawking-cp0e3)

### Steps to reproduce
## one
1. open the link https://codesandbox.io/s/wizardly-hawking-cp0e3
2. click next button once at the top carousel 
3. click next or prev button at first child carousel

## another:
1. open the link https://codesandbox.io/s/wizardly-hawking-cp0e3
2. click prev button once at the top carousel
3. click next or prev button at second child carousel

### What is expected?
when click prev or next button of child carousel, it should slide

### What is actually happening?
not slide, nothing happen

| Environment | Info |
|---|---|
| antd | 3.25.1 |
| React | 16.7.0 |
| System | macOS Catalina 10.15.1 |
| Browser | 78.0.3904.87 (64) |


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: pytorch
Issue: Get wrong precision when multi nodes run in docker
Labels: needs reproduction,oncall: distributed,triaged

I can finetune a pretrained model using two nodes outside docker by several steps to get better precision. But when I do the same thing in the docker( without any error messages) by several steps in the same machine, the test precision is always 0. Does anyone know why?
Pytorch version is 1.2.0, nccl version is 2.4.8 for inside or outside docker container.

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @xush6528