sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Allow specifying interface implements clauses for the static side of classes
Labels: Suggestion,In Discussion

## Search Terms

class static side syntax interface type expression

## Suggestion

Currently, you can only specify the static side interface of a class with a declaration. From [the handbook](https://www.typescriptlang.org/docs/handbook/interfaces.html#difference-between-the-static-and-instance-sides-of-classes):

```ts
const Clock: ClockConstructor = class Clock implements ClockInterface {
  constructor(h: number, m: number) {}
  tick() {
      console.log("beep beep");
  }
}
```

When I first wanted to do this (before looking at the docs), I tried to do it in this fashion:

```ts
class Clock: ClockConstructor implements ClockInterface {
  ...
}
```

And I was surprised to see that it didn't work. My proposal is to make this a valid syntax as it's more intuitive and understandable.

I believe that forcing class expressions conflicts with TypeScript's design goals:

>5. Produce a language that is composable and easy to reason about.

Why use a class expression when there is no need for it? Why change your actual JavaScript logic for something that exists only in TypeScript and not in your production code.

## Use Cases

Anywhere you need to set the interface of the static side of a class without having a need to specify it as an expression.

## Examples

Take the example from the playground:

```ts
interface ClockConstructor {
  new (hour: number, minute: number);
}

interface ClockInterface {
  tick();
}

class Clock: ClockConstructor implements ClockInterface {
  constructor(h: number, m: number) {}
  tick() {
      console.log("beep beep");
  }
}
```

## 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: rust
Issue: Occasional "cannot move out" error (E0505) when adding a match guard
Labels: C-enhancement,A-borrow-checker,T-compiler,A-NLL,NLL-polonius

Given the following snippet:
```rust
struct State {
    val: u8,
    xy: bool,
}

struct Test {
    vec: Vec<State>,
}

impl Test {
    fn new() -> Self {
        Test { vec: Vec::new() }
    }
    
    fn get_mut(&mut self, id: usize) -> Result<&mut u8, Option<&mut State>> {
        match self.vec.get_mut(id) {
            Some(State { ref mut val, ref xy }) /*if true*/ => Ok(val),
            other => Err(other),
        }
    }
}
```
This compiles just fine. Now uncomment the _if true_ match guard and compile fails:
```
error[E0505]: cannot move out of `_` because it is borrowed
  --> src/lib.rs:18:13
   |
15 |     fn get_mut(&mut self, id: usize) -> Result<&mut u8, Option<&mut State>> {
   |                - let's call the lifetime of this reference `'1`
16 |         match self.vec.get_mut(id) {
17 |             Some(State { ref mut val, ref xy }) if true => Ok(val),
   |                          -----------                       ------- returning this value requires that borrow lasts for `'1`
   |                          |
   |                          borrow of value occurs here
18 |             other => Err(other),
   |             ^^^^^ move out of value occurs here
```
Why does the insignificant match guard affect the borrowck?

Tested both on stable 1.38.0 and 1.40.0-nightly (032a53a06 2019-10-03).
Repository: opencv
Issue: Support I/O functionality through std::istream/ostream
Labels: evolution

## OE-XX Support I/O functionality through std::istream/ostream
* Status: Draft

## Introduction and Rationale

OpenCV library includes functionality for I/O. Currently it is file-name based.

Current approach has several issues:
- lack of cross-platform Unicode symbols support (only UTF-8 file paths may work)
- it requires files (no direct access to Java packed resources from .JAR/.AAR) or has workarounds like `imdecode()`



## Proposed solutions

Extend functionality of existed I/O functions and their internal backends:
- imread/imwrite
- FileStorage
- DNN's network reader

Expected changes (in case of data reading):
- C++: add overload which accepts `std::istream`
- Python: add wrapper/implementation over `std::istream` for Python-based file/stream handles (like open() calls)
- Java: add wrapper/implementation over `std::istream` for Java InputStream / ByteBuffer / etc

Handling of Unicode files paths responsibility would be moved on the side of C++ standard library (through robust `std::wstring` or `std::filesystem::path`).
Similar idea is for Python/Java code.

Extra: Python/Java may support network(HTTP) input streams.

In-memory handling would be improved too (through `std::istream` wrapper).



## Possible issues

Not all image readers backends may support new feature (depends on 3rdparty).



## Impact on existing code, compatibility

No impact is expected on existing C++ code.



## References

Issues/PRs about I/O: #4292 #5631+[comment](https://github.com/opencv/opencv/issues/5631#issuecomment-291991001) #13368(PR)
Repository: rust
Issue: Adding imports (or even crates) to suggestions
Labels: C-enhancement,T-compiler,A-suggestion-diagnostics,D-diagnostic-infra

Sometimes we (as in Rust errors or clippy lints) may suggest things that require adding a `use` somewhere, or even adding a crate to the dependencies.

I'd like to see support for this from the compiler, e.g. extend `Suggestion` with a structured way of adding or removing an import or crate dependency.
Repository: angular
Issue: elements: too many change detection runs during initialization
Labels: type: bug/fix,area: performance,area: elements,state: confirmed,P4

# 🐞 bug report

### Affected Package

The issue is caused by package @angular/elements.


### Is this a regression?

No.


### Description

During custom element initialization (i.e. [initializeComponent()][1]), the default `NgElementStrategy`, [ComponentNgElementStrategy][2], (transitively) may call [setInputValue()][3], which in turn calls [scheduleDetectChanges()][4]. Right after, `initializeComponent()` calls [detectChanges()][5].

However, despite CD being run synchronously after `setInputValue()`, the scheduled, asynchronous CD (scheduled inside `setInputValue()`) will still run.

This results in two CDs per Angular custom element instance, which can negatively affect initial page loads or route transitions for pages/routes with many custom elements. (This is the case for example in https://angular.io/guide/router, which has ~200 custom elements.)

**Possible solution:**
I think it would be reasonable to cancel scheduled CD, if CD is triggered earlier than scheduled.

(See the reproduction below for a demo of the fix.)


### 🔬 Minimal Reproduction

https://stackblitz.com/edit/ngelements-issue-33059?file=src/app/app.component.ts


### Anything else relevant?

Related issues: #23813, #33060


[1]: https://github.com/angular/angular/blob/9f0c549bc/packages/elements/src/component-factory-strategy.ts#L146-L162
[2]: https://github.com/angular/angular/blob/9f0c549bc/packages/elements/src/component-factory-strategy.ts#L45
[3]: https://github.com/angular/angular/blob/9f0c549bc/packages/elements/src/component-factory-strategy.ts#L168
[4]: https://github.com/angular/angular/blob/9f0c549bc/packages/elements/src/component-factory-strategy.ts#L139
[5]: https://github.com/angular/angular/blob/9f0c549bc/packages/elements/src/component-factory-strategy.ts#L158
Repository: angular
Issue: elements: no coalescing of change detection invocations across instances
Labels: type: bug/fix,area: performance,area: elements,state: confirmed,P4

# 🐞 bug report

### Affected Package

The issue is caused by package @angular/elements.


### Is this a regression?

No.


### Description

While Angular custom elements do coalesce change detection invocations per element instance (see [scheduleDetectChanges()][1]), there is no coalescing across other instances of the same element or other elements (even for those on the same injector or component tree.

This results in too many CDs on pages/routes with many custom elements and can negatively affect performance. (This is the case for example in https://angular.io/guide/router, which has ~200 custom elements.)


### Anything else relevant?

Related issues: #23813, #33059

_EDIT:_
_Similar issue with useful context (closed in favor of this one): #23813_
_PR (that would at least cover some usecases): #23885_

[1]: https://github.com/angular/angular/blob/9f0c549bc/packages/elements/src/component-factory-strategy.ts#L206-L215
Repository: pytorch
Issue: Unify warning logging mechanism
Labels: module: internals,triaged,enhancement,better-engineering

We have `TORCH_WARN` macro, and glog also provides `LOG(WARNING)` macro.

To recount the differences between these macros:

* `TORCH_WARN` integrates with Python warning mechanism, when the relevant C++ code was invoked from Python. Warnings reported this way can be handled using regular facilities for capturing and aggregating warnings; e.g., in some tests, we use this to ensure that a warning is actually reported. When Python is not involved, we simply print warnings to stderr
* `LOG(WARNING)` integrates with glog, which means that its visibility can be toggled via standard command line flags from the glog/gflags ecosystem. glog based logging is the standard logging mechanism in Facebook and integrates with Facebook logging infrastructure.

I believe an ideal warning mechanism combines the best parts of both of these systems (integration with Python, and integration with glog infrastructure). We should unify these mechanisms
Repository: flutter
Issue: Support golden widget tests in Fuchsia tree
Labels: a: tests,customer: fuchsia,framework,dependency: fuchsia,platform-fuchsia,P2,team-framework,triaged-framework
Repository: create-react-app
Issue: Make font size of error overlay configurable
Labels: issue: proposal

### Is your proposal related to a problem?

<!--
  Provide a clear and concise description of what the problem is.
  For example, "I'm always frustrated when..."
-->

[The error overlay font size is too small ](https://github.com/facebook/create-react-app/blob/68f95d41334f65fd1dc12c329fda12c719e18b3f/packages/react-dev-utils/webpackHotDevClient.js#L72) for some people

### Describe the solution you'd like

<!--
  Provide a clear and concise description of what you want to happen.
-->

 It would be good if it could be configurable

### Describe alternatives you've considered

<!--
  Let us know about other solutions you've tried or researched.
-->

None

### Additional context

<!--
  Is there anything else you can add about the proposal?
  You might want to link to related issues here, if you haven't already.
-->

None
Repository: opencv
Issue: cv::magnitudeSqr and cv::magnitude(InputArray xy,...) ?
Labels: feature,category: core

OpenCV 4.1:

cv::cuda::magnitude... functions have more options than cv::magnitude..., because :
-there is a cv::cuda::magnitudeSqr()
-cv::cuda::magnitude(...) can accept x and y as interleaved rather than two planes.

-cv::magnitudeSqr() would require the use of ippsPowerSpectr() rather than ippsMagnitude()
-cv::magnitude(xy) would require the use of "ipp...32/64fc" rather than "ipp...32/64f" functions
-the biggest part of the work would be in ocl/hal to support new functions like magnitudeSqr() magnitude32c().

Considering that work, would it be accepted as a pull request, or would it be rejected as not useful enough to justify more code ?
Repository: pytorch
Issue: scatter_add allows index tensor that doesn't match input size in forward pass but fails on backward pass
Labels: high priority,module: crash,triaged

## 🐛 Bug

If you have an index tensor whose shape does not match the other tensor's shape but is broadcast-compatible, the forward pass of `torch.scatter_add()` will succeed but the backward pass will throw a RuntimeError saying that the shapes do not match exactly on the non-indexed dimension.

## To Reproduce

Repro script:
```python
import torch as th

src = th.zeros(8, 105238, 3)
ind = th.zeros(8, 626304, 1).long()
ofs = th.zeros(8, 626304, 3)
src.requires_grad_(True)
ofs.requires_grad_(True)

out = src.scatter_add(1, ind, ofs)
#out = src.scatter_add(1, ind.expand(-1, -1, 3), ofs) <<< this line works

l = out.sum()
l.backward()
```

Exception (CPU):
```
RuntimeError: Expected tensor [8, 626304, 1], src [8, 105238, 3] and index [8, 626304, 1] to have the same size ap
art from dimension 1
```

Exception (CUDA):
```
RuntimeError: invalid argument 2: Input tensor must have same size as output tensor apart from the specified dimen
sion at /mnt/home/gbschwartz/pytorch/aten/src/THC/generic/THCTensorScatterGather.cu:27
```

## Expected behavior

No exceptions thrown.

## Environment

 - PyTorch Version (e.g., 1.0): 1.2.0
 - OS (e.g., Linux): linux
 - How you installed PyTorch (`conda`, `pip`, source): conda
 - Build command you used (if compiling from source):
 - Python version: 3.7
 - CUDA/cuDNN version: 9.0 / 7.6.0
 - GPU models and configuration: V100

cc @ezyang @gchanan @zou3519
Repository: pytorch
Issue: [feature request] [dataloader] Pad variable-sized tensors in default_collate
Labels: module: dataloader,triaged,enhancement

It's more and more frequent to deal with variable-sized inputs (with max size being determined at collation time). Currently one deals with those by writing a custom `collate_fn`, but it adds some boilerplate.

I propose to evaluate the idea of putting this into the default `collate_fn`. Some ideas:
0) frequent case is 1d sequences and 2d images
1) allow `torch.stack` / `torch.cat` deal with padding variable-sized inputs
2) deal with padding at `collate_fn`
3) convert default_collate to Collate class / module with `__call__` interface. Then padding options can be put as arguments to the constructor. 
5. One useful padding config is padding sequence size to multiples of some size like 16/64/128 (better for pytorch allocator)

cc @SsnL
Repository: godot
Issue: CLI debugger (--debug) does not work with standalone scripts (--script)
Labels: bug,topic:core,confirmed

**Godot version:**
3.2.alpha1.official

**OS/device including version:**
Mac OS X Mojave

**Issue description:**
As per documentation from godot -h:
```
Debug options:
  -d, --debug                      Debug (local stdout debugger).
  -b, --breakpoints                Breakpoint list as source::line comma-separated pairs, no spaces (use %20 instead).
```
I am trying to use the -b and -d options from the command line, but it's as if nothing happens.
`godot -s somescript.gd --debug --breakpoints somescript.gd::3`

**Steps to reproduce:**
Create `somescript.gd`  script and execute above CLI command.

```gdscript
extends SceneTree
var somevar = 20
var foo1='abcd'
func _init():
	print(foo1)
```
Repository: pytorch
Issue: torch.distributed.autograd.backward() should populate .grad field on Tensors by default.
Labels: module: autograd,triaged,module: rpc

In the implementation for the backward pass in https://github.com/pytorch/pytorch/pull/27022, we accumulate the gradients in the autograd context by default. In order to have symmetry with `torch.autograd.backwards`, the API should be something like this:

```
torch.distributed.autograd.backward(tensors, grads, accumulate_grad_on_tensors = True)
```

When `accumulate_grad_on_tensors` is set to False, we accumulate the grads on the autograd context, otherwise we accumulate the grads on the .grad field.

cc @ezyang @SsnL @albanD @zou3519 @gqchen @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @aazzolini @xush6528
Repository: pytorch
Issue: Test re-entrant backward works with torch.distributed.autograd.backward()
Labels: module: autograd,triaged,module: rpc

Need to add a unit test to ensure re-entrant backward works with the distributed backward pass.

cc @ezyang @SsnL @albanD @zou3519 @gqchen @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @aazzolini @xush6528
Repository: pytorch
Issue: 🚀 Graceful RPCAgent termination in multi-driver scenario
Labels: high priority,triaged,better-engineering,module: rpc

# Problem

* Currently, `sync()`, `join()` interface is implemented in and only for `ProcessGroupAgent`.
* Other `RPCAgent`s also need it, but it shouldn’t implement it again.
* What stops the current solution from being reused is that `ProcessGroupAgent` uses collective communication to achieve it, while by default, other `RPCAgent`s don't have this facility.

# Proposal

* Problem 1
    * Statement
        * Currently, we ask users to call `init_process_group` before calling `init_model_parallel`. One user error could be that the user passes 2 different init_methods, resulting 2 different node groups. One for c10d data parallel default process group and the other for model parallel node group.
    * Solution
        * We create a model parallel default process group inside of `init_model_parallel` for users. Notice, the default process group here is a model-parallel scope default. In order to make naming scopes of data parallelism and model parallelism distinct. We decide to do the following refactoring.
            * Move `torch.distributed.*`, like `torch.distributed.barrier`, to `torch.distributed.data_parallel.*`.
            * Keep `torch.distributed.rpc.*` in case data parallel want to use RPC in the future.
            * Create `torch.distributed.model_parallel.*`. Inside it, it could import `torch.distributed.rpc` to use.
        * The `init_model_parallel` API initializes a model parallel default process group for users. Users can call `torch.distributed.model_parallel.barrier` later.
* Problem 2
    * Statement
        * Is `ProcessGroupAgent::sync` still needed? It essentially called `barrier()` twice. Shouldn’t `barrier` + `drain` enough to gracefully shutdown symmetric workers (i.e. workers are not driven by a master)?
    * Solution
        * Remove `sync`, `join` interface in `RpcAgent`. For user cases where there is no master in charge, make every worker call `barrier` + `drain` at the end, before shutting down local `RPCAgent`.



cc @ezyang @gchanan @zou3519 @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @rohan-varma @xush6528 @jjlilley @osalpekar
Repository: pytorch
Issue: Avoid RTTI in DistEngine
Labels: triaged,better-engineering,module: rpc

As mentioned in the comment here: https://github.com/pytorch/pytorch/pull/27022#discussion_r332294507, we should try and avoid RTTI in DistEngine. 

cc @ezyang @gchanan @zou3519 @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @rohan-varma @xush6528
Repository: rust
Issue: Verify trait impls’ signatures before checking dyn compatibility
Labels: C-enhancement,A-diagnostics,A-trait-system,T-compiler,A-trait-objects,A-dyn-compatibility

Given a code like this:

```rust
mod obj_unsafe {
    pub trait Serialize {
        fn serialize<T>(&self, t: T);
    }
}

mod obj_safe {
    pub trait Serialize {
        fn serialize(&self);
    }
}

trait DoSomething {
    fn foo(&self) -> Box<dyn obj_safe::Serialize>;
}

impl DoSomething for () {
    fn foo(&self) -> Box<dyn obj_unsafe::Serialize> {
        unimplemented!()
    }
}
```

We emit an error like this:

```
error[E0038]: the trait `obj_unsafe::Serialize` cannot be made into an object
  --> src/lib.rs:18:5
   |
18 |     fn foo(&self) -> Box<dyn obj_unsafe::Serialize> {
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `obj_unsafe::Serialize` cannot be made into an object
   |
   = note: method `serialize` has generic type parameters
```

---

This error is something that was encountered by someone who read documentation and saw they needed to implement a method returning `Box<dyn Serialize>`, An obvious assumption is that this refers to `serde::Serialize`, so that’s what they specified in their return type when implementing `DoSomething`.

The error they got does not point them at the problem at all. Sure, `Serialize` from serde is not object safe, but that is irrelevant, because they are trying to make an object of an entirely wrong trait in the first place.

Instead we should be emitting `error[E0053]: method `foo` has an incompatible type for trait` first.
Repository: PowerToys
Issue: [FancyZones] Map keyboard shortcuts to zones directly to zone windows quicker
Labels: Idea-Enhancement,FancyZones-Dragging&UI,FancyZones-Hotkeys,Product-FancyZones

I want to hit a user definable shortcut and the focused window should resize to the zone which is mapped to this shortcut . 

I would map some keys e.g. on the numpad to my e.g. 4 zones. Now I can just press one of these keys and my windows is resized to the chosen zone. 

Cycling with WIN + arrow is nice, but just hitting a key is a lot faster!
Repository: PowerToys
Issue: PowerToys: very fast switching between apps with Alt + Tab should not show the window overview (like on linux/mac) to be less distracting
Labels: Idea-New PowerToy

In Windows Alt+Tab shows immediately the overview. So regardless how fast you switch between apps, you see the overview flickering a short moment. 

In macOS and Ubuntu the overview is only shown when you don't release the key very fast. Please have a look at an actual machine and get a feeling how it works there. 

1. So with keeping the Alt key pressed, you get the task overview after 200ms (value is just a guess, but it's very quick and you don't notice the delay when you really want to see the overview).

2. But when releasing the keys instantly, you don't see the task overview at all, which makes fast switching between apps a lot less visually distracting.

It would be so great when I could have this in Windows too. Maybe an idea for a PowerToys tool?