sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: [feature] class properties that are "readonly in public, writable in private" or other permutations
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 help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ, especially the "Common Feature Requests" section: https://github.com/Microsoft/TypeScript/wiki/FAQ

-->

## Search Terms

[typescript readonly on the outside writable on the inside](https://www.google.com/search?q=typescript%20readonly%20on%20the%20outside%20writable%20on%20the%20inside&cad=h)

- https://stackoverflow.com/questions/46634876/how-can-i-change-a-readonly-property-in-typescript

## Suggestion

Some sort of syntax to describe `readonly on the outside, writeable on the inside` for a given property, so we can avoid making a getter just for this purpose (or using any of the convoluted options linked in that StackOverflow post).

## Use Cases

To make this pattern easier to express.

## Examples

instead of having to write

```ts
class Foo {
  private _foo = 123
  get foo() {
    return this._foo
  }

  changeIt() {
    this._foo = 456
  }
}

const f = new Foo
f.foo = 345 // ERROR
```

we would be able to write something shorter like

```ts
class Foo {
  publicread foo = 123

  changeIt() {
    this.foo = 456
  }
}

const f = new Foo
f.foo = 345 // ERROR
```

## 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: godot
Issue: Right-button menu for Scene-file nodes has a bigger offset than normal
Labels: enhancement,topic:editor,usability

**Godot version:** 3.2.1 (stable)

**OS/device including version:** ArchLinux

**Issue description:** When clicking with the right-button on a node added to the scene via a Scene file, the inspector menu that appears will have a weird offset (as shown in the images). This is probably caused by the toggle options "Editable Children" and "Load as Placeholder", as they show more distant to the option label than the rest of the icons.

This is a (very) minor UI bug and I couldn't found something similar happening somewhere else in Godot.

Normal Menu:
![normal](https://user-images.githubusercontent.com/7095429/77133195-fd661b80-6a40-11ea-8772-722b7e8eeb5e.png)

Weird Offset Menu:
![bugged](https://user-images.githubusercontent.com/7095429/77133193-fccd8500-6a40-11ea-9481-9620e7a6d94a.png)
Repository: scrcpy
Issue: Copy files from phone to PC
Labels: feature request

Is there any way to copy stuff from phone to pc like drag and drop feature. If not, please implement it. Thanks
Repository: node
Issue: Inspector pause at beginning of recently parsed function will crash
Labels: v8 engine,inspector

This is a bug upstream which started once we landed V8 8.1. Opening this issue to keep track of the upstream bug, so we remember to backport once it's fixed.

The bug is unlikely to affect users unless they are using the Inspector protocol to automatically pause a script. The bug happens when the inspector pauses right before a function parsed and compiled with CompileFuncionInContext (and potentially through other means) runs. We have two flaky tests because of this bug.

V8 minimal repro: https://chromium-review.googlesource.com/c/v8/v8/+/2080072
Upstream bug: https://bugs.chromium.org/p/v8/issues/detail?id=10287
First V8 commit with the issue (found with git bisect): https://chromium-review.googlesource.com/c/v8/v8/+/1903440
Repository: pytorch
Issue: tensorboard add_graph 's "operator_export_type"
Labels: module: tensorboard,oncall: visualization

## tensorboard add_graph 's "operator_export_type"

`torch.utils.tensorboard add_graph` have "operator_export_type"(kwargs) in torch 1.1
but now we can not use this kwargs in torch 1.2 and later? (or similar kwargs)

The remove is from  https://github.com/pytorch/pytorch/pull/23000

With "operator_export_type", we can draw ellegant graph, and this is very helpful for model visualization. 

@orionr Do you have plan to bring this kwarg back?

before (torch 1.1)
![0320162040-410x530](https://user-images.githubusercontent.com/15137588/77146857-013c8100-6ac7-11ea-9b0a-0b1a35a53ead.png)

now (torch 1.4)
![0320162030-869x314](https://user-images.githubusercontent.com/15137588/77146847-fe419080-6ac6-11ea-9fc6-17f7a2d6b9f4.png)
Repository: flutter
Issue: SizedBox height is ignored when child Image has BoxFit.fill In An AppBar
Labels: framework,f: material design,a: quality,a: images,has reproducible steps,found in release: 3.0,found in release: 3.1,team-design,triaged-design

I have wrap image by sizedBox and set height = 1 , also set height of image but image still get max height of appbar 
my code
```
AppBar(
          title: Text('My Favourite'),
          centerTitle: true,
          actions: <Widget>[
            Padding(
              padding: const EdgeInsets.only(right: 8.0),
              child: Image.asset(
                'assets/images/home_black.png',
                height: 25,
                width: 25,
                fit: BoxFit.fitWidth,
              ),
            ),
            Padding(
              padding: const EdgeInsets.only(right: 8.0),
              child: Image.asset(
                'assets/images/search_black.png',
                height: 25,
                width: 25,
                fit: BoxFit.fitWidth,
              ),
            ),
            SizedBox(
              height: 1,
              width: 25,
              child: Image.asset(
                'assets/images/user_black.png',
                height: 1,
                width: 25,
                fit: BoxFit.fill,
              ),
            ),
          ],
        )
```
<img width="285" alt="Screen Shot 2020-03-20 at 17 12 23" src="https://user-images.githubusercontent.com/52562340/77154345-14068400-6ace-11ea-96c8-7ee062ef45b6.png">
Repository: rust
Issue: rustc --crate-type flag should display valid values
Labels: E-easy,A-diagnostics,T-compiler,D-papercut,A-CLI

Hello,

When we provide wrong value for the `--emit` flag, we will get a list of valid values. This is not the case for `--crate-type` flag, which should also display valid values.

The `--emit` example:
```
$ cargo rustc -- --emit=asd
   Compiling tokio v0.2.13 (/host/tokio/tokio)
error: unknown emission type: `asd` - expected one of: `llvm-bc`, `asm`, `llvm-ir`, `mir`, `obj`, `metadata`, `link`, `dep-info`
```

The `--crate-type` example:
```
$ cargo rustc -- --crate-type=dynlib
   Compiling tokio v0.2.13 (/host/tokio/tokio)
error: unknown crate type: `dynlib`

error: could not compile `tokio`.

To learn more, run the command again with --verbose.
```

Versions:
```
$ cargo --version
cargo 1.41.0 (626f0f40e 2019-12-03)
r$ rustc --version
rustc 1.41.0 (5e1a79984 2020-01-27)
```

I have also tested this on rustc 1.42.0 and it is the same.
Repository: rust
Issue: Consider adding #[must_use] to std::process::Child
Labels: C-enhancement,T-libs-api,A-process

I fixed a bug that was caused by not calling `.wait()` on a `std::process::Child`. See [the issue](https://github.com/denisidoro/navi/issues/267) for the details. I'm not exactly sure how the bug manifested itself, but I noticed that not waiting for the child process whose stdin or stdout is inherited from the parent process can lead to weird behavior.

That's why I suggest to add `#[must_use = "this Child may still be attached to its parent process's stdin/stdout and must be handled"]` to `std::process::Child`. Currently I can't think of a reason why someone would not use a `Child` and that's I think the compiler warnings on that will prevent more headaches than they will cause.
Repository: go
Issue: x/build/dashboard: atLeastGo1/atMostGo1 helpers handle non-release branches incorrectly
Labels: Builders,NeedsInvestigation

As a follow-up to #37953, we can improve the `atLeastGo1` and `atMostGo1` helpers so that they operate closer to what the name suggests, and report only whether the Go version meets a certain number. Right now they report suboptimal results on non-release branches in some situations.

For example, the `master` branch is currently where Go 1.15 is being developed, but `atLeastGo1(goBranch, 16)` reports true. It should be false.

Similarly, `atMostGo1(goBranch, 15)` makes an incorrect assumption that `master` is already greater than 1.15, and reports false. It should be true.

`cmd/coordinator` can look up precise Go release information (via `maintnerClient`), and use it to make a better decision. We'll need to modify the signature of `BuildsRepoPostSubmit` to pass more information to it.

/cc @toothrot @cagedmantis
Repository: terminal
Issue: Ctrl+C should not cancel ReadFile/ReadConsole when the signal is handled and the console is in VT input mode
Labels: Product-Conhost,Area-Server,Issue-Task

Run this C program on Linux:

```c
#include <signal.h>
#include <unistd.h>

int main()
{
    char buf[4096];

    signal(SIGINT, SIG_IGN);

    write(STDOUT_FILENO, "reading: ", 9);
    ssize_t len = read(STDIN_FILENO, buf, sizeof(buf));
    write(STDOUT_FILENO, buf, len);

    return 0;
}
```

Since `SIGINT` is ignored, what will happen here is that `^C` will be shown in the output (but not passed through to the program since we're not in raw mode), all input on the current line prior to pressing Ctrl+C will be dropped when the current line is submitted (e.g. `aaa^Cbbb` will return `bbb`), and importantly, the `read` system call will not be interrupted.

This differs from the behavior on Windows (see https://github.com/microsoft/terminal/issues/334#issuecomment-601788840) where `ReadFile`/`ReadConsole` will be interrupted by a Ctrl+C even when a handler is set up.

So, I think there is a case to be made here that Ctrl+C on Windows should not interrupt `ReadFile`/`ReadConsole` at all **if** a handler (registered with `SetConsoleCtrlHandler`) has suppressed the signal **and** the input mode has `ENABLE_VIRTUAL_TERMINAL_INPUT` set.
Repository: create-react-app
Issue: add hot reload modules for templates
Labels: issue: proposal,needs triage

for example
```js
import React from 'react';
import ReactDOM from 'react-dom';
import './index.css';
import App from './App';
import * as serviceWorker from './serviceWorker';

const rootEl = document.getElementById('root')

ReactDOM.render(
  <App />,
  rootEl
)

if (module.hot) {
  module.hot.accept('./App', () => {
    const NextApp = require('./App').default
    ReactDOM.render(
      <NextApp />,
      rootEl
    )
  })
}

// If you want your app to work offline and load faster, you can change
// unregister() to register() below. Note this comes with some pitfalls.
// Learn more about service workers: https://bit.ly/CRA-PWA
serviceWorker.unregister();
Repository: godot
Issue: 3d artifact is generated by ProceduralSky (blue circles at the top/bottom)
Labels: bug,topic:rendering,confirmed,topic:3d

**Godot version:**
3.2.1

**OS/device including version:**
Win10/GTX1060

**Issue description:**
The spatial editor in editor and game modes contains a strange graphical artifact that could not be selected or removed.

![image](https://user-images.githubusercontent.com/3036176/77186765-72d6f800-6ae4-11ea-8a81-344153321846.png)

**Steps to reproduce:**
Create a simple project - open 3D editor - at the green line you will see it

![image](https://user-images.githubusercontent.com/3036176/77187103-01e41000-6ae5-11ea-86c1-b5ae3e9f204d.png)

**Minimal reproduction project:**
[New Game Project.zip](https://github.com/godotengine/godot/files/4360893/New.Game.Project.zip)
Repository: three.js
Issue: Possible improvements to Cascaded Shadow Maps
Labels: Suggestion

I thought I'd post a couple improvements for CSM I was thinking about in case anyone is interested and wants to pick them up.

- Render all shadow cascades to a single shadow map target to save on shadow map branching and texture uniforms. Reference [here](http://the-witness.net/news/2010/03/graphics-tech-shadow-maps-part-1/) and [here](http://the-witness.net/news/2010/04/graphics-tech-shadow-maps-part-2-save-25-texture-memory-and-possibly-much-more/)

- Add option to provide a scene bounding box or bounding sphere to the CSM object so the shadow render bounds can always encapsulate the scene.

- Remove or rename the `Frustum` class in the `/csm` folder so it won't eventually conflict with `Frustum` in core.
Repository: flutter
Issue: Smoke test new versions of the tool against projects generated by older versions
Labels: team,tool,P3,team-tool,triaged-tool

Create a library of default template projects for every release. Create integration tests to detect when tool changes would break on older projects to detect unintended breakages and regressions, to inform project migrations.

Example:
1. Check out 1.7.8+hotfix 4 (July 2019 stable)
2. `flutter create`
3. Check out master
4. `flutter run` against Android and iOS devices and simulators
Repository: pytorch
Issue: zip(list, tuple) throws an non-actionable error message
Labels: oncall: jit,triaged,days,TSRootCause:TypeChecking,TSUsability

```python
@torch.jit.script
def test_iterable_tree():
    t = Tuple[int] = (1)
    l: List[int] = [2, 3]

    zip(t, l)
```

Error message,
```
Can not iterate over a module list or tuple with a value that does not have a statically determinable length
```

Expected
```
type Tuple with static length and type List without static length can't be put together into zip(...).
```


Need to make error message thrown from `IterableTree::addChild` better, but notice `IterableTree` is used by both `prim::enumerate` and `prim::zip`.

@wanchaol 

cc @suo @gmagogsfm
Repository: kubernetes
Issue: Provide simulation endpoints for local persistent/ephemeral volumes
Labels: sig/scheduling,sig/storage,kind/feature,lifecycle/frozen,needs-triage

**What would you like to be added**:

The scheduler's [SharedLister](https://github.com/kubernetes/kubernetes/blob/master/pkg/scheduler/listers/listers.go#L49) interface defines APIs to retrieve listers for nodes and pods. The backing implementation used in the scheduler is based on the nodeinfo Snapshot. This scheduler.SharedLister interface is used by all plugins to retrieve and list nodes/pods, the rest of resources are accessed by the framework plugins through the general SharedInformerFactory (like NodeCSI, PVs and PVCs).

Cluster Autoscaler has logic that simulates the scheduling of pods, this logic instantiates a scheduler Framework. The Framework that CA instantiates is configured with a scheduler.SharedLister backed by CA's custom implementation that allows adding "fake" nodes to simulate possible upscale/downscale events. However, since PVs, PVCs and whatnot are listed from SharedInformerFactory, CA can't simulate those resources (e.g., simulate creating a node with local SSD etc.)

What we need is to make storage-related listers available through the scheduler framework's SharedLister interface, in the scheduler those listers will simply be backed by the SharedInformerLister, while CA can implement their own that injects fake resources.

**Why is this needed**:

To enable cluster autoscale to simulate storage-related resources.

/sig scheduling
/assign
Repository: pytorch
Issue: JIT does not support class instance attribute type annotation
Labels: oncall: jit,triaged,enhancement,days

From PEP 526, https://www.python.org/dev/peps/pep-0526/#class-and-instance-variable-annotations.

These 2 use cases are supported in Python3.

```py
@torch.jit.script
class Test:
    _ea_centers: List[int]  # instance attribute type hint.

    def __init__(self):
        self.t = []
        self.t.append(1)
```

```py
@torch.jit.script
class Test:
    def __init__(self):
        self.t: List[int] = []
        self.t.append(1)
```

Now what is supported is 
```py
@torch.jit.script
class Test:
    def __init__(self):
        self.t = torch.jit.annotate(List[int], [])
        self.t.append(1)
```

cc @suo @gmagogsfm
Repository: terminal
Issue: Duplicating a tab/pane without a valid profile should still duplicate the settings from that tab
Labels: Area-UserInterface,Product-Terminal,Issue-Task,Priority-3

This is a follow-up from PR #4429, and bug #2455

> I actually don't hate the idea of just duplicating the settings for the existing control. In that scenario, we'd probably just ignore the settings for that profile in the actual file, and just use whatever settings the control currently has. This might require some plumbing, but it's doable.

> Okay this is harder, but maybe not impossible, but probably impossible in v1.
> The `Profile` knows how to build the connection settings, and the `ControlSettings`, etc. However, when the settings reloads like in this bug, we'll remove all the old profiles, and build a new list. 
> If we wanted the case 1 behavior, we could wait until the `Profile` is a winrt object, then have each Pane hold a strong ref to the `Profile` that it's hosting. Then it would be trivial to be able to duplicate the settings from it. I believe that work is tracked in #3998.

As of #4429, we'll silently do nothing. We should instead get the `Profile` from the `Pane`/`Tab` that we're duplicating, and use that to build the settings instead. 

-------------

note to self: this is the "duplicate the `NewTerminalArgs`, not just the Profile" thread
Repository: opencv
Issue: opencv 4.2.0 built with contrib 4.2.0
Labels: duplicate,wontfix,category: contrib,category: infrastructure

Compiling opencv 4.2.0 built with contrib 4.2.0 seems to be the toughest job in the world. 
So, can you just share a release of opencv 4.2.0 with contrib 4.2.0? I will be grateful.
Repository: pytorch
Issue: Customize batch size based on  gpu id
Labels: triaged,enhancement,module: data parallel

## 🚀 Feature

Right now after choosing the batch size we cannot choose how many batches each gpu should have...
## Motivation
This is not important when the memory of gpus are the same.
BUT if we have 3 gpus with different memory then it will be really helpful to have the power to choose how many batches to give to each gpu.
## Pitch
e.g. we have 3 GPUs: 1 is 24 GB, and 2 are 11GB. each of 11GB can have a batch of 1.
If we do a batch of 4 and choose GPU 0,1,2 it will show a cuda gpu memmory error because the model can not distribute them selectively. **BUT** if we can tell the model that GPU 0 contains 2 and gpu 1,2 contain 1 batch each the problem is solved. 
## Alternatives

Right now we have to change the gather and scatter function manually but it is not easy.
This feature can be so helpful.
Repository: terminal
Issue: Device portal in Windows Terminal
Labels: Issue-Feature,Area-Extensibility,Product-Terminal

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

# Description of the new feature/enhancement

- Windows 10 users currently have the ability to control a device in the **Device Portal** in the **GUI (Graphical User Interface) version**, but not in the **CUI (Character User Interface) / Terminal** version.

- Windows 10 users would be pleased if this feature were also available in the **CUI 
(Character User Interface) / Terminal** version.


<!-- 
A clear and concise description of what the problem is that the new feature would solve.
Describe why and how a user would use this new functionality (if applicable).
-->

# Proposed technical implementation details (optional)

<!-- 
A clear and concise description of what you want to happen.
-->
Repository: TypeScript
Issue: Iteration using for of does not recognize optional arrays in generic mapped types
Labels: Bug

**TypeScript Version:**  3.8.3

**Search Terms:**
mapped for of array optional undefined generic

**Code**

```ts
type OptionalArrays = {
    a: Array<string>|undefined;
    b: Array<number>|undefined;
}

function test1<K extends keyof OptionalArrays>(value: OptionalArrays[K]) {
    for (const item of (value || [])) {
    }
}

function test2(value: Array<string>|Array<number>|undefined) {
    for (const item of (value || [])) {
    }
}
```

**Expected behavior:**
Both `test1` and `test2` compile.

**Actual behavior:**
`test2` compiles, but `test1` reports `Type 'OptionalArrays[K]' must have a '[Symbol.iterator]()' method that returns an iterator.(2488)`.

**Playground Link:**
https://www.typescriptlang.org/play/#code/C4TwDgpgBA8mwEsD2A7AhgGwIICcdpAGcoBeKAbwFgAoKOqNALil3xAB5DgcEUBzAHwAfAK4oAJhABmvCOIDcNelABGzVgXYoRAWxUQcwsZJko5i6gF8aNKWIDGiVFGAQuARnYBpKBAAerhLEANYQIEhSsPDI6Nh4BIQCABQAbpgiEMxwTrEaRADaXgC6AJQUSvRSSDhQSfaoXFAIrjpQEbVpGBlQQkJQ+aVlVLT01lY21HYojjEubsAATKnpmSzxHFw8-MJ5Wrr6hqIS0rLiQxV0VTV1DcBNLW2Ry13Qvf2D5SN0Y5ZAA
Repository: pytorch
Issue: Autograd Engine leaks reentrant threadpool threads on deletion
Labels: module: autograd,triaged,better-engineering

This is not a huge problem in general but we should have a similar mechanism as we do for the device worker threads [here](https://github.com/pytorch/pytorch/blob/12f0052eee599ae85c78ccb22c17ae41cc221ff2/torch/csrc/autograd/engine.cpp#L233-L254) that tries it's best to clean things up when possible.

cc @ezyang @SsnL @albanD @zou3519 @gqchen