sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Nested conditional type with generic tuple argument always expands to false branch.
Labels: Bug

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  next (`3.4.0-dev.20190330`), latest (`3.4.1`)

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
* tuple conditional type
* tuple compare
* tuple comparison

**Code**

```ts
type Not<T extends boolean> = [T] extends [true] ? false : true;
type NoOp<T extends boolean> = Not<Not<T>>; // always expands true (see intellisense)

type t0 = Not<Not<false>>; // false
type t1 = NoOp<false>;     // true (but should be false)
```

**Expected behavior:**
Type `t1` must be `false` and `NoOp` must be of the nested conditional type that depends on `T`, but not of simple `true` unit type.
**Actual behavior:**
As you see, something is broken when you use generic argument for tuple comparison in conditional type, because when you expand your types manually (`t0` is an expanded representation of `t1`) it works as expected.

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->

[Klick me](https://www.typescriptlang.org/play/index.html#src=type%20Not%3CT%20extends%20boolean%3E%20%3D%20%5BT%5D%20extends%20%5Btrue%5D%20%3F%20false%20%3A%20true%3B%0D%0Atype%20NoOp%3CT%20extends%20boolean%3E%20%3D%20Not%3CNot%3CT%3E%3E%3B%0D%0A%0D%0Atype%20t10%20%3D%20Not%3CNot%3Cfalse%3E%3E%3B%20%2F%2F%20false%0D%0Atype%20t11%20%3D%20NoOp%3Cfalse%3E%3B%20%20%20%20%20%2F%2F%20true%0D%0A)

**Related Issues:** <!-- Did you find other bugs that looked similar? -->

This bug report originated from my [stackoverflow question](https://stackoverflow.com/questions/55465053/typescript-tuples-conditional-comparison-always-evaluates-to-false).

Additional credits to @dragomirtitian and @fictitious for helping and localizing the bug to a minimal representation.
Repository: TypeScript
Issue: TS 3.4: Error when passing dynamically imported generic type as a function argument
Labels: Bug

<!-- 🚨 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.4.0-dev.201xxxxx

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** TS2322, dynamic import, dynamic import never, dynamic import generic

**Code**

     .\node_modules\.bin\tsc --jsx react --lib es2017 --strict index.tsx

```ts
// ===== page.tsx ======
import * as React from 'react'

export interface PageProps {
    title: string
}

export class Page extends React.Component<PageProps> {
    render() {
        return <div>{this.props.title}</div>
    }
}

// ===== index.tsx =====
import * as React from 'react'
import{ PageProps, Page } from './page'

export function myFunction<TProps>(loader: () => Promise<React.ComponentType<TProps>>) {

}

// No error
myFunction(() => Promise.resolve(Page))

// No error
const loader: () => Promise<React.ComponentType<PageProps>> = () => import('./page').then(m => m.Page)

// Error
myFunction(() => import('./page').then(m => m.Page))

```

**Expected behavior:**

No compile error. This was the behavior in TS 3.3 and earlier.

**Actual behavior:**

There is an error after upgrading to TS 3.4:

```
index.tsx:14:18 - error TS2322: Type 'Promise<typeof Page | ComponentClass<never, any> | FunctionComponen
t<never>>' is not assignable to type 'Promise<ComponentType<PageProps>>'.
  Type 'typeof Page | ComponentClass<never, any> | FunctionComponent<never>' is not assignable to type 'C
omponentType<PageProps>'.
    Type 'ComponentClass<never, any>' is not assignable to type 'ComponentType<PageProps>'.
      Type 'ComponentClass<never, any>' is not assignable to type 'ComponentClass<PageProps, any>'.
        Type 'PageProps' is not assignable to type 'never'.

14 myFunction(() => import('./page').then(m => m.Page))
                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  index.tsx:4:44
    4 export function myFunction<TProps>(loader: () => Promise<React.ComponentType<TProps>>) {
                                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    The expected type comes from the return type of this signature.
```

Repro here: https://github.com/srmagura/ts-import-repro
Repository: rust
Issue: Re-enable LLVM and debug assertions for slow builders
Labels: O-macos,P-low,T-infra

Assertions are currently disabled on a number of builders:

 * test-various - debug asserts, intentional - needed to properly test code size of some tests
 * dist-x86_64-apple - llvm, debug
 * dist-x86_64-apple-alt - llvm, debug
 * x86_64-apple - llvm, debug
 * dist-aarch64-apple - llvm, debug
Repository: flutter
Issue: Engine often does not correctly handle errors from the Dart embedding API
Labels: engine,dependency: dart,P2,team-engine,triaged-engine

The DART_CHECK_VALID macro had incorrect behavior in the face of Isolate.kill and Dart_Cleanup. It was removed upstream.

The engine is still in maybe places calling Dart_PropagateError in a context where is not Dart frame to which the error can be propagated. One example is the initialization of the core libraries that happens in the isolate creation callback.
Repository: rust
Issue: Why are 'maybe' bounds not permitted in trait objects?
Labels: C-enhancement,A-trait-system,T-lang,A-trait-objects

For example,

```rust
type Foo = dyn Send + ?Sized;
```

gives the error `` `?Trait` is not permitted in trait object types ``.

Is there any good reason for this rule? Either from a language-theoretic or implementation viewpoint.

I ask mainly because I'm try to enforce this for trait objects that use trait aliases in the compiler, but this error is currently raised during AST validation, and would be very difficult to do during typeck, since information about 'maybe' bounds is only included in the HIR and not the type system.

CC @Centril
Repository: rust
Issue: Run-pass checks for warnings, notes, etc.
Labels: A-testsuite,A-lints,T-compiler

When writing https://github.com/rust-lang/rust/pull/59658, I found it neccesary to check for warnings in a `run-pass` test because `deny(warning)` would observably change the warning pattern I was testing for in the first place.

It would be nice if `run-pass` would check for `WARN`, `NOTE`, `HELP`, etc. and cause a test failure if those are not found when expected. A bonus point for failing for unexpected `WARN`s etc. as well.
Repository: pytorch
Issue: [Feature Request] Flattened indices option for max pooling
Labels: module: nn,triaged,enhancement,module: pooling

## 🚀 Feature
Option to return flattened indices for max pooling layers.

## Motivation
Some operations require to have access to the flattened indices that ONNX returns initially. For instance, let's consider this vision example: I am working on a layer that counts how many times the element (pixel) at position `i` was the winner (selected as maximum) in a max pooling 2d operation.

As things are right now, this is the solution:
```python
def forward(self, input):
    _, indices = self.maxpool2d(input)
    N, C, H, W = input.size()
    minlength = H * W
    Nout, Cout, Hout, Wout = indices.size()
    indices_count = [t.bincount(minlength=minlength) for t in indices.view(-1, Hout * Wout).unbind()]
    return torch.stack(indices_count).view(input.size())
```

This implementation is very slow. The overhead introduced by running this for-loop could be avoided if flattened indices were returned. This is how the code would look like then:
```python
def forward(self, input):
    input_flattened_length, input_shape = input.nelement(), input.size()
    _, indices = self.maxpool2d(input)
    return indices.view(-1).bincount(minlength=input_flattened_length).view(input_shape)
```

The indices for max pooling 2d are currently referencing local frames, non-flattened. See [this issue](https://github.com/pytorch/pytorch/pull/16455#issuecomment-460776407) for a clearer picture of what this means.

## Pitch
This feature would allow to return flattened indices, in the same way as [tf.nn.max_pool_with_argmax](https://www.tensorflow.org/api_docs/python/tf/nn/max_pool_with_argmax) does.

## Alternatives
1. To implement `apply_along_axis`. This is a draft showing how it would solve my problem:
```python
def forward(self, input):
    _, indices = self.maccpool2d(-input)
    N, C, H, W = input.size()
    minlength = H * W
    Nout, Cout, Hout, Wout = indices.size()
    r = np.apply_along_axis(lambda x: np.bincount(x, minlength=minlength), axis=-1, arr=indices.view(N, C, -1).numpy())
    return torch.from_numpy(r).view(input.size())
```
2. To add a frequency counter that takes the indices returned by max pooling 2d (for instance) and sets in the location of the tensor corresponding to each index, the amount of times it was encountered in the returned indices.

## Additional context
In short, what I am trying to implement is the following:

![CodeCogsEqn (2)](https://user-images.githubusercontent.com/7946422/55476426-d1c30900-5616-11e9-85ba-4ae3f2a91677.gif)
where C contains the unfolded set of kernel windows.

In words: for each kernel window `c`, it adds `1` in the output at the location of the winner, `1[argmax c]`.


cc @albanD @mruberry @houseroad @spandantiwari @lara-hdr @BowenBao @neginraoof
Repository: godot
Issue: Create Outline Mesh unexpected result for PlaneMesh and flat CubeMesh
Labels: topic:rendering,topic:editor,documentation

**Godot version:**
Godot v3.1.stable.official


**OS/device including version:**
Windows 10 64bit

**Issue description:**
The "Create Outline Mesh" doesn't work properly for PlaneMesh (or CubeMesh with x xor y xor z set to 0), creating an outline that is just a copy of the original mesh offset by the specified outline width.

**Left:** result of the automatically generated outline, **Right:** expected result

Top:
![Top](https://i.imgur.com/CVrR1F3.png)

Bottom:
![Bottom](https://i.imgur.com/vlYV6n7.png)

Side:
![Side](https://i.imgur.com/5ICPA53.png)

**Steps to reproduce:**
1. Create a MeshInstance
2. Set the MeshInstances Mesh to a PlaneMesh (or CubeMesh with x xor y xor z set to 0)
3. Generate the outline by clicking on Mesh -> Create Outline Mesh

**Minimal reproduction project:**
[OutlineIssue.zip](https://github.com/godotengine/godot/files/3038749/OutlineIssue.zip)
Repository: pytorch
Issue: Running custom operator tests manually is too difficult
Labels: module: cpp-extensions,module: tests,triaged,enhancement

To compile/run custom operator tests one needs to:

1. build the repo normally
2. find the folder where the custom operator tests live
3. make a new cmake build folder for them
4. build cmake, setting the CMAKE_PREFIX_PATH correctly, otherwise the FindTorch.cmake file is not found and it doesn't work
5. figure out how to invoke the C++ tests
6. figure out how to invoke the python tests.

The precise details for osx and linux are spread across at least 4 separate CI scripts hidden in dot folders.

Instead: There should be a python test/test_custom_ops.py that simply runs all those steps for you.

cc @ezyang @gchanan
Repository: flutter
Issue: Touching the screen should be represented as 0x01 in buttons
Labels: framework,f: gestures,c: proposal,P3,team-framework,triaged-framework

## Reasoning
Currently, "touching" is not considered as a button. More specifically,

| Action | Dispatched `PointerDownEvent` | 
| -- | -- |
| Touch screen tap start | `buttons = 0x0` |
| Stylus tap start | `buttons = <0_or_other_buttons>` |
| Inv-stylus tap start | `buttons = <0_or_other_buttons>` |

However, in reality, touch and stylus touch are almost always considered the same as left mouse button. Currently, a gesture that wants to recognize "touch tap, stylus tap or LMB press" has to use:
```
(event.device == PointerDeviceKind.mouse && event.buttons == kPrimaryMouseButton) || (event.buttons == 0)
```
If we define `0x01` as the "primary button" that is equivalent to LMB on all devices, then a gesture that wants to recognize the aformentioned buttons can simply use:
```
event.buttons == kPrimaryButton
```
where `kPrimaryButton` is a new constant with value `1`.

Another benefit of this change is to fix the misalignment between `buttons` and `down`.
Currently, the relationship between `(buttons != 0)` and `(down != false)` is different across devices:
- The two booleans are the same for mouse.
- The two booleans are independent for stylus.
- And for touch, `buttons` doesn't make sense.

After the change, the two booleans will always be the same.

Last but not least, this change also aligns with the design where stylus buttons start from `0x02` instead of `0x01`.

Some discussion and demand can be found at [[1]](https://docs.google.com/a/google.com/document/d/1rlHXrnhic2Wz0fXI8PX2HCghZLrG1xJIcQ6Draf3l-4/edit?disco=AAAACqf2puI) [[2]](https://docs.google.com/a/google.com/document/d/1rlHXrnhic2Wz0fXI8PX2HCghZLrG1xJIcQ6Draf3l-4/edit?disco=AAAACqf2puA) [[3]](https://github.com/flutter/flutter/pull/30339#discussion_r271087162)

## Changes
We propose to add `0x01` to `buttons` whenever the pointer is in contact with the screen.

More specifically,

| Action | Dispatched `PointerDownEvent` | 
| -- | -- |
| Touch screen tap start | `buttons = 0x1` |
| Stylus tap start | `buttons = 0x1 \| <other_buttons>` |
| Inv-stylus tap start | `buttons = 0x1 \| <other_buttons>` |

No changes are made to mouse events.

## Breaking: No
Since Flutter does not support gestures that recognize buttons, this change will not break existing code, except for the code that writes their own gesture recognizers that distinguishes buttons.

## Development plan
The correct place for this feature belongs to the engine (embedder). Unfortunately, this change requires tracking the state of `down`, which is done by `PointerEventConverter`. 
`PointerEventConverter` will be moved to embedder by https://github.com/flutter/flutter/pull/28972 https://github.com/flutter/engine/pull/8064 and https://github.com/flutter/engine/pull/8088, but before that happens we'll have to patch them in framework.

## Related PR
https://github.com/flutter/flutter/pull/30457
Repository: rust
Issue: Move the compiler flags in the unstable book to the rustc book
Labels: A-frontend,C-enhancement,T-compiler,A-docs

# Description

Currently the unstable book contains three sections:

- Unstable compiler flags
- Unstable language features
- Unstable library features.

As has been mentioned in #41142 it might be better to move the unstable compiler flags to the rustc book. I see the following reasons why:

- Compiler flags are already mentioned [in the rustc book](https://doc.rust-lang.org/rustc/command-line-arguments.html) to keep documentation close together I believe it would make sense to keep all compiler flags close together. In order to avoid documentation duplication (which is hard to maintain), I believe placing them in the rustc book is more logical then not mentioning them in the rustc book and only having them in the unstable book.

- It seems that the unstable compiler flags in the unstable book are not maintained, unless there are only two unstable compiler flags (which I believe is not true since -Z lists many options).

I'd like to hear your opinion on this and, if you agree, under which section we should place this documentation. We could also aim to automize the generation of these nightly compiler flags?
Repository: flutter
Issue: Make IgnorePointer more customizable
Labels: platform-ios,framework,a: fidelity,c: proposal,P2,team-ios,triaged-ios

We wrap the entire scrollable's child in an IgnorePointer which is the right behavior on Android. But for iOS, even though the large title nav bar moves with the scrollable, it's not 'part of the scrollable'. 

Vertical drag gestures on the nav bar doesn't apply to the scrollable and the contents of the nav bar should be tappable even while scrolling. 

Create a new PointerFilter widget which always traverses its children for hit test when tapped. 

The descendent tree may include a FilteredPointer widget which itself would both hit test its own children, and also run a predicate function. If both passes, it re-wraps its descendents' hit test entry with a filtered hit test entry. 

The parent PointerFilter's render object, as it processes the children's hit test result, only unpacks the filtered hit test entries and sends that back up to its parents.
Repository: three.js
Issue: Non POT ImageBitmap texture can be upside down
Labels: Bug

##### Description of the problem

Non POT `ImageBitmap` texture can be upside down.

Demo: https://jsfiddle.net/7do6um2f/ (Use Chrome)

Non POT image can be resized to POT `canvas` in `WebGLRenderer(WebGLTexture)`. If original image is `ImageBitmap` and `texture.flipY` is `true`, `texture` will be upside down.

This is from the difference of `ImageBitmap` API from others. `ImageBitmap` requires `flipY` on bitmap creation while others requires on uploading data to GPU (= `texture.flipY`).

`texture.flipY` used on uploading data to GPU is ignored for `ImageBItmap`. But if non POT `ImageBitmap` is converted to `canvas`, `texture.flipY` will have an effect. So texture will be upside down.

`texture.flipY` has no effect for `ImageBitmap` so we should force it to `false` if texture's image is `ImageBitmap`?

API difference has another issue. (May be it isn't so serious tho.) `FlipY` and `premultiplyAlpha` is required on bitmap creation. `texture.flipY/premultiplyAlpha` used on uploading data to GPU are ignored for `ImageBitmap`.

So the following code has no effect for `ImageBitmap`, but the code has effect if `ImageBitmap` is resized and converted to `canvas`.

```
texture.premultiplyAlpha = ! texture.premultiplyAlpha;
texture.flipY = ! texture.flipY;
texture.needsUpdate = true;
```

##### Three.js version

- [x] Dev
- [ ] r103
- [ ] ...

##### Browser

- [x] All of them
- [ ] Chrome
- [ ] Firefox
- [ ] Internet Explorer

##### OS

- [x] All of them
- [ ] Windows
- [ ] macOS
- [ ] Linux
- [ ] Android
- [ ] iOS

##### Hardware Requirements (graphics card, VR Device, ...)
Repository: flutter
Issue: Write gesture test for GoogleMap#onTap once we have end to end testing
Labels: team,platform-android,platform-ios,a: platform-views,p: maps,package,team-ecosystem,P2,c: tech-debt,triaged-ecosystem

We don't support testing gestures on platform views yet.
Repository: TypeScript
Issue: Add JSDOC @module support for intellisense.
Labels: Suggestion,Awaiting More Feedback

## Search Terms

Intellisense jsdoc support for modules

## Suggestion

When adding `/** @module moduleName Module Description. */` to a module, then doing this:

    import * as myName from "./moduleName";

I think it makes sense, when importing the whole namespace, to include the jsdoc `@module` comment.

I also think that when pressing Ctrl+Space for code completion on `"./"` (to get a list of modules) should also show the module documentation. 

## Use Cases

Better support for module documentation. I'm developing some module libraries and it would be great to give end users a good experience with better intellisense documentation.

## Examples

_aModule.ts_

    `/** @module aModule Does something awesome. */`

_app.ts_

    import * as aModule from "./aModule";
    // (moduleName should both have the doc details)
    // ("./{*.*}" - all files in code completion should show the documentation as well)

## Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: flutter
Issue: _scaffoldKey.currentState.showBottomSheet with grey background overlay
Labels: framework,f: material design,a: quality,P2,workaround available,team-design,triaged-design

I'm using _scaffoldKey.currentState.showBottomSheet instead of showBottomSheet because it handle the keyboard better than showBottomSheet. But the problem is when I'm using _scaffoldKey.currentState.showBottomSheet, it not showing grey background overlay. It is possible to add the background overlay ?
Repository: frp
Issue: proposal - reload config file on save
Labels: proposal

## abstract
I'd like to contribute to this project by adding a new feature. I wish to support reloading the config files automatically on save.
## details
Users can enable this feature in `frpc.ini`
```
reload_on_save = true
```
and whenever the config file is written, a `reload` is automatically triggered.
### implementation details
I would use [https://github.com/fsnotify/fsnotify](fsnotify)(Cross-platform file system notifications for Go) to watch the config files and use `go's channel` to pass the information asynchronously.
## motivation
It's more natural for users (including me) to `ssh` to the client and change the config file. AdminUI is great but `ssh` is better.
A reload on save would be helpful.
Repository: three.js
Issue: Volumetric SpotLights 
Labels: Addons

Hey all,

I came across a cool and efficient implementation of [volumetrics for spotlights](http://john-chapman-graphics.blogspot.com/2013/01/good-enough-volumetrics-for-spotlights.html) -- and was able to achieve a pretty neat effect by using this approach paired with a noise texture and using multiple cones with decreasing radii. 

<img width="539" alt="Screen Shot 2019-04-04 at 1 10 29 PM" src="https://user-images.githubusercontent.com/17795014/55533610-0f3d9a00-56dc-11e9-86f8-3dd044ef189d.png">

I think this could be helpful for people, as it is the only one i've seen that does not require multiple render passes. I think it's not fundamental enough to add to the `THREE.Spotlight`, but probably better for an example.

Let me know!
Repository: react
Issue: [Concurrent] Safely disposing uncommitted objects
Labels: Type: Discussion

## How to safely keep a reference to uncommitted objects and dispose of them on unmount? 

For a MobX world, we are trying to [prepare for the Concurrent mode](https://github.com/mobxjs/mobx-react-lite/issues/53). In short, there is a [Reaction object being created](https://github.com/mobxjs/mobx-react-lite/blob/231be100e6ba458f40642adb9f0bc77aa4d366ce/src/useObserver.ts#L32
) to track for observables and it is stored within `useRef`.

The major problem is, that we can't just `useEffect` to create it in a safe way later. We need it to start tracking the observables on a first render otherwise we might miss some updates and cause inconsistent behavior.

We do have a [semi-working solution](https://github.com/mobxjs/mobx-react-lite/pull/121), basically, a custom made garbage collector based on `setTimeout`. However, it's unreliable as it can accidentally dispose of Reactions that are actually being used but weren't committed yet.

Would love to hear we are overlooking some obvious solution there.