sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Use React TSX tags without having to write "import React from 'react'"
Labels: Suggestion,Awaiting More Feedback

<!-- 🚨 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.

-->

## Suggestion

I have to write `import React from 'react'` every time I use TSX syntax even though I make no explicit mention of the name `React` in the following lines of code (Of course, TSC output will contain mentions of `React` but the key is _explicit_). 

It is possible to write JSX tags in Babel's JavaScript without `import React from 'react'` by using Babel's/Webpack's plugins. A notable example is [Next.js](https://github.com/zeit/next.js/blob/canary/examples/basic-export/pages/index.js).

Therefore I suggest: If user are not mentioning `React` directly, user shouldn't have to declare `React` explicitly. This can be configured in compiler options, something like a combination of `--jsxFactoryPath` and `--jsxModule` for example.

<!-- A summary of what you'd like to see added or changed -->

## Examples

<!-- Show how this would be used and what the behavior would be -->

### React.js

#### Ideal Source Code

**tsconfig.json:**

```json
{
  "compilerOptions": {
    "module": "commonjs",
    "jsxFactoryPath": ["createElement"],
    "jsxModule": "react"
  }
}
```

**index.tsx:**

```typescript
export = <div id='123'>hello</div>
```

#### Desired Output

**index.js:**

```javascript
var _jsx = require("react").createElement;
module.exports = _jsx("div", { id: "123" }, "hello");
```

### Hyperscript

#### Ideal Source Code

**tsconfig.json:**

```json
{
  "compilerOptions": {
    "module": "commonjs",
    "jsxFactoryPath": [],
    "jsxModule": "hyperscript"
  }
}
```

**index.tsx:**

```typescript
export = <div id='123'>hello</div>
```

#### Desired Output

```javascript
var _jsx = require("hyperscript");
module.exports = _jsx("div", { id: "123" }, "hello");
```

### Generic

#### Ideal Source Code

**tsconfig.json:**

```json
{
  "compilerOptions": {
    "module": "commonjs",
    "jsxFactoryPath": ["obj1", "obj2", "func"],
    "jsxModule": "pkg/dir1/dir2"
  }
}
```

**index.tsx:**

```typescript
export = <div id='123'>hello</div>
```

#### Desired Output

**index.js:**

```javascript
var _jsx = require("pkg/dir1/dir2").obj1.obj2.func;
module.exports = _jsx("div", { id: "123" }, "hello");
```

## 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. new expression-level syntax)
Repository: create-react-app
Issue: Prevent shell output deletion when launching
Labels: issue: proposal

It's quite silly, but I'd just like to propose that the start script doesn't erase the previous shell output by default. This can be bit annoying if you ever forget to run in a separate shell, use a screen/script command etc. I looked for a possible setup in the docs but didn't find any. Maybe I'm missing something though.
Repository: bitcoin
Issue: Callback/notification documentation and cleanup
Labels: Docs

I believe many aspects of how callbacks or notifications work are not well-documented, particularly the user-facing behaviors (like the various `-*notify` behaviors, zmq interface, and synchronization guarantees between the wallet/mempool/validation).  Along with a lack of documentation, I believe there's likely a lack of regression testing to ensure that our software continues to enforce whatever implicit guarantees users may have come to expect.  And it makes changes to the behavior more difficult, as it is hard to reason about changes to behavior without some context for what expectations might be.

I think it'd be a great project for someone to pick some of these interfaces and document exactly how they work.  I imagine this would uncover some oversights that will be a jumping off point for making improvements as well.

As an example here are a few questions that show the kinds of things that I think are missing documentation:
 * What are the ordering guarantees of eg `-blocknotify` callbacks, and what should they be? (#14275 highlights that there is a discrepancy between our own python tests and the behavior in our software)
 * Exactly which transactions are announced via the zmq interface -- for instance during a reorg, or a transaction being evicted, a transaction being replaced due to conflict, etc?
 * What ordering guarantees exist (if any) between notifications received via zmq and when the rest of our software (wallet/mempool/validation) reflecting the same underlying event via our RPC interface?
 * What should the synchronization be between RPC calls that affect validation-level information (like `getbestblockhash` and RPC calls that touch the mempool? (eg see #14193 for a reasonable-looking change that IMO should be evaluated in a larger context about how our interfaces should work).

etc.
Repository: pytorch
Issue: caffe2 argmax and argmin documentation incorrect for output type
Labels: caffe2


## Issue description

It looks like the documentation for the output types for the caffe2 argmax and argmin operators are incorrect.

The documentation says that they should be floats:

https://github.com/pytorch/pytorch/blob/8f4601fbac5565218212908fe9be57abcbf14145/caffe2/operators/arg_ops.cc#L163

But it looks like the infer function is making sure they are int64s:

https://github.com/pytorch/pytorch/blob/8f4601fbac5565218212908fe9be57abcbf14145/caffe2/operators/arg_ops.cc#L89

- PyTorch or Caffe2: caffe2
- How you installed PyTorch (conda, pip, source): nix
- Build command you used (if compiling from source):
- OS: linux
- PyTorch version:
- Python version:
- CUDA/cuDNN version:
- GPU models and configuration:
- GCC version (if compiling from source):
- CMake version:
- Versions of any other relevant libraries:
Repository: realworld
Issue: Functionality Testing
Labels: v2

It seems that some of the apps aren't actually functioning properly. The only one I've had complete success with is the Keechma app so far:

## Quick summary of non-functional features

Framework | Routing        | Tagging          | Article          | Profile       | Other
---       | ---            | ---              | ---            | ---           | ---
Angular   | home (logo)    | article tag nav  |                |               | Images broken
Angularjs |                | article tag nav  |                |               |
Redux     | home (logo)    | article tag nav  |                |               | No "favorite"
Re-frame  |                | article edit, tag nav |           |               |
Keechma   |                |                  |                |               | Can't delete comments
Vue       |                | article tag nav  |                |               | 
Mobx      |                | article tag nav  |                |               | 
Svelte    |                | article tag nav  | Publish sticks, no favorite |  | 
Apprun    |                | tag nav persists over feed |      | Profile Update |
Dojo2     | home (link)    |                  |                |                |
Crizmas   |                | article tag nav  |                |                |
Aurelia   |                | article edit, display, tag nav | profile links  |  | Whole app locks up with some clicking around pages
Elm       |                | article edit, tag nav |           |                |     

I think there should be some kind of user acceptance testing for these if they're supposed to compare apples to apples. I may have missed some, ran out of time to really dig into them all
Repository: rust
Issue: rustdoc: doc comments on `use` and `extern crate` statements run doctests
Labels: T-rustdoc,C-bug,A-doctests

The following two files fail `cargo test --doc`:

```rust
/// ```
/// panic!("oh no");
/// ```
use std::fs::File;
```

```rust
/// ```
/// panic!("oh no");
/// ```
extern crate asdf;
```

...despite neither of these code blocks actually getting displayed in docs. Until we decide to display any docs written on these kinds of statements, we should stop scanning them for doctests.
Repository: TypeScript
Issue: Mix on inline/external defined properties corrupt javascript intellisense
Labels: Bug,Domain: JavaScript

_From @mobisga on September 20, 2018 10:4_

Issue Type: <b>Bug</b>

Defining a variable:
var test = { prop1: '' }; test.prop2 = '';
intellisense does NOT recognize prop2 as a property belonging to test

Whereas defining:
var test = {  }; test.prop2 = '';
intellisense does recognize prop2 as a property belonging to test as it should

VS Code version: Code 1.27.2 (f46c4c469d6e6d8c46f268d1553c5dc4b475840f, 2018-09-12T16:17:45.060Z)
OS version: Windows_NT x64 10.0.15063

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i5-7500T CPU @ 2.70GHz (4 x 2712)|
|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.85GB (9.39GB free)|
|Process Argv|C:\Program Files\Microsoft VS Code\Code.exe C:\Users\_\Desktop\KeyEventsRuleTest.html|
|Screen Reader|no|
|VM|0%|

</details><details><summary>Extensions (4)</summary>

Extension|Author (truncated)|Version
---|---|---
ng-template|Ang|0.1.10
tslint|eg2|1.0.39
csharp|ms-|1.16.1
debugger-for-chrome|msj|4.10.1

(1 theme extensions excluded)

</details>
<!-- generated by issue reporter -->

_Copied from original issue: Microsoft/vscode#59033_
Repository: flutter
Issue: Support creation of an engine AAR instead of a JAR for Android.
Labels: platform-android,engine,e: embedder,a: existing-apps,P2,team-android,triaged-android

Support creation of an AAR instead of a JAR for Android.

Android uses XML resources as a canonical element of everyday development.  It is possible to reference FlutterFragment and FlutterView from XML, but the Flutter embedding currently has no capability to expose XML attributes to customize those elements.

For example, we might want to do this:
```xml
<io.flutter.embedding.FlutterView
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    app:splash="@android:color/blue"
    />
```

The definition of `app:splash` needs to be setup as an XML resource.  But we can't do this in the embedding because we aren't producing AARs and therefore we cannot include any resources.

The JAR restriction also prevents us from defining any of our own XML layouts, defining our own colors, defining any Flutter-specific IDs, etc.
Repository: go
Issue: doc/articles/wiki: "Writing Web Applications" example writes the reponse header twice
Labels: Documentation,NeedsFix

### What version of Go are you using (`go version`)?
go1.11


### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?

<details><br>

```
GOARCH="amd64"
GOBIN="/home/jabenze/go/bin"
GOCACHE="/home/jabenze/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/jabenze/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/go"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
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-build876174949=/tmp/go-build -gno-record-gcc-switches"
```

</details>

### What did you do?

Follow the "Writing Web Applications" tutorial here, up through the error handling section here: https://golang.org/doc/articles/wiki/#tmp_9.  L

Look at the function `renderTemplate`, reproduced here:

```
func renderTemplate(w http.ResponseWriter, tmpl string, p *Page) {
    t, err := template.ParseFiles(tmpl + ".html")
    if err != nil {
        http.Error(w, err.Error(), http.StatusInternalServerError)
        return
    }
    err = t.Execute(w, p)
    if err != nil {
        http.Error(w, err.Error(), http.StatusInternalServerError)
    }
}
```

Modify the `Page` data structure by removing a field (or modify the template to reference a nonexisting field) so that the line: `err = t.Execute(w, p)` will cause an error to be created.  Observe the response code sent by the application.  The following line: `http.Error(w, err.Error(), http.StatusInternalServerError)` would imply the response code to be 500, however, the application returns 200.

This is because `t.Execute` is calling `w.Write` which, because `w.WriteHeader` has not yet been called, causes an implicit call to `w.WriteHeader(200)`.  Further calls to `w.WriteHeader`, such as the one inside `http.Error` are ignored.

There is no way to able to send a 500 error code in the case of all errors, since `w.Write` itself can return an error, and at some point, one has to simply log an error and return without setting an error code.  Optionally, the example could render to a `bytes.Buffer` so that template rendering errors could be caught.

### What did you expect to see?
Based on the code, a 500 error code

### What did you see instead?
Error code 200.
Repository: rust
Issue: Testing `Sync` diverges on recursive type
Labels: A-type-system,T-compiler,T-types

Typechecking the following program diverges:
```rust
#![feature(never_type)]

struct Foo<'a, T: 'a> {
    ph: std::marker::PhantomData<T>,
    foo: &'a Foo<'a, (T, T)>,
}

fn wub(f: Foo<!>) {
    sync(f)
}

fn sync<T: Sync>(x: T) {}

fn main() {}
```

Cc @eddyb @nikomatsakis
Repository: go
Issue: path/filepath: Clean doesn't remove trailing backslash from Windows volume name
Labels: OS-Windows,NeedsInvestigation

### What version of Go are you using (`go version`)?
go 1.10.3 windows/amd64

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?
Windows 7, Core I7, x64

### What did you do?
> filepath.Clean(\`\\\\somepath\dir\\`)

### What did you expect to see?
`\\somepath\dir` (without trailing slash as per documentation)

### What did you see instead?
`\\somepath\dir\` (with trailing shash)

Seems that problem is in two Windows slashes at the beginning, all other cases work just fine.
Repository: vue
Issue: Different functional componens has the same key
Labels: has workaround

### Version
2.5.17

### Reproduction link
[https://github.com/vedmaque/vue-functional-bug](https://github.com/vedmaque/vue-functional-bug)





### Steps to reproduce
1) create `Component1`
```
<template functional>
  <div class="a">
    <div class="b">first (template)</div>
    <div class="b">component</div>
  </div>
</template>
```
2) create `Component2`
```
<template functional>
  <div class="x">
    <div class="y">second (template)</div>
    <div class="y">component</div>
  </div>
</template>
```
3) render them in App.
```
<template>
  <div id="app">
    <component1 />
    <component2 />
  </div>
</template>
```

### What is expected?
Everything works fine

### What is actually happening?
Vue warns about same key
```
[Vue warn]: Duplicate keys detected: '__static__0'. This may cause an update error.
```

---
If you create the same components from render function directly, it works fine, without duplicated keys (keys are `undefined` in this situation)
```
<script>
export default {
  functional: true,
  render(createElement) {
    return createElement("div", {
        staticClass: "a"
    }, [createElement("div", {
        staticClass: "b"
    }, ["first"]), createElement("div", {
        staticClass: "b"
    }, ["component"])])
  }
}
</script>
```

This image shows the difference in VNode objects.
![screenshot](https://github.com/vedmaque/vue-functional-bug/raw/master/functional-bug.png)

Moreover, if `Component1` looks likes this, it works fine too.
```
<template functional>
  <div class="a">first (template) component</div>
</template>
```

Vue Template Exporer will go crazy too if you try to compile `Component1`
https://template-explorer.vuejs.org/#%3Cdiv%20class%3D%22a%22%3E%0A%20%20%3Cdiv%20class%3D%22b%22%3Efirst%20(template)%3C%2Fdiv%3E%0A%20%20%3Cdiv%20class%3D%22b%22%3Ecomponent%3C%2Fdiv%3E%0A%3C%2Fdiv%3E%0A

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: godot
Issue: [Bullet] Kinematicbody snap drags objects down even without any velocity
Labels: bug,topic:physics

Godot version 534b7ef

Kinematicbody snap drags objects down even without any velocity.

**This is 3D, it is just sideview to better illustrate what is happening.**
![snap_drag](https://user-images.githubusercontent.com/40793342/45876405-433a1900-bda3-11e8-92a7-119e0840f08f.gif)


This is the full code in kinematicbody.

```
extends KinematicBody

var vel = Vector3()

func _physics_process(delta):
	vel = move_and_slide_with_snap(vel, Vector3(0, -1, 0), Vector3(0, 1, 0))
```

Copied here from one of my comments for visibility:

> Increasing collision safe margin makes it go faster so I think something like this happens:
> Kinematicbody snaps straight down to floor, then separates to safe margin along collision normal.
> Since collision normal is not parallel to y axis it moves slightly sideways and then this repeats.

[Minimal Project.zip](https://github.com/godotengine/godot/files/2404944/Minimal.Project.zip)
Repository: rust
Issue: Should `partial_cmp` on `Range` implement interval order?
Labels: C-enhancement,T-libs-api,A-docs

Hi,

Whilst implementing a data structure, I've noticed a quirk (or bug) in the `Range` implementation.

It appears that we can query the partial ordering relation between two ranges using `partial_cmp`. For example:

```
          assert_eq!((0..5).partial_cmp(10..20), Some(Ordering::Less));           
          assert_eq!((5..6).partial_cmp(1..5), Some(Ordering::Greater));          
          assert_eq!((5..10).partial_cmp(8..9), None);                            
```

The last assertion here fails:
```
  left: `Some(Less)`,
 right: `None`', src/lib.rs:81:9
```

This surprised me, as (unless I am mistaken) overlapping ranges cannot be compared in the interval order. In the above example, both 8 and 9 are members of both ranges.

From Wikipedia (https://en.wikipedia.org/wiki/Interval_order):

> one interval, I1, being considered less than another, I2, if I1 is completely to the left of I2

I suspect that the partial order of ranges has been `derive`ed leading to pairwise comparisons of the upper and lower bounds, which is a different partial ordering (actually a total ordering I think).

Am I right? If so, should `Range` implement interval order? In either case, improved documentation would really help.

Thanks
Repository: TypeScript
Issue: replace implicit 'any' with 'unknown'
Labels: Suggestion,Awaiting More Feedback,Add a Flag

<!-- 🚨 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

noImplicitAny, strict, any, unknown
<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

## Suggestion
When enabling `"strict": true` or `"noImplicitAny": true` in a project, could we assign `unknown` to un-inferred/un-typed variables, instead of causing a compiler error? This would be a non-breaking change, since all cases where this would have an effect are already compiler errors.

## Use Cases
It would allow avoiding having to specify a type when it's being type-checked anyway. The current implementation forces converted-from-js projects to deal with a *lot* of compiler errors from the outset (many of which use various runtime type-checking methods so should be happy with implicit `unknown`s).

## Examples
```typescript
const getMessage = input => typeof input === 'string' ? input : 'hello';
const shortenMessage = message => message.substring(3);
```
the `getMessage` example would be an error currently, but would be fine in the new world and the function would have return type `string`.
the `shortenMessage` example would have a changed error. instead of `Parameter 'message' implicitly has an 'any' type` we'd see an error at `message.substring` of `Object is of type 'unknown'.` To me that's more intuitive in terms of what the problem actually is. `message` _is_ unknown so it should have type `unknown`.
<!-- Show how this would be used and what the behavior would be -->

## 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. new expression-level syntax)
Repository: TypeScript
Issue: recursive return type for deterministic generators
Labels: Suggestion,Awaiting More Feedback

## Suggestion

If a generator neither yields inside a loop nor defers to another generator, it's considered deterministic. For any given number of `next` calls, the compiler could theoretically reduce the generator to the exact type of its next yield. Of course, because generators are mutable, this isn't true. But what if I'm using a library that allows for [immutable generators](https://github.com/pelotom/immutagen)? For every `next` call, a new generator is returned. Maybe it should be possible to introspect the order of yields in a deterministic generator, and use that to deduce a recursive type structure that represents an immutable generator.

```ts
import immutagen from 'immutagen'

const gen = immutagen(function* foo() {
  yield 0
  yield 1
})

const a = gen()
const b = a.next()
typeof a // => { value: 0, next: () => typeof b }
typeof b // => { value: 1, next: undefined }
```

## 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. new expression-level syntax)