sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: react
Issue: Fail to render input in a separate window on Edge
Labels: Browser: IE,Component: DOM,Type: Needs Investigation

<!--
  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?**
On Edge, when to render any <input> components in a separate window, it comes to react-dom error for `<input>`, and JS error like

> SCRIPT5673: Unknown runtime error


**If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. 

`window.open` dose not work well on JSFiddle or CodeSandbox, so put a page link to reproduce the behavior

https://haojy.github.io/issues/input-error-in-separate-window.html

**What is the expected behavior?**

`<input>` component should be rendered as expected without errors

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**

React: v16.6.3 and V16.3.0
browser:
- only on Edge v42
- works well on IE 11/Chrome 70/Safari 12
Repository: rust
Issue: Avoid hashing more than is strictly necessary, in the compiler.
Labels: C-cleanup,T-compiler

It should be possible to build cheaper interners than what we currently have, using `raw_entry`.
cc @rust-lang/compiler @Gankro @Amanieu
Repository: TypeScript
Issue: In JS, don't complain about a better inferred type if there's no code action
Labels: Suggestion,Fixed,Domain: JavaScript,Experience Enhancement,Fix Available

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.2.0-rc

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** inferred type

**Code**
JS file with `checkJS` on:
![unbenannt](https://user-images.githubusercontent.com/17641229/49149750-34279800-f30b-11e8-9e8c-59a268fdfdf2.PNG)

This message is on **every single** parameter without a JSDoc comment!

**Expected behavior:**
No complaint, or a code action that is offered

**Actual behavior:**
Complaint about a better inferred type, <kbd>Ctrl</kbd> + <kbd>.</kbd> offers no code actions.

**Related Issues:** https://github.com/Microsoft/TypeScript/issues/22357
Repository: neovim
Issue: virtualtext: multiple EOL virtual text annotations per line
Labels: enhancement,needs:design,marks

`nvim_buf_clear_highlight` with id=2 will also clear the highlight for id=1.

```vim
let b = bufnr('%')

let id1 = nvim_buf_set_virtual_text(b, 0, 0, [['foo', 'Error']], {})
let id2 = nvim_buf_set_virtual_text(b, 0, 0, [['foo', 'Error']], {})

echo [id1, id2]

call nvim_buf_clear_highlight(b, id2, 0, -1)
```

This happens with both using `0` for an auto-generated src_id, or when using 1 and 2 directly.
Also using the same text is not relevant here.

Relevant code: 
https://github.com/neovim/neovim/blob/def608cd248218f9473caebb99e848e67a46a6f6/src/nvim/buffer.c#L5485-L5520

Neovim v0.3.2-931-gdef608cd2.
Repository: rust
Issue: Warn against `mod lib;` in `main.rs`
Labels: A-lints,T-lang,T-cargo

Right now this is possible and compiles without warning:

Given a cargo crate with name "foo":

```rust
// src/lib.rs
```

```rust
// src/main.rs

mod lib;
fn main() {}
```

... even though we now have duplicated code in the library "foo" and the submodule "lib"

This can be confusing for a beginner because the code can still compile or just breaks "late" depending on what you do:


```rust
// src/lib.rs

pub struct Foo;
```

```rust
// src/main.rs

mod lib;

// either of those work (though not at the same time):
use foo::Foo;
use crate::lib::Foo;

fn main() {}
```

cargo or rustc should detect if we use `lib.rs` as a submodule, and warn or error against it.

---

This issue assumes 2018 edition without uniform paths syntax.
Repository: pytorch
Issue: Add a debug mode which is -O0 for framework code, but -O for kernels
Labels: module: build,triaged

One of the reasons people don't like `DEBUG=1` defaulting to `-O0` is because it makes their tests run slowly. But they also don't like `-O` because you get not very useful information inside gdb.

Wouldn't it be nice to have the best of both worlds? Well, maybe we can achieve this, by having a mode where we can compile kernels with optimizations, and framework code without it. We'd have to come up with some sort of dividing principle in cmake land (maybe folder structure), but hopefully most of the time you want to debug a backtrace, it's because some framework code is bad, not a kernel.

cc @malfet @seemethere @walterddr
Repository: pytorch
Issue: Flaky download from files.pythonhosted.org when installing botocore
Labels: triaged,module: flaky-tests,better-engineering

Log: https://circleci.com/gh/pytorch/pytorch/316264?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

```
Exception:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/pip/basecommand.py", line 122, in main
    status = self.run(options, args)
  File "/usr/lib/python2.7/dist-packages/pip/commands/install.py", line 278, in run
    requirement_set.prepare_files(finder, force_root_egg_info=self.bundle, bundle=self.bundle)
  File "/usr/lib/python2.7/dist-packages/pip/req.py", line 1198, in prepare_files
    do_download,
  File "/usr/lib/python2.7/dist-packages/pip/req.py", line 1376, in unpack_url
    self.session,
  File "/usr/lib/python2.7/dist-packages/pip/download.py", line 546, in unpack_http_url
    resp = session.get(target_url, stream=True)
  File "/usr/share/python-wheels/requests-2.2.1-py2.py3-none-any.whl/requests/sessions.py", line 467, in get
    return self.request('GET', url, **kwargs)
  File "/usr/lib/python2.7/dist-packages/pip/download.py", line 237, in request
    return super(PipSession, self).request(method, url, *args, **kwargs)
  File "/usr/share/python-wheels/requests-2.2.1-py2.py3-none-any.whl/requests/sessions.py", line 455, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/share/python-wheels/requests-2.2.1-py2.py3-none-any.whl/requests/sessions.py", line 558, in send
    r = adapter.send(request, **kwargs)
  File "/usr/share/python-wheels/requests-2.2.1-py2.py3-none-any.whl/requests/adapters.py", line 378, in send
    raise ConnectionError(e)
ConnectionError: HTTPSConnectionPool(host='files.pythonhosted.org', port=443): Max retries exceeded with url: /packages/53/80/8328098290ca3bfeca05b96c4041c5a7f861219c22624ff482aa859107e9/botocore-1.12.25-py2.py3-none-any.whl (Caused by <class 'socket.error'>: [Errno 104] Connection reset by peer)

Storing debug log for failure in /home/circleci/.pip/pip.log
```

I'm not sure what we should do here: we can't preload botocore onto our Docker image, because this happens before we have gotten our Docker image.
Repository: go
Issue: go/printer: consider using last position for nodes with no position
Labels: NeedsInvestigation

Reminder issue to experiment with using the last known (end) position for nodes where we don't have a position (and where NoPos is not used to indicate absence of a token).

From e-mail conversation with @aclements:

> > On Wed, Nov 28, 2018 at 8:34 AM Austin Clements <austin@google.com> wrote:
> > Thanks! Assigning the new Specs I created in the const block to the position of the const worked perfectly.
> > 
> > Is there a reason we don't treat NoPos nodes as having the position of the nearest ancestor when printing?
> 
> NoPos sometimes indicates that a token is absent (e.g., the position of '(' or ')' is NoPos if those parentheses are missing).
> 
> But I suppose in other cases it might work - interesting thought. I'm slightly worried that making such a change might break existing carefully tuned code though. But worthwhile an experiment.
Repository: go
Issue: reflect: document struct field layout in memory
Labels: Documentation,NeedsInvestigation,compiler/runtime

### What version of Go are you using (`go version`)?

1.11

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

N/A

### What did you do?

Read the docs, specifically as to (1) whether the memory layout of structures has any predictable qualities, (2) whether reflect's Field() (on either reflect.Type or reflect.Value) finds them in a predictable order.

### What did you expect to see?

More detailed information.

Empirically, it appears that fields are always reported in source code order, and are always laid out in source code orde. Gven the AST entries representing the declaration of two struct field identifiers for a given struct, the one that came first will have a lower offset, and its field number, as used by Field() or FieldByIndex(), etc., will also be lower.

I don't think this being untrue breaks any compatibility promises, so it may not be true. It's almost never significant. I've seen one case where behavior of code might actually depend significantly on it, in the behavior of a library using reflect to iterate over structs to synthesize a list of command-line flags at runtime.

To be clear, I'm not necessarily asking that the behavior be codified. I'd also be fine with "the ordering is not guaranteed to be consistent", as long as it's safe to assume that, given a value and type that correspond to the same structure type, Field(i) gives *corresponding* fields in both of them. But right now, even *that* is not actually specified, although it's hard to imagine any possible way it could be untrue without breaking all sorts of things.

Note overlap with issue #10014 on struct layout/padding. Really, the substantive new part is probably just the observation that nothing is stated about the semantics of Field(), and that if it's not guaranteed to pick one of source order or memory order, or some order anyway, that would be nice to know.

### What did you see instead?

Less detailed information.
Repository: pytorch
Issue: prim::ConstantChunk derivative formula doesn't handle undefined inputs
Labels: oncall: jit

It's a multi-output node, so it has to handle the case when not all outputs get well defined gradients (e.g. when some outputs are unused).
Repository: pytorch
Issue: building bundled nccl fails in (caffe2, cuda 8, cudnn 7) CI environment
Labels: caffe2

the error is the same as seen in #13362 - they're likely related, although this does not involve ccache.

To uncover this bug, remove the hardcoding of USE_SYSTEM_NCCL=1 in .jenkins/caffe2/build.sh

The error ends up looking like this

```
nvlink fatal   : Internal error: reference to deleted section
```

I partially investigated this, with these findings

(1) building the bundled nccl works in the exact same environment when driven by the pytorch build (i.e. calling setup.py). Tested by spinning up the docker container and trying both the caffe2 and the pytorch build.
(2) the difference is, for some reason, because the pytorch build has `MAKEFLAGS=s -j --jobserver-fds=3,4` and `MFLAGS=s -j --jobserver-fds=3,4`, while the caffe2 build has only `-s` in each variable. So - something about the jobserver makes the build succeed during the torch build.

I verified this by explicitly setting `MAKEFLAGS=-s` and `MFLAGS=-s` in nccl.cmake, and running another pytorch build. It then fails in the same way as the caffe2 build.

To uncover this difference in the first place, I replaced the build command in nccl.cmake with `bash -c "env > /tmp/ncclenv"` to output the environment of the nccl sub-build, and diffed the resulting file when driven by the pytorch build and the caffe2 build.
Repository: go
Issue: runtime: potential for self-deadlock in runtime write barriers
Labels: compiler/runtime

In the runtime there's an implicit invariant that's being maintained: write barriers may not be called into while the mheap.lock is held or the runtime could deadlock. This invariant is not documented anywhere nor is it enforced via `nowritebarrier` or `nowritebarrierrec` annotations.

Consider the following situation:
1. Call into runtime.XXX
2. runtime.XXX grabs the heap lock.
3. runtime.XXX assigns a heap pointer value into some location.
4. The write barrier is on and is invoked.
5. The write barrier attempts to enqueue the pointer into a marking work buffer.
6. There are no empty work buffers available to enqueue the pointer for marking.
7. Call into mheap.allocManual to allocate space for more work buffers.
8. mheap.allocManual attempts to grab the heap lock.
9. Deadlock.

After some manual inspection, I'm fairly convinced that this isn't really a problem today because everywhere the heap lock is held, only `notinheap`-annotated structures are manipulated, so no write barriers are ever generated in those sections.

However, this invariant adds an additional mental burden when making changes to the runtime, and one day we may want to allow such write barriers (see https://go-review.googlesource.com/c/go/+/46751/12/src/runtime/mgc.go#266 for example), so perhaps the invariant doesn't need to exist at all.

traceBufs for example are managed via sysAlloc and sysFree directly, whereas GC mark work buffers live in heap-allocated spans. If we were to move GC mark work buffers to use the same model, this would effectively remove this invariant. Making this change will require some work, so I'm kicking this issue to 1.13.

CC @aclements @RLH
Repository: pytorch
Issue: Batch matmul with sparse matrix, dense vector
Labels: todo,module: sparse,triaged

When I use torch.matmul or SparseTensor.mm, I can't seem to do batch matmul:

`
torch.matmul(sparse_mat, batch)
`
<br>gives:

```
RuntimeError                              Traceback (most recent call last)
<ipython-input-45-a815f1be316f> in <module>()
----> 1 torch.matmul(sparse_mat, batch)


RuntimeError: sparse tensors do not have strides
```

When the matrix is dense, it runs without a problem:

`
torch.matmul(sparse_mat.to_dense(), batch)
`

So I have had to resort to iterating over batches, which makes it a bit slower than the custom implementation I built for my project. With parallelization over batches, it would be really simple to write custom autograd functions to speed up my implementation (something like [this](https://gist.github.com/anonymous/49c10bc17ac4a97307d52c07d01a2870))

Any suggestions or upcoming support for batch operations for dense vector * sparse matrix -> dense vector operations? Am I missing something that is currently working for this?

cc @vincentqb
Repository: TypeScript
Issue: Make JS/TS Import fix insert import in linter specified order
Labels: Suggestion,Awaiting More Feedback,Domain: TSServer

<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
Popular linting rules in the TypeScript community require imports to be in alphabetic order (see [ordered-imports in tslint:recommended](https://github.com/palantir/tslint/blob/a43cfdc4534c63447a6a5a66a6802716892503d2/src/configs/recommended.ts#L125)). This is generally useful for readability of imports. 

In VS Code, when a developer references an external module that hasn't been imported, VS Code offers a useful fix, which adds the appropriate import: 

![image](https://user-images.githubusercontent.com/3891951/49174467-3d106d80-f2fb-11e8-9a13-3ae3323e398d.png)

This is extremely useful! Thanks you! :tada:

However, once automatically imported, the import is just added to the end of the import list, leading to a linter error (since it's not in alphabetic order)😕:

![image](https://user-images.githubusercontent.com/3891951/49177771-e6a72d00-f302-11e8-825d-7585225ec203.png)


You can then auto-fix the import issue (VS Code is aware of the TSLint preferences):
![image](https://user-images.githubusercontent.com/3891951/49175461-7d70eb00-f2fd-11e8-9f69-213eef2ea944.png)

Would it be possible to short-circuit these steps such that when a developer "fixes" a missing import, it automatically inserts it in the appropriate order based on linting rules? FWIW, this also applies to the JS community (eslint has import order rules as well).
Repository: rust
Issue: edition idioms: Incorrect span in `extern crate` removal
Labels: C-enhancement,A-lints,A-diagnostics,T-compiler,A-suggestion-diagnostics,D-incorrect,A-edition-2018

[First reported upstream](https://github.com/rust-lang/cargo/issues/6360) this code:

```rust
#![warn(rust_2018_idioms)]

#[cfg_attr(test, macro_use)]
extern crate itertools;

use itertools::Itertools;

fn main() {
    println!("{:?}", (0..1).collect_vec());
}
```

[when compiled](https://play.rust-lang.org/?version=beta&mode=debug&edition=2018&gist=04ce404ce50b4ad3ab21582d8556d382) yields:

```
warning: unused extern crate
 --> src/main.rs:4:1
  |
4 | extern crate itertools;
  | ^^^^^^^^^^^^^^^^^^^^^^^ help: remove it
  |
note: lint level defined here
 --> src/main.rs:1:9
  |
1 | #![warn(rust_2018_idioms)]
  |         ^^^^^^^^^^^^^^^^
  = note: #[warn(unused_extern_crates)] implied by #[warn(rust_2018_idioms)]
```

but the suggestion is incorrect! Both the `extern crate` and the attribute on the item should be removed.
Repository: pytorch
Issue: [Caffe2] GPU test passed. Cannot see on nvidia-smi
Labels: caffe2

GPU test passed. However, when I run code no PID is shown on nvidia-smi. Is there other way to check whether the code is running on GPU? Or is there some more lines of code I need to add so that caffe2 detects GPUs and uses it?
Repository: go
Issue: x/build/maintner: isTempError improvements
Labels: Builders,NeedsInvestigation

Currently `isTempError` logs the error and vacuously returns true 
```go
func isTempErr(err error) bool {
	log.Printf("IS TEMP ERROR? %T %v", err, err)
	return true
}
```
This is used in the `sync` function's error group members in conjunction with `loop` to determine if the error returned from the various source `sync` functions is a temporary error or not.
```go
for {
  err := gr.sync(ctx, token, loop)
  if loop && isTempErr(err) {
	log.Printf("Temporary error from github %v: %v", gr.ID(), err)
	time.Sleep(30 * time.Second)
	continue
  }
  log.Printf("github sync ending for %v: %v", gr.ID(), err)
	return err
}
```

This guarantees that if `SyncLoop` is called, the routines will loop forever (`loop` is true and `isTempErr` always returns true), but it also means that if `Sync` is called, and any repository sync operation fails, the entire error group will exit. In a `corpus` that is tracking hundreds of repositories with tens of thousands of issues, a single temporary error in the `Sync` call will always abort all other routines in the group.

It would be useful to be able to provide criteria for what constitutes a temporary error or not.

I propose something similar to the following:
```go
type errCheck func(error) bool

// SyncLoop runs forever (until an error or context expiration) and
// updates the corpus as the tracked sources change.
func (c *Corpus) SyncLoop(ctx context.Context, check errCheck) error {
	if check == nil {
		check = isTempErr
	}
	return c.sync(ctx, true, check)
}

// Sync updates the corpus from its tracked sources.
func (c *Corpus) Sync(ctx context.Context, check errCheck) error {
	if check == nil {
		check = isTempErr
	}
	return c.sync(ctx, false, check)
}
func (c *Corpus) sync(ctx context.Context, loop bool, check errCheck) error {
	if _, ok := c.mutationSource.(*netMutSource); ok {
		return errors.New("maintner: can't run Corpus.Sync on a Corpus using NetworkMutationSource (did you mean Update?)")
	}

	group, ctx := errgroup.WithContext(ctx)
	for _, w := range c.watchedGithubRepos {
		gr, token := w.gr, w.token
		group.Go(func() error {
			log.Printf("Polling %v ...", gr.id)
			for {
				err := gr.sync(ctx, token, loop)
                                isTempErr := check(err)
				if loop && isTempErr {
					log.Printf("Temporary error from github %v: %v", gr.ID(), err)
					time.Sleep(30 * time.Second)
					continue
				}
				log.Printf("github sync ending for %v: %v", gr.ID(), err)
                                if isTempErr {
                                    err = nil
                                }
				return err
			}
		})
	}
  // Rest of function similarly calls check
}
```

This would give the consumers of `corpus` the ability to determine what constitutes a temporary error, but default back to the old behaviour by passing `nil` to `Sync` and `SyncLoop`
Repository: TypeScript
Issue: JSDoc @type for list of declarations
Labels: Bug,Domain: JavaScript

Issue Type: <b>Bug</b>

When using the `@type` JSDoc for an empty array when declaring multiple variables, only the first declaration is recognized by intellisense.  It is overridden by what is actually in the array.

It's possible I'm not documenting this correctly, so if that's the case please correct me.

Example of it working for the first declaration:

![image](https://user-images.githubusercontent.com/498929/48814902-6b85bb80-ecf1-11e8-8009-5a5893ad1b78.png)

Example of it failing for other declarations:

![image](https://user-images.githubusercontent.com/498929/48814923-82c4a900-ecf1-11e8-82a5-eb2093541873.png)

![image](https://user-images.githubusercontent.com/498929/48814953-953ee280-ecf1-11e8-8428-9faba5e1c411.png)

VS Code version: Code 1.29.1 (bc24f98b5f70467bc689abf41cc5550ca637088e, 2018-11-15T19:13:36.375Z)
OS version: Windows_NT x64 10.0.18272

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz (12 x 4044)|
|GPU Status|2d_canvas: enabled<br>checker_imaging: disabled_off<br>flash_3d: enabled<br>flash_stage3d: enabled<br>flash_stage3d_baseline: enabled<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>native_gpu_memory_buffers: disabled_software<br>rasterization: enabled<br>video_decode: enabled<br>video_encode: enabled<br>webgl: enabled<br>webgl2: enabled|
|Memory (System)|15.94GB (4.89GB free)|
|Process Argv||
|Screen Reader|yes|
|VM|0%|

</details><details><summary>Extensions (9)</summary>

Extension|Author (truncated)|Version
---|---|---
vscode-css-formatter|aes|1.0.1
vscode-eslint|dba|1.7.0
vscode-npm-script|eg2|0.3.5
asciidecorator|hel|0.2.0
vscode-auto-open-markdown-preview|hnw|0.0.4
classic-asp|ili|0.0.4
mssql|ms-|1.4.0
python|ms-|2018.10.1
cpptools|ms-|0.20.1


</details>
<!-- generated by issue reporter -->
Repository: go
Issue: cmd/trace: does not track or report in-syscall properly 
Labels: NeedsInvestigation,compiler/runtime

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

1.11.2

### Does this issue reproduce with the latest release?

yes

### What operating system and processor architecture are you using (`go env`)?

osx, darwin, amd64

### What did you do?

simple ping/pong network test [here](https://github.com/robaho/go-network-test)

you need to change the benchmark time to make it run longer

I selected an area of threads in the graph.

### What did you expect to see?

Since it is a ping-pong, I would expect to see threads alternating between in-syscall, and running.

### What did you see instead?

all of the in-syscall counts are 0, but the running alternates from 0 to 1 as expected

Here is a screen shot:

![image](https://user-images.githubusercontent.com/4958833/49200195-47fde900-f361-11e8-9a8f-6833eda16d59.png)

and here is when I scroll down to the running:

![image](https://user-images.githubusercontent.com/4958833/49200226-78458780-f361-11e8-899d-fd7af6ee4e78.png)
Repository: flutter
Issue: Show users how to run analyze locally when CI fails
Labels: team,tool,P2,team-tool,triaged-tool

Got this from multiple contributors now. After sending a PR, the analyze shard fails with tests they have no idea existed and it doesn't show them how to test and fix locally before pushing more commits to the PR. 

i.e. dart dev/bots/analyze.dart