sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Breadcrumb missing on read-only documents supplied by debug adapter
Labels: feature-request,breadcrumbs

Issue Type: <b>Bug</b>

VS Code version: Code 1.28.2 (7f3ce96ff4729c91352ae6def877e59c561f4850, 2018-10-17T00:23:51.859Z)
OS version: Windows_NT x64 10.0.15063

1. Start debugging something. In my case I am debugging a debug extension written in Typescript, e.g. the mock-debug sample.
2. Use the Pause button to suspend execution at a point where the debug adapter will supply the (read-only) source for display. In my case it was easy to suspend in async_hooks.js.
3. Observe that there's no breadcrumb on the loaded document. Toggling breadcrumb on the View menu has no effect.
4. Set a breakpoint in a source that exists on the local filesystem. Run to that breakpoint and confirm that a breadcrumb appears as expected. Toggling breadcrumb on the View menu works as expected.

Also occurs on current 1.29 Insider. I don't recall if the same problem existed in other breadcrumb-enabled versions (i.e. 1.26+).
Repository: svelte
Issue: Chrome video autoplay bug when hydrating server-rendered component
Labels: feature request,stale-bot,temp-stale

If a component contains an autoplaying video, like this:

```html
<video autoplay loop muted>
    <source src="https://example.com/video.mp4" type="video/mp4">
</video>
```

and that component is server-rendered and then hydrated in Chrome, the video starts playing for around 500ms until hydration kicks in, then the video pauses.

This only happens with server-rendered components that are hydrated in the browser. Disabling Javascript or server-rendering fixes the issue.

If I add the line

```js
video.play();
```

to the end of the hydration function that the Svelte compiler emits for the component, I sometimes (though not always, which seems to imply that whatever is pausing the video is being called asynchronously) get the error [1]:

```
Uncaught (in promise) DOMException: The play() request was interrupted by a call to pause().
```

and the video remains paused in all cases. If, however, I add a simple timeout to that line:

```js
setTimeout(() => {
  video.play();
}, 0);
```

the video plays, which seems to rule out the hydration function as the culprit.

This bug only shows up in Chrome (tested in version 70.0.3538.77). Safari and Firefox don't seem to be affected.

I've set up a Sapper project that demonstrates this [here](https://github.com/nsivertsen/svelte-video-autoplay-bug) and a Glitch project with a live demo [here](https://nsivertsen-svelte-video-autoplay-bug.glitch.me/). I've added the video to the "Home" and "About" pages. Whichever one you load first should show a paused video, and when you navigate to the other page it should play.

---

1. More info on the Google Developers site: [DOMException: The play() request was interrupted](https://developers.google.com/web/updates/2017/06/play-request-was-interrupted)
Repository: TypeScript
Issue: Infer-from-usage should find references of related tokens
Labels: Suggestion,Domain: Quick Fixes,Experience Enhancement,feature-request

Based on code in acorn:

```js
var TokenType = function TokenType(label, conf) {
  this.label = label
  this.binop = conf.binop || null
}

/**
 * @param {string} name
 * @param {number} prec
 */
function x(name, prec) {
  return new TokenType(name, { binop: prec })
}
```

**Expected behavior:**

TokenType's inferred type should be `(label: string, conf: { binop: string })` based on usage in `x`.

**Actual behavior:**
TokenType's inferred type is `(label: any, conf: { binop: null })`, based only on usage inside `TokenType` itself.

I don't think infer-from-usage supports any JS assignment patterns; this is just the first one I ran into.
Repository: go
Issue: cmd/go: align comments in go.mod files
Labels: NeedsDecision,modules

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?
Go 1.11

### Does this issue reproduce with the latest release?
yes



### What did you do?
go mod init
go mod tidy


### What did you expect to see?
Into go.mod, is it possible to have (like into comment into source code) align of `// indirect`

```
module myModule

require (
	github.com/something v1.0.0
	github.com/foo v1.0.0       // indirect
	github.com/foo/bar v1.0.0   // indirect	
)
```

### What did you see instead?
```
module myModule

require (
	github.com/something v1.0.0
	github.com/foo v1.0.0  // indirect
	github.com/foo/bar v1.0.0 // indirect	
)
```
Repository: pytorch
Issue: batch_norm doesn't bump version counter of running stats
Labels: high priority,module: autograd,module: nn,triaged,actionable,fixathon

This can cause correctness problems if you mix `eval` and `training` modes because `eval` mode backward needs the running stats, and `training` mode forward updates the running stats, even if the `training` mode result is unused. E.g.,

```py
import torch

bn = torch.nn.BatchNorm2d(3).double()
x = torch.randn(2, 3, 1, 1).double().requires_grad_()


def f(x):
  bn.running_mean.data.fill_(0)
  bn.running_var.data.fill_(1)
  bn.eval(); y0 = bn(x)
  bn.train(); unused = bn(x)  # running buffers are changed in-place here
  return y0

torch.autograd.gradcheck(f, (x,))  # fails gradcheck

def g(x):
  bn.running_mean.data.fill_(0)
  bn.running_var.data.fill_(1)
  bn.eval(); y0 = bn(x)
  bn.running_mean = bn.running_mean.clone()
  bn.running_var = bn.running_var.clone()
  bn.train(); unused = bn(x)
  return y0

torch.autograd.gradcheck(g, (x,))  # passes

```

cc @ezyang @gchanan @zou3519 @SsnL @albanD @gqchen @colesbury
Repository: pytorch
Issue: [caffe2] How to use Split operator?
Labels: caffe2

Hi all,

how can I use the Split operator? I want to split a tensor and get the splitted blobs based on a indicated split number for further processing. Something like this:
```
...
relu = brew.relu(m, fc3, fc3)
split1, split2 = m.net.Split(relu, num_splits=2,axis=0)
conv2 = brew.conv(m, split1, 'conv2', .....................)
```

Is it possible?
Repository: TypeScript
Issue: Skip type checking project reference redirect(declaration file from project reference) to improve perf
Labels: Suggestion,In Discussion,Scenario: Monorepos & Cross-Project References,Domain: Performance

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Please read the FAQ first, especially the "Common Feature Requests" section.

-->

## Search Terms

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

## Suggestion

We could probably set internal option and skip type checking project reference redirects (included .d.ts files from project reference output)
This could speed up `tsc --b` mode by skipping type checking generated files, (eg. skip `compiler.d.ts` when building `tsc` project and so on...) Since in build mode referencing projects are not built if there are any errors in the referenced project this should report all errors.
## Use Cases

<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->

## Examples

<!-- Show how this would be used and what the behavior would be -->

## Checklist

My suggestion meets these guidelines:
* [ ] This wouldn't be a breaking change in existing TypeScript / JavaScript code
* [ ] This wouldn't change the runtime behavior of existing JavaScript code
* [ ] This could be implemented without emitting different JS based on the types of the expressions
* [ ] This isn't a runtime feature (e.g. new expression-level syntax)
Repository: rust
Issue: Specific implementations on wrapper types should show up on the page of the inner type
Labels: T-rustdoc,C-enhancement,A-trait-system,A-rustdoc-ui

Currently, with the following code:

```rust
pub struct Rc<T>(T);

pub struct Foo;


impl Rc<Foo> {
    pub fn bar() {}
}
```

the impl appears on the page for `Rc`, even though it's more relevant for `Foo`.

Provide a way to mark a type as a wrapper type, such that an impl where its first generic parameter is a single type (which may itself be generic, e.g. `Rc<Option<T>>`) appears on the page of that type.

It may be worth automatically doing this for `#[fundamental]` types
Repository: react
Issue: Using both getDerivedStateFromError and getDerivedStateFromProps can be a foot gun
Labels: Type: Discussion

<!--
  Note: if the issue is about documentation or the website, please file it at:
  https://github.com/reactjs/reactjs.org/issues/new
-->

**Do you want to request a *feature* or report a *bug*?**

Feature

**What is the current behavior?**

If `componentDidCatch` and/or `getDerivedStateFromError` put the component in a state that avoids the cause of the error, and `getDerivedStateFromProps` reverts that state change, the error boundary will (obviously) fail to avert disaster.

https://codesandbox.io/s/pj0lwxk15j

It sounds very obvious when simplified like this, but when my team updated to React 16.5.x (and 16.6.0), suddenly this started happening for us. So something changed internally, but it's hard to pinpoint what. Unfortunately I haven't been able to create a small repro for that specific case that works in 16.4.2 but not 16.5.0 – so I'm making this issue about avoiding the cause in the first place.

**What is the expected behavior?**

Naively, my thinking is that because errors are more exceptional, let the state from error handlers take precedence. Probably there's a reason why this can't happen so a warning of some kind when this can happen would be nice. Two ways to do this comes to mind:

1. Cross-check that keys in state from `getDerivedStateFromProps` or `setState` in `componentDidCatch` don't collide with `getDerivedStateFromError` (sounds a bit far fetched?)
2. Be more explicit in documentation for error boundaries about how `getDerivedStateFromProps` will run last so that a developer can consider this case

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**

16.5.0 and up (16.4.2 behaves a bit differently – see above), all platforms/browsers.
Repository: TypeScript
Issue: JSDoc doesn't dig through type aliases
Labels: Suggestion,Domain: JSDoc,Domain: Type Display,Experience Enhancement

**TypeScript Version:**  6fd6a04f2eabcbd468b80aac270b34bad24892e4

**Code**

```ts
/** @param containingNode Node to check for parse error */
type AddUnusedDiagnostic = (containingNode: number, type: number, diagnostic: number) => void;
```

**Expected behavior:** `containingNode` in the JSDoc comment binds to the parameter of the function type (e.g. rename, quick info, document highlights, and GTD work).

**Actual behavior:** `containingNode` doesn't bind to anything and the quick info just says it has type `any`.
Repository: TypeScript
Issue: Nested indexing of mapped type fails to resolve correctly
Labels: Bug,Domain: Indexed Access Types

<!-- 🚨 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.2.0-dev.20181031

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

`nested indexing mapped type`

**Code**

```ts
interface Foo {
  a: { x: boolean };
  b: { y: boolean };
}

function extractBoolean<K extends 'a' | 'b'>(foo: Foo, key: K, innerKey: keyof Foo[K]): boolean {
  return foo[key][innerKey];
}
```

**Expected behavior:**

Should compile.

**Actual behavior:**

```
Type 'Foo[K][keyof Foo[K]]' is not assignable to type 'boolean'.
  Type '({ x: boolean; } | { y: boolean; })[keyof Foo[K]]' is not assignable to type 'boolean'.
```

[**Playground Link**](https://www.typescriptlang.org/play/#src=interface%20Foo%20%7B%0D%0A%20%20a%3A%20%7B%20x%3A%20boolean%20%7D%3B%0D%0A%20%20b%3A%20%7B%20y%3A%20boolean%20%7D%3B%0D%0A%7D%0D%0A%0D%0Afunction%20extractBoolean%3CK%20extends%20'a'%20%7C%20'b'%3E(foo%3A%20Foo%2C%20key%3A%20K%2C%20innerKey%3A%20keyof%20Foo%5BK%5D)%3A%20boolean%20%7B%0D%0A%20%20return%20foo%5Bkey%5D%5BinnerKey%5D%3B%0D%0A%7D%0D%0A)

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: vscode
Issue: [css] Add @media and @supports to CSS breadcrumbs
Labels: feature-request,css-less-scss

It would be really useful if the navigation breadcrumbs for css included @media and @supports queries. 

At the moment, if you are working inside a long media query, there's no easy way to tell aside from scrolling up and manually checking for one.

![screen shot 2018-10-31 at 3 04 08 pm](https://user-images.githubusercontent.com/182772/47821648-a57d2680-dd1e-11e8-964e-dc654d5ad625.png)
Repository: TypeScript
Issue: Quick info for array in `a.length` shows `any[]` even when it should have a type
Labels: Bug,Domain: Quick Info

**TypeScript Version:**  3.2.0-dev.20181031

**Code**

```ts
/// <reference path='fourslash.ts'/>

// @strict: true

////function f(b: number) {
////    const /*0*/a = [];
////    if (b) /*1*/a.push(0);
////    /*2*/a.length;
////    /*3*/a.concat;
////}

verify.quickInfos({
    0: "const a: any[]",
    1: "const a: any[]",
    2: "const a: any[]", // Should be number[]
    3: "const a: number[]",
});
```

**Expected behavior:**

Quick info at `a` in `a.length` should show it as a `number[]`.

**Actual behavior:**

Shows `any[]`.
Repository: opencv
Issue: OpenGL code in samples/cpp/detect_mser.cpp
Labels: category: samples,RFC

We should keep samples simple as much as possible.

What is OpenGL part demonstrate in this sample?
Can we port this code into OpenCV code without OpenGL usage?
Should we move original "OpenGL" code into "samples/opengl" sub-directory?
Repository: go
Issue: x/tools/go/packages: failure parsing go.mod silently ignored
Labels: modules,Tools

Followup from #28518. 

We spent a while chasing our tails before realizing that `go list` was failing entirely. I think the error was swallowed because the call fell into the `usesExportData` case of `invokeGo`'s error handling. Can anything better be done?

@ianthehat @matloob
Repository: flutter
Issue: Make BorderStyle extensible
Labels: c: new feature,framework,customer: crowd,P3,team-framework,triaged-framework

It would be interesting to support new kinds of BorderStyle, based on some sort of interface that converts a Path to another Path for later processing.

e.g. to enable a package to implement dashed borders for the Border class and friends.
Repository: rust
Issue: .count() too slow
Labels: A-LLVM,I-slow,T-compiler

I noticed something peculiar in #33038, notably

> So in short, the slowdown is caused by .count() using 64 bit integers. Which is strange, because the length of the vector is known be less than 2^32 - is there any way to optimize Vec or count() to use something smaller than usize?

In my understanding, `.count()` using `usize` directly contradicts

> So how do you know which type of integer to use? If you’re unsure, Rust’s defaults are generally good choices, and integer types default to i32: this type is generally the fastest, even on 64-bit systems. The primary situation in which you’d use isize or usize is when indexing some sort of collection.

from https://doc.rust-lang.org/book/second-edition/ch03-02-data-types.html

`.count()` is certainly never realistically being used for indexing, so according to the above paragraph it should default to `i32` on 64bit systems (This is referring to automatic typing of integer literals, but as an idea it remains valid). If this was already thoroughly discussed, I apologize. If not, I think it needs a second look. I think that in the majority of use cases, the users of Rust would much prefer `.count()` be three times faster, as opposed to being able to surpass 4 Billion.
Repository: TypeScript
Issue: Compiler API to resolve path from ImportDeclaration
Labels: Suggestion,In Discussion,API

Hi there, since TS supports `paths` in `tsconfig.json`, is there an API in the compiler (`Program`, `CompilerHost` or something) to programmatically resolve real path of an import?

I wrote this transformer https://github.com/longlho/ts-transform-css-modules and it's tripping up on paths that are aliased in `tsconfig.json`, e.g:

```
import * as css from 'alias/foo.css'
```

tsconfig.json
```
{
  "compilerOptions": {
    "paths": {
      "alias/*": "../../../some_location/*"
    }
  }
}
```

I can try to manually reconstruct TS resolver but rather not to.

Thanks!
Repository: react
Issue: Unexpected copies of the props object retained in memory with the new hooks API
Labels: Type: Needs Investigation,Component: Reconciler

<!--
  Note: if the issue is about documentation or the website, please file it at:
  https://github.com/reactjs/reactjs.org/issues/new
-->

**Do you want to request a *feature* or report a *bug*?**

bug

**What is the current behavior?**

```jsx
function useCustomHook1() {
  useEffect(() => {
    console.log("mounted");
    return () => {
      console.log("unmounted");
    };
  }, []);
}

function Test3(props) {
  useCustomHook1();
  useEffect(() => {
    console.log(props.test);
  });

  return <div onClick={() => console.log(props.test)}>{props.items.length}</div>;
}
```

`props` object that were used when component was rendered for the first time is kept alive. Completely unexpected behavior even when developer understands [closure context sharing](https://mrale.ph/blog/2012/09/23/grokking-v8-closures-for-fun.html).

**If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle (https://jsfiddle.net/Luktwrdm/) or CodeSandbox (https://codesandbox.io/s/new) example below:**

https://codesandbox.io/s/lz61v39r7

- Select test **3** 
- Click on the button "Create New Array" 5 times
- Take memory snapshot in the developer tools
- Inspect (array) objects
- There will be 4 arrays retained in memory `t0`, `t-2`, `t-1`, `t`

**What is the expected behavior?**

Should be 2 arrays retained in memory `t-1`, `t`.
Repository: neovim
Issue: :edit scrolls the viewport
Labels: enhancement

<!-- Before reporting: search existing issues and check the FAQ. -->

- `nvim --version`:  0.3.1
- Vim (version: ) behaves differently? :  cursor line does not move
- Operating system/version:  ubuntu 14.04
- Terminal name/version:  xterm
- `$TERM`:  xterm-256color

### Steps to reproduce using `nvim -u NORC`

```
nvim -u NORC

:call setline(1, range(1, 1000))
:w /tmp/test.txt
:normal 500G
:normal zb
:edit   # cursor moves here
```

### Actual behaviour
the screen scrolls and the cursor line moves to the middle of the screen

### Expected behaviour
the screen remains the same

### More information
according to Christian Brabandt 's comment to [the stackoverflow question](https://vi.stackexchange.com/questions/17780/neovim-cursor-line-moves-to-the-middle-of-the-window-after-edit), this patch [v8.1.0034](https://github.com/vim/vim/releases/tag/v8.1.0034) may has some effect
Repository: TypeScript
Issue: Conflicting function return types checked for single bindings, but not overloads.
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.1.1-insiders.20180926 (what's running in the playground)

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** conflicting function return

**Code**

```ts
declare var foo: () => number
declare var foo: () => string

declare function bar(): number
declare function bar(): string
```

**Expected behavior:** `foo` and `bar` to both fail

**Actual behavior:** `bar` seems to still type-check, inconsistently with `foo`

**Playground Link:** https://www.typescriptlang.org/play/index.html#src=declare%20var%20foo%3A%20()%20%3D%3E%20number%0D%0Adeclare%20var%20foo%3A%20()%20%3D%3E%20string%0D%0A%0D%0Adeclare%20function%20bar()%3A%20number%0D%0Adeclare%20function%20bar()%3A%20string

**Related Issues:** N/A
Repository: rust
Issue: format!() ignores precision while formatting Debug
Labels: T-lang

The `precision` field is ignored when formatting/printing `Debug` representation. Apparently, it *is* honored when formatting `Display` representation.

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2015&gist=516b0c6222b4b351b69e45c15943821b
Repository: go
Issue: cmd/go: -buildmode=pie does not build correct PIE binaries for ppc64le
Labels: NeedsInvestigation,arch-ppc64x

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?
latest

### Does this issue reproduce with the latest release?
yes

### What operating system and processor architecture are you using (`go env`)?
ppc64le

### What did you do?
Tried to run binaries built as PIE.

### What did you expect to see?
Correct execution

### What did you see instead?
Error messages like this:
./main.exe: error while loading shared libraries: R_PPC64_ADDR16_HA re10f2f8fa4 for symbol `' out of range
2018/09/05 09:53:14 Failed: exit status 127
on newer distros.

The problem is related to issues #27510 and #21954 and can still be reproduced on many distros by passing -pie as a linker option. 

The solution to the above issues was to use -buildmode=pie but that doesn't correct all problems. When linking a program with -pie on ppc64le then all code should be built as PIC. When some code is not PIC there could be relocations created like R_PPC64_ADDR16_HA which will fail with the above error if the relocated addresses are too big. On some distros/kernels we get lucky and no failures occur if the addresses stay small enough but on newer distros the runtime relocation errors can occur.

When using -buildmode=pie the -shared option is set to force the compiles to be built as PIC but it still links in stdlib which was not built as PIC. Likewise any library linked in should be PIC. When all the code is has been built as PIC then this relocation would not be generated and the PIE should work.

One further question is whether all code should be PIC if the gcc being used for the link passes -pie by default and stop setting -no-pie.