sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: ConstructorParameters is not working for private constructors (and protected constructors)
Labels: Suggestion,Awaiting More Feedback

**TypeScript Version:**  3.4
**Search Terms:** ConstructorParameters, private constructor

**Code**

```ts
class Foo
{ public constructor(a: number, b: boolean, c: string) { } }

class Bar
{ private constructor(a: number, b: boolean, c: string) { } }

type FooCtorArgs = ConstructorParameters<typeof Foo>;
type BarCtorArgs = ConstructorParameters<typeof Bar>;
```

**Expected behavior:**
`BarCtorArgs` is `[number, boolean, string]`.

**Actual behavior:**
Error in line 8:
`Type 'typeof Bar' does not satisfy the constraint 'new (...args: any) => any'. Cannot assign a 'private' constructor type to a 'public' constructor type.`

**Playground Link:** https://www.typescriptlang.org/play/#src=class%20Foo%0D%0A%7B%20public%20constructor(a%3A%20number%2C%20b%3A%20boolean%2C%20c%3A%20string)%20%7B%20%7D%20%7D%0D%0A%0D%0Aclass%20Bar%0D%0A%7B%20private%20constructor(a%3A%20number%2C%20b%3A%20boolean%2C%20c%3A%20string)%20%7B%20%7D%20%7D%0D%0A%0D%0Atype%20FooCtorArgs%20%3D%20ConstructorParameters%3Ctypeof%20Foo%3E%3B%0D%0Atype%20BarCtorArgs%20%3D%20ConstructorParameters%3Ctypeof%20Bar%3E%3B

----

**Use Case**

Convenient factory pattern to mimic asynchronous object construction.
```ts
class Component
{
    public static async create(...args: ConstructorParameters<typeof Component>)
    {
        const component = new Component(...args);
        await component.initialize();
        return component;
    }

    private constructor(a: number, b: boolean, c: string)
    { /* stuff */ }

    private async initialize()
    { /* asynchronous setup */ }
}
```

**Ideas for Solution**

Allow visibility modifiers in interfaces. Yes, if you use an interface to outline the visible properties of an object to a user this makes no sense, but why not allow interfaces to be a flexible tool to specify internal rules of implementations?  I think this problem could be solved, if the `ConstructorParameters` type could be defined like the following:

```ts
type ConstructorParameters<T extends {private new (...args: any[]): any}> = T extends new (...args: infer P) => any ? P : never;
```

Which is of course no allowed at the moment.
Repository: go
Issue: cmd/cover: add number of uncovered lines
Labels: NeedsInvestigation,FeatureRequest,compiler/runtime

The coverage HTML file generated by `go tool cover -html=coverage.out` only displays the coverage *percentage* per package; as a result it's hard to identify, by just glancing at the list of packages and their coverage, where the coverage is lacking because small packages and giant packages are treated the same.
This is a feature request to add, in addition to the coverage percentage, the number of lines that are uncovered: this will enable to see what packages are big contributors to the lack of coverage.
Repository: rust
Issue: Missed NonZero optimization opportunity
Labels: A-LLVM,I-slow,E-needs-test,T-compiler

Godbolt [link](https://rust.godbolt.org/z/lc6Jl0)

When a `NonZeroUsize` is created through `new_unchecked` and wrapped in a `Some`, the optimizer does not recognize that the value is always `Some`. This can be fixed by adding a `std::intrinsics::assume(value != 0)` line before creating the NonZero type.

```rust
use std::num::NonZeroUsize;
use std::sync::atomic::AtomicUsize;
use std::sync::atomic::Ordering::Relaxed;

pub static X: AtomicUsize = AtomicUsize::new(1);

pub unsafe fn get() -> Option<NonZeroUsize> {
    let x = X.load(Relaxed);
    Some(NonZeroUsize::new_unchecked(x))
}

pub unsafe fn get2() -> usize {
    match get() {
        Some(x) => x.get(),
        None => unreachable!(), // not optimized out
    }
}
```

Lots of panicking code gets generated in this example.

Fixed by:
```rust
#![feature(core_intrinsics)]

use std::num::NonZeroUsize;
use std::sync::atomic::AtomicUsize;
use std::sync::atomic::Ordering::Relaxed;

pub static X: AtomicUsize = AtomicUsize::new(1);

pub unsafe fn get() -> Option<NonZeroUsize> {
    let x = X.load(Relaxed);
    std::intrinsics::assume(x != 0); // gets rid of the panicking code
    Some(NonZeroUsize::new_unchecked(x))
}

pub unsafe fn get2() -> usize {
    match get() {
        Some(x) => x.get(),
        None => unreachable!(), // optimized away
    }
}
```

I would guess that adding `assume` inside of `new_unchecked` would be ok, since it's already UB if it's not zero.

Related: #51346. Posted as a new issue, because it can be fixed without any LLVM pass changes.
Repository: create-react-app
Issue: react-scripts v3 via npm requires a peer of typescript@*
Labels: issue: needs investigation

The inclusion of @typescript-eslint/eslint-plugin and @typescript-eslint/parser in react-scripts means there are now a lot of warnings about typescript being an unmet peer dependency when part of a project not using typescript.

I understand it is just a warning and I know I can ignore it, but I still wanted to bring it up. So many warnings coming from this package makes it harder to pull out the warnings I do want to fix.
Repository: TypeScript
Issue: Refactoring to convert destructuring declaration to property accesses
Labels: Suggestion,Awaiting More Feedback,Domain: Refactorings

From https://github.com/Microsoft/vscode/issues/72502

**Feature request**
Add a refactoring that converts a destructured local to normal propery access:

```ts
const {x, y, z} = someObject;
console.log(x + y * z);
```

Would be converted to:

```ts
const newLocal = someObject;
console.log(newLocal.x + newLocal.y * newLocal.z);
```

We would want to also trigger a rename on `newLocal`, similar to how the extract refactorings work

This would be the inverse refactoring of #25946
Repository: go
Issue: cmd/compile: more fine-grained mechanism for escape analysis of assembly functions
Labels: NeedsFix,compiler/runtime

test/escape_runtime_atomic.go is failing on linux/arm. E.g., https://build.golang.org/log/b9cb939c683aed32bfa9ce69dbf44df63e291507
Repository: create-react-app
Issue: Style sheets referenced in XML or SVG
Labels: issue: needs investigation

<!--
  PLEASE READ THE FIRST SECTION :-)
-->

### Is this a bug report?

Maybe?


I'm trying to use an SVG which references an external CSS file. When the browser requests the external style sheet, create-react is redirecting the request to the index page with a status of 304. 

This does work correctly if I us an absolute path in the SVG, but a relative path is changed to /static/media/svg_style.css

Do I have an incorrect relative path in the SVG, or is this a bug?

```
<?xml-stylesheet type="text/css" href="../public/svg_style.css" ?>
<svg  xmlns="http://www.w3.org/2000/svg" viewBox="0 0 841.9 595.3">
    <g class='svgTestFill'>
        <path  d="M666.3 296.5c0-32.5-40.7-63.3-103.1-82.4 14.4-63.6 8-114.2-20.2-130.4-6.5-3.8-14.1-5.6-22.4-5.6v22.3c4.6 0..."/>
        <circle  cx="420.9" cy="296.5" r="45.7"/>
        <path   d="M520.5 78.1z"/>
    </g>
</svg>
```

This also works if I bring in the SVG as

`import {ReactComponent as Logo }from './logo.svg';`

but I'd like to know if it's possible to load css from the SVG without having to load the SVG as a react component.
Repository: opencv
Issue: Feature request: cv::erf() and cv::erfc()
Labels: feature,priority: low

- OpenCV => 3.4.5
- Operating System / Platform => Ubuntu 16.04
- Compiler => GCC 5.4.0

##### Detailed description
This is a feature request for two core functions/operations on arrays:
`void cv::erf(InputArray src, OutputArray dst)` and
`void cv::erfc(InputArray src, OutputArray dst)`

These would provide the element-wise [error function](http://www.cplusplus.com/reference/cmath/erf/) and the element-wise [complementary error-function](http://www.cplusplus.com/reference/cmath/erfc/).

Given fabs(X) standard deviations, erf returns the probability of observing a less extreme sample.

See also: [wikipedia](https://en.wikipedia.org/wiki/Error_function).

##### Steps to reproduce
N/A
Repository: vscode
Issue: index.js/index.ts file should show at top of file picker when searching for the name of the directory
Labels: feature-request,search,quick-open

- VSCode Version: Version 1.34.0-insider (1.34.0-insider) 6d5feae57959287fb116467f4eb6c7079571b466
- OS Version: MacOS 10.14.4

**Expected:** In TypeScript, index.js should show up at or near the top of the list, identically to if it was called `./MyComponent.ts`.  (Since index.ts is a shorthand for "whatever this directory is" - e.g. `MyComponent/index.ts` can be imported as just `./MyComponent`).

Note that there is currently no clean and quick way to open such a file since typing "index" is highly general and may bring up a huge list, and the dev doesn't know to type both the component name and index because it's not clear by looking at the import line that the module is being imported from a file named "index.ts".

**Actual:** File often appears well down the list of choices, including below items that are seldom if ever selected.  Example typing "regi" and wanting to open "registerLoginRoutes/index.ts":

<img width="592" alt="image" src="https://user-images.githubusercontent.com/19214773/56315943-b24fd400-611e-11e9-9eb0-8d9c1047dd4a.png">

**Steps to Reproduce:**

1. Create an index.ts file within a directory
2. Cmd+p to open file search box
3. Start typing the name of the directory

Does this issue occur when all extensions are disabled?: Yes
Repository: godot
Issue: Can't access rotation and transform in Node2Ds and call functions on Transform2Ds
Labels: bug,confirmed,usability,topic:visualscript

In VisualScript you can only get access to members that show up in the inspector, which means that rotation (not rotation_degrees) and transform members of Node2D are inaccessible. Furthermore, you can't call functions on a Transform2D object as you would with others, you have to search for Transform in the node search to get a `Transform Do X` node. This is the same with all basic types.

Why does the `Basic Type` call mode even exist?
![image](https://user-images.githubusercontent.com/28286961/56317822-fca47580-615d-11e9-94e2-b3dc9db58127.png)
Repository: godot
Issue: WorldEnvironment Glow not working when background is transparent
Labels: discussion,topic:rendering,confirmed,topic:3d

**Godot version:**
3.1


**OS/device including version:**
Linux 5.0.5-1-MANJARO
GPU: AMD Radeon R7 260X using AMDGPU driver.

**Issue description:**
When setting the viewport to have a transparent background, the Glow effect from the WorldEnvironment gets disabled (Possibly other effects to, haven't tested).

**Steps to reproduce:**
1. Create a scene with a bright object and a WorldEnvironment with Glow enabled.
2. Make the background transparent using `get_root().set_transparent_background(true)`

**Minimal reproduction project:**
[noglow.zip](https://github.com/godotengine/godot/files/3091614/noglow.zip)
Repository: opencv
Issue: Building OpenCV 4.1.0 / 3.4.6 with OpenGL, CUDA 10.1 and OpenCL
Labels: priority: low,category: build/install,category: gpu/cuda (contrib),category: ocl

<!--
If you have a question rather than reporting a bug please go to http://answers.opencv.org where you get much faster responses.
If you need further assistance please read [How To Contribute](https://github.com/opencv/opencv/wiki/How_to_contribute).

Please:

* Read the documentation to test with the latest developer build.
* Check if other person has already created the same issue to avoid duplicates. You can comment on it if there already is an issue.
* Try to be as detailed as possible in your report.
* Report only one problem per created issue.


This is a template helping you to create an issue which can be processed as quickly as possible. This is the bug reporting section for the OpenCV library.
-->

##### System information (version)
<!-- Example
- OpenCV => 3.1
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2015
-->

- OpenCV => 4.1.0 / 3.4.6
- Operating System / Platform => Windows 64 Bit
- Compiler =>Visual Studio 2019

##### Detailed description

Hi all, I have been unable to build OpenCV from source with support for CUDA 10.1, OpenCL and OpenGL. This issue applies to both the 4.1.0 and 3.4.6 versions of OpenCV. There seems to be an issue with a sharing function between OpenCL and OpenGL namely clGetGLContextInfoKHR.

I need to develop an application similar to the video_reader.cpp sample thus I require all three modules to be supported.


*Snippets*

7>C:\opencv\opencv41\modules\core\src\opengl.cpp(1640): warning C4459: declaration of 'clGetGLContextInfoKHR_pfn' hides global declaration

7>C:\opencv\opencv41\modules\core\include\opencv2\core\opencl\runtime\autogenerated/opencl_gl.hpp(58): note: see declaration of 'clGetGLContextInfoKHR_pfn' (compiling source file C:\opencv\opencv41\modules\core\src\opengl.cpp)

7>opencl_core.obj : error LNK2001: unresolved external symbol clGetGLContextInfoKHR

7>C:\opencv\install\opencv\bin\Debug\opencv_core410d.dll : fatal error LNK1120: 1 unresolved externals


##### Steps to reproduce

Build OpenCV 4.1.0 / 3.4.6 using CMake 3.14.1
Compiler: Visual Studio 16 2019 x64
Options:
WITH_CUDA
WITH_OPENCL
WITH_OPENGL
Repository: rust
Issue: Generators should implement either Iterator or IntoIterator.
Labels: T-lang,T-libs-api,C-feature-request,A-coroutines,A-iterators

Generators (currently unstable) are used as an implementation detail for async/await support in rust, but they can also be useful for writing Iterators and similar.

If you want to turn a Generator into an Iterator, you must wrap it in a new type, but it'd be useful to implement Iterator directory on Generator.

Here's an example of how that could work:

```rust
impl<G> Iterator for G where G: Generator<Return = ()> + Unpin {
    type Item = G::Yield;
    
    fn next(&mut self) -> Option<Self::Item> {
        match Pin::new(&mut self.generator).resume() {
            GeneratorState::Yielded(item) => Some(item),
            GeneratorState::Complete(_) => None,
        }
    }
}
```
Repository: vue-element-admin
Issue: 编译的时候element的chunk出现了两处for(let i...)，已经加了babel
Labels: need repro :mag_right:

<!--
    注意：为更好的解决你的问题，请参考模板提供完整信息，准确描述问题，信息不全的 issue 将被关闭。

    Note: In order to better solve your problem, please refer to the template to provide complete information, accurately describe the problem, and the incomplete information issue will be closed.
-->


## Bug report（问题描述）
编译后的代码除了这两处都正常转换成for(var i...)，就这两处比较特殊，目前不明白为什么会这样
#### Steps to reproduce（问题复现步骤）
<!--
1. [xxx]
2. [xxx]
3. [xxxx]
-->

#### Screenshot or Gif（截图或动态图）
编译异常的代码片段：
"6rf1":function(e,t,i){"use strict";t.a=function(e){for(let t=1,i=arguments.length;t<i;t++){let i=arguments[t]||{};for(let t in i)if(i.hasOwnProperty(t)){let n=i[t];void 0!==n&&(e[t]=n)}}return e}}

#### Link to minimal reproduction（最小可在线还原demo）

<!--
Please only use Codepen, JSFiddle, CodeSandbox or a github repo
-->

#### Other relevant information（格外信息）
- Your OS: 
- Node.js version: 10.14.2
- vue-element-admin version:3.10.0
Repository: three.js
Issue: Editor：could the editor add Group/Ungroup function ？ use ctrl + mouse-left select meshes。
Labels: Enhancement,Editor
Repository: pytorch
Issue: [jit] requires_grad in JIT constructor/factories
Labels: high priority,triage review,oncall: jit

Something like:
```
        t = torch.ones(2, requires_grad=True)
```
fails with:
```
RuntimeError:
arguments for call are not valid:

  for operator aten::ones(int[] size, *, Tensor out) -> Tensor:
  argument out not provided.
  @torch.jit.script
  def foo():
      t = torch.ones(2, requires_grad=True)
          ~~~~~~~~~~ <--- HERE

  for operator aten::ones(int[] size, *, int? dtype=<default>, int? layout=<default>, Device? device=<default
>) -> Tensor:
  keyword argument requires_grad unknown
for call at:
@torch.jit.script
def foo():
    t = torch.ones(2, requires_grad=True)
        ~~~~~~~~~~ <--- HERE
```

We also can't do:
```
@torch.jit.script
def foo():
    t = torch.ones(2)
    t.requires_grad_(True)
```

I assume this had to do with lack of mutability annotations before? @zdevito are there any other difficulties you could see?

cc @ezyang @gchanan @zou3519 @bdhirsh @jbschlosser @gmagogsfm @suo
Repository: vscode
Issue: Support restart of remote EH to avoid window reloads
Labels: feature-request,extension-host

It looks like we added code to the workbench to reload the window in certain cases when entering a workspace or folders change:

https://github.com/Microsoft/vscode/blob/053a32e2bbc354af2b19cb40758f615cefcb714e/src/vs/workbench/services/workspace/electron-browser/workspaceEditingService.ts#L366

https://github.com/Microsoft/vscode/blob/053a32e2bbc354af2b19cb40758f615cefcb714e/src/vs/workbench/contrib/relauncher/electron-browser/relauncher.contribution.ts#L163

There should only be very few reasons why this is needed (e.g. a global settings change) and in that case we tell the user at least and offer to cancel that.

Here we just reload without warning (which is quite horrible if e.g. the user has decided to disable hot-exit and then needs to deal with untitled/unsaved buffers).
Repository: ant-design
Issue: Layout.Sider should be allowed to used classes to solve width problems in responsive layouts instead of specifying width attribute
Labels: Inactive

### What problem does this feature solve?
Currently the the [Layout.Sider](https://ant.design/components/layout/) allows specifying both - **className** and **width**. **Width** is used to manually set the style width of the Sider's `<Div/>` div component in expanded mode.

This works beautifully in most of the cases however if you want to have responsive design and control the width of the expanded state via  **className** and `@media` CSS selector - you will fail to. This is because because the collapse/expand mechanism always sets width that overrides the set *className* that would otherwise the CSS `@media` selector.
The problem in couple of examples.  If I set *width* to:
- *320*. It will always set the width to 320 px in expanded mode no matter the width of the screen. For portrait mode   and mobile devices it makes sense to take 100% of the width and push the content below.
- *null*. It will set the width 0 px in expanded mode, which breaks the visualisation.
- *undefined*. It will set the width  to 200 px, which will lead to case #1


### What does the proposed API look like?
I would like to have additional property like  `disableCollapseWidthControl={true}`  that will not control the width style of the Sider's   `<Div/>`  , so could fine tune the siders width in various positions.

### Related links
Other people having the same problem [here on StackOverflow](https://stackoverflow.com/questions/50251476/how-to-avoid-content-reflow-with-ant-designs-responsive-sider?rq=1)
<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: rust
Issue: Implementation of Trait for different type of Fn doesn't work
Labels: A-trait-system,A-closures,T-lang

Implementing a Trait for a type T (where T is a function with a given a signature) and then trying to implement the same trait for another type T (where T is a function with a different signature) doesn't compile.

I tried this code:
```Rust
trait MyTrait {}

impl<F> MyTrait for F where F: Fn(u32) -> u32 {}

impl<F> MyTrait for F where F: Fn(u32, u32) -> u32 {}
```

When compiling this code I get :
```
error[E0119]: conflicting implementations of trait `MyTrait`:
 --> src/main.rs:5:1
  |
3 | impl<F> MyTrait for F where F: Fn(u32) -> u32 {}
  | ------------------------------------------------------ first implementation here
4 | 
5 | impl<F> MyTrait for F where F: Fn(u32, u32) -> u32 {}
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation
```

What I would expect is that T here represent in the first implementation either a fn(u32) -> u32 or a closure the implement Fn(u32) -> u32, then in the second implementation, T would be either a fn(u32, u32) -> u32 or a closure the implement Fn(u32, u32) -> u32.

## Meta

rustc 1.34.0 (91856ed52 2019-04-10)
binary: rustc
commit-hash: 91856ed52c58aa5ba66a015354d1cc69e9779bdf
commit-date: 2019-04-10
host: x86_64-apple-darwin
release: 1.34.0
LLVM version: 8.0
Repository: pytorch
Issue: Massive memory overhead over NumPy
Labels: module: internals,module: memory usage,triaged

## 🐛 Bug

The memory usage comparison between the same data structures implemented with different backends (PyTorch tensors and NumPy arrays) shows over 4x higher usage when using PyTorch. Data structure consists of a list containing 5kk small tensors/arrays.

![](https://imgur.com/RtznFzw.png)

## To Reproduce

Use this Gist: https://gist.github.com/iamhatesz/3ef34254febe482aa48e3e489f89b07b

## Expected behavior

The memory usage for both data structures should be similar.

## Environment

 - PyTorch Version (e.g., 1.0): 1.0.1
 - OS (e.g., Linux): Windows 10
 - How you installed PyTorch (`conda`, `pip`, source): pip
 - Build command you used (if compiling from source): -
 - Python version: 3.7.1
 - CUDA/cuDNN version: -
 - GPU models and configuration: -
 - Any other relevant information: -

## Additional context

none
Repository: storybook
Issue: Ability to specify version in AboutScreen
Labels: feature request,ui,has workaround

**Is your feature request related to a problem? Please describe.**
We build a static storybook to deploy for our designer to review and then also for reviewing code changes before approval. Currently, it's not possible to see when the storybook was built and what commit was used to build it.

**Describe the solution you'd like**
Add support for loading a `version.json` file whose contents are displayed in the `AboutScreen`.

**Describe alternatives you've considered**
Anything that allows the user to see the build date and other details about the build.

**Are you able to assist bring the feature to reality?**
possibly. I've never worked with the Storybook code base before, but this should be a simple change that I might be able to work with.

**Additional context**
A simple display of key/value pairs from the `version.json` is all that I'm looking for.
Repository: react-native
Issue: [a11y] Nested accessibility items are not respected on iOS
Labels: Platform: iOS,Ran Commands,Accessibility,Bug,Accessibility Team - Evaluated,Never gets stale

React Native apps often have many UI components that are touchable but also contain nested elements that are also touchable. For example, an entire list row may be touchable as a primary navigation option, but it might also have an auxiliary button nested inside of it for taking a specific action, like delete or save. 
  
Currently, if the touchable wrapper for the auxiliary button as well as the row container are properly tagged with accessibility props and accessibility labels it works fine on Android but on iOS, the nested 'save/delete' button is not selectable by VoiceOver. On Android, both will be accessible when accessibility features are enabled.

The current workaround in user-land is to make some janky hierachry where the aux button is a sibling of its visual container, which often breaks encapsulation and is generally a pain. 
  
There are a couple ways we might be able to work around this at the framework level:  
  
1) use UIAccessibilityContainer protocol  
2) set the accessibilityElements property on the parent  
  
Those approaches are detailed a bit more here:  
https://stackoverflow.com/questions/38849389/voiceover-parent-and-child-views-as-accessibility-elements  
  
Looks like flutter had this same issue and fixed it here with UIAccessibilityContainer: https://github.com/flutter/engine/pull/4110

Tracked internally with T34121499