sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Type guards can't deal with unknown type as default
Labels: Suggestion,Needs Proposal

We can't know the failures of type inference in type guards because of this problem. Maybe `a is any[]` should also return unknown[].

<!--
Please try to reproduce the issue with the latest published version. It may have already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly
-->
**TypeScript Version:**  3.7.x-dev.20200410

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

**Code**

```ts
declare function f(a: any): a is any[];
declare function g(a: any): a is unknown[];
declare const a: readonly number[];

f(a) && a; // any[]
g(a) && a; // not unknown[]
```

**Expected behavior:**
a's type narrowed by g is `unknown[]`.
**Actual behavior:**
a's type narrowed by g is `readonly number[] & unknown[]`.

**Playground Link:** https://www.typescriptlang.org/play/?ts=3.9.0-dev.20200410&ssl=1&ssc=1&pln=6&pc=11#code/CYUwxgNghgTiAEAzArgOzAFwJYHtVIAooAueKVATwEpSp4sBnMygbQF0BuAKFElgRTpseeAHMitSjTL0maANaocAd1TtuvaHHhg8DDGVJwowPBArxUyALYAjEDHVcuiIlXgAyD2W7io7rx8gA

**Related Issues:** #17002
Repository: vue-element-admin
Issue: support /icons/svg/index to defined child folder of icons
Labels: feature,in plan

## Feature request（新功能建议）

in router we could use subfolder project like follow
```js
meta:{
title:'dingding.settingpage',
icon:'dingding.setting'
}
```
Repository: godot
Issue: ProjectSettings.load_resource_pack won't replace files.
Labels: bug,topic:core

**Godot version:**
3.2.1.stable

**OS/device including version:**
Windows10 (latest)

**Issue description:**
Been trying a solution for a least a few hours on this issue. ProjectSettings.load_resource_pack doesn't replace files if replace_files is true . I made one pck file using export with a scene that had a red color_rect. the pck file loads properly without errors but wont have the red square.

pls don't fix this because its the only way to make pcks to work but turning on 'convert text resources to binary on export' does make it work but filenames are like res://folder/scene.tscn.converted.res instead of res://folder/scene.tscn and they do load the red color_rect

**Steps to reproduce:**
pretty much add a red color_rect, export as pck or zip, and try to load that pck file. the pck file will load properly (will return true) it won't have the red color_rect square.

**Minimal reproduction project:**
same as above.
Repository: rust
Issue: Auto-fix wrongly suggesting scope issues during struct manipulations 
Labels: C-enhancement,A-diagnostics,T-compiler

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->
Hi, there's a auto-fix bug. I'm using VSCode. The code explains itself:

I tried this code:

```rust
use std::fmt;
use std::fmt::Error;
use std::fmt::Formatter;

struct Structure(i32);

#[derive(Debug)]
struct Point {
    x : i32,
    y : i32,
}

impl fmt::Display for Structure {
    fn fmt(&self, f: &mut Formatter) -> Result<(), Error> {
        write!(f, "The value inside the structure is: {}", self.0)
    }
}


fn main() {
    let s = Structure(12);
    println!("{}", s);
    let point = {x = 12; y = 45};
    println!("{}")
}
```

I expected to see the auto-fix suggest ways to print Point correctly.

Instead, auto-fix in VSCode suggests changing x and y to s in line 23.
However, the error message from rust displays fine.

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.42.0 (b8cedc004 2020-03-09)
binary: rustc
commit-hash: b8cedc00407a4c56a3bda1ed605c6fc166655447
commit-date: 2020-03-09
host: x86_64-unknown-linux-gnu
release: 1.42.0
LLVM version: 9.0
```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Backtrace</summary>
<p>

```
RUST_BACKTRACE=1 cargo build
   Compiling hello_world v0.1.0 (/home/jerry/rust-experiment/hello_world)
error: 1 positional argument in format string, but no arguments were given
  --> src/main.rs:26:15
   |
26 |     println!("{}")
   |               ^^

error[E0425]: cannot find value `x` in this scope
  --> src/main.rs:23:9
   |
23 |         x = 12;
   |         ^ help: a local variable with a similar name exists: `s`

error[E0425]: cannot find value `y` in this scope
  --> src/main.rs:24:9
   |
24 |         y = 45;
   |         ^ help: a local variable with a similar name exists: `s`

error: aborting due to 3 previous errors

For more information about this error, try `rustc --explain E0425`.
error: could not compile `hello_world`.
```

</p>
</details>
Repository: opencv
Issue: opencv.js detectMultiScale piles up a lot of memory when using large images
Labels: category: javascript (js)

##### System information (version)
- OpenCV => 4.3 (problem also exists for older versions)
- Operating System / Platform => Linux (with Mozilla Firefox 74.0 (64-bit))
- Compiler => using opencv.js from demo page

##### Detailed description
When detectMultiScale from opencv.js runs on large photos (e.g. from common DSLRs), a lot of memory is used and not freed after use.
Running the demo (https://docs.opencv.org/4.3.0/js_face_detection.html) on a 8MB jpeg file results in >1GB of used memory, which is not removed after detetctMultiScale has finished or after loading a different image.

I am not really sure, but it could be related to this issue: https://github.com/opencv/opencv/issues/15060 !?

##### Steps to reproduce

1. Go to: https://docs.opencv.org/4.3.0/js_face_detection.html
2. Load a large photo which contains faces (I used 6000x4000px, ~8MB, jpeg)
3. Check the memory of the tab (e.g. by using the browser's dev functions)
4. Load a different photo
5. Check memory again, and see that it is even larger than in step 3.
Repository: flutter
Issue: Add consistent across all platforms onDonePressed callback to TextField
Labels: a: text input,c: new feature,framework,f: material design,a: quality,c: proposal,P3,team-text-input,triaged-text-input

This issue is a follow up of https://github.com/flutter/flutter/issues/49785
Please check it out.

TextField's **onSubmitted** and **onEditingComplete** behaive differently on different platforms. 

Currently, there are following differnces:
On mobile - **onSubmitted**  **is not** firing if you tap another TextField or blank space.
On web  - **onSubmitted** **is** firing if you tap another TextField or blank space (undesired).
On mobile web - **onSubmitted** **is** firing when the virtual keyboard is closed and when app sent to background (undesired).

I suggest adding **onDonePressed** callback that would be invoked **only** when user presses **Enter**.

It'd allow to have the same behavior on mobile and web without changing code and creating workarounds.

Thanks!
Repository: pytorch
Issue: After `create_graph=True`, calculating `backward()` on sparse Tensor fails
Labels: triaged,enhancement

## 🐛 Bug

After retaining the calculation graph of the gradients ( `create_graph=True`), `backward()` fails on sparse Tensor.

The following error occurs:
`RuntimeError: calculating the gradient of a sparse Tensor argument to mm is not supported.`

## To Reproduce
```
import torch

batch_size = 10
inp_size = 1000
out_size= 40

X = torch.randn(batch_size, inp_size).to_sparse().requires_grad_(True)
y = torch.randn(batch_size, out_size).requires_grad_(True)

weight = torch.nn.Parameter(torch.randn(inp_size, out_size))

y_out = torch.sparse.mm(X, weight)

criterion = torch.nn.MSELoss()
loss = criterion(y_out, y)

grad = torch.autograd.grad(loss, [weight], create_graph=True)[0]

expected_grad = torch.randn(grad.size())
L = ((grad - expected_grad) ** 2).sum()
L.backward()

```

## Expected behavior

After `L.backward()`, dL/dX and dL/dy should be calculated based on the gradient's calculation graph.

## Environment
```
PyTorch version: 1.4.0
Is debug build: No
CUDA used to build PyTorch: 10.1

OS: Ubuntu 18.04.4 LTS
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
CMake version: Could not collect

Python version: 3.6
Is CUDA available: Yes
CUDA runtime version: 9.1.85
GPU models and configuration: 
GPU 0: Tesla V100-PCIE-32GB
GPU 1: Tesla V100-PCIE-32GB

Nvidia driver version: 440.33.01
cuDNN version: Could not collect

Versions of relevant libraries:
[pip] Could not collect
[conda] Could not collect
```
- pip                    20.0.2
- numpy              1.17.0
- torch                 1.4.0
- torchvision        0.5.0
Repository: pytorch
Issue: Issue when linking C++ code with libtorch_cpu: cuda not detected
Labels: module: build,module: cpp,triaged

## 🐛 Bug

(not sure how much of a bug this is, maybe it's expected)
I'm currently working on adapting some [rust bindings](https://github.com/LaurentMazare/tch-rs) for PyTorch and in the process came across the following issue for which I don't have a good solution. The issue can be show on C++ code.
- When linking the final binary with `-ltorch -ltorch_cpu -lc10`, `torch::cuda::is_available()` returns false.
- When linking the final binary with `-Wl,--no-as-needed -ltorch -ltorch_cpu -lc10`, `torch::cuda::is_available()` returns true.
- When linking without `-ltorch_cpu`, I get a missing symbol error for: `c10::Dispatcher::singleton`.

I tried compiling some C++ pytorch code with cmake and it seems to use --no-as-needed to get this to work.

Is there a way to get some external code to compile without libtorch_cpu?
One difficulty is that the rust build system does not let you specify arbitrary linker flags so I cannot easily set `-Wl,--no-as-needed`.

## To Reproduce

The issue can be reproduced using the C++ code below.

```c++
#include <torch/torch.h>
#include <iostream>

int main() {
  std::cout << torch::cuda::is_available() << std::endl;
}
```
Then:
- `g++ test.cpp -std=gnu++14 -ltorch -ltorch_cpu -lc10 && ./a.out` prints 0.
- `g++ test.cpp -std=gnu++14 -Wl,--no-as-needed -ltorch -ltorch_cpu -lc10 && ./a.out` prints 1.

## Expected behavior

I would have hoped for cuda to be reported as available without the `-Wl,--no-as-needed` flag.

## Environment

 - PyTorch Version (e.g., 1.0): release/1.5 branch as of 2020-04-11.
 - OS (e.g., Linux): Linux (ubuntu 18.04)
 - How you installed PyTorch (`conda`, `pip`, source): source, compiled with cuda support
 - Build command you used (if compiling from source): `python setup.py build`
 - Python version: 3.7.1.
 - CUDA/cuDNN version: 10.0/none.
 - GPU models and configuration: 1x GeForce RTX 2080.
 - Any other relevant information: gcc/g++ 7.5.0, ld 2.3.0

## Additional context

cc @yf225
Repository: create-react-app
Issue: Update workbox plugin to 5.1.2 resolving ServiceWorker quota exceeded errors
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?

Currently our e-commerce site is experiencing millions of ServiceWorker `DOMException: QuotaExceededError` errors ([we're not the only ones](https://github.com/GoogleChrome/workbox/pull/1505)), which almost blowing through our monthly Rollbar limit 😬. I did some brief research and found that Google is aware of this issue and [recommends `purgeOnQuotaError`](https://developers.google.com/web/tools/workbox/guides/storage-quota#purgeonquotaerror) to potentially fix most of these runtime quota issues.

I could be mistaken, but looks as if [CRA is using workbox 4.3.1](https://github.com/facebook/create-react-app/blob/c5b96c2853671baa3f1f297ec3b36d7358898304/packages/react-scripts/package.json#L84), and this `purgeOnQuotaError` was [added in 5.0.0 as default enabled](https://github.com/GoogleChrome/workbox/blob/v5.0.0/packages/workbox-build/src/options/defaults.js#L29).

Since CRA follows best practices, I highly suggest we update Workbox plugin ASAP so we can be on par with Google's best practices for handling ServiceWorkers.

Thanks and love this app!

### Describe the solution you'd like

[Update `workbox-webpack-plugin` to 5.1.2](https://github.com/facebook/create-react-app/pull/8822)

### Describe alternatives you've considered

None possible without ejecting.
Repository: go
Issue: x/tools/gopls: fuzzy completion does not return result when expected
Labels: NeedsInvestigation,gopls,Tools

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version devel +801cd7c84d Thu Apr 2 09:00:44 2020 +0000 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.0.0-20200408132156-9ee5ef7a2c0d => github.com/myitcvforks/tools v0.0.0-20200408225201-7e808beafd9f
$ go list -m golang.org/x/tools/gopls
golang.org/x/tools/gopls v0.0.0-20200408132156-9ee5ef7a2c0d => github.com/myitcvforks/tools/gopls v0.0.0-20200408225201-7e808beafd9f
</pre>

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/myitcv/.cache/go-build"
GOENV="/home/myitcv/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/myitcv/gostuff"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/myitcv/gos"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/myitcv/.vim/plugged/govim/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build227804233=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

```
-- go.mod --
module github.com/myitcv/playground

go 1.12
-- main.go --
package main

import (
	"fmt"
)

func main() {
	fmt.Prnf
}
```



### What did you expect to see?

Triggering completion at the end of `fmt.Prnf` to return a single result, `fmt.Printf`

### What did you see instead?

Triggering completion at the end of `fmt.Prnf` did not return any results.

See the following `gopls` log: [bad.log](https://github.com/golang/go/files/4465248/bad.log)


---

cc @stamblerre @muirdm

FYI @leitzler
Repository: rust
Issue: Typo suggestion doesn't account for types
Labels: C-enhancement,A-diagnostics,T-compiler,A-suggestion-diagnostics,D-papercut

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

When using multiple transmitters with a single receiver across multiple thread, the `:help` message is totally bonkers. Refer the `backtrace` lines 10 and 16:

```rust
use std::sync::mpsc::channel;
use std::thread;

fn main() {
    let (tx1, rx) = channel();
    let tx2 = tx1.clone();

    thread::spawn(move || {
        for i in 1..10 {
            tx.send(i);
        }
    });

    thread::spawn(move || {
        for i in 1..10 {
            tx.send(i);
        }
    });

    for i in 1..10 {
        println!("{}", rx.recv().unwrap());
    }
}
```

The auto-fix seems to be too ambitious at the moment by suggesting wrong fixes. Let me know if I need to file a RFC for this. JAVA's auto-fix seems smarter and Rust can definitely borrow some of it's implementation.

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.42.0 (b8cedc004 2020-03-09)
binary: rustc
commit-hash: b8cedc00407a4c56a3bda1ed605c6fc166655447
commit-date: 2020-03-09
host: x86_64-unknown-linux-gnu
release: 1.42.0
LLVM version: 9.0
```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Backtrace</summary>
<p>

```
 Compiling hello_world v0.1.0 (/home/jerry/rust-experiment/hello_world)
error[E0425]: cannot find value `tx` in this scope
  --> src/main.rs:10:13
   |
10 |             tx.send(i);
   |             ^^ help: a local variable with a similar name exists: `rx`

error[E0425]: cannot find value `tx` in this scope
  --> src/main.rs:16:13
   |
16 |             tx.send(i);
   |             ^^ help: a local variable with a similar name exists: `rx`

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0425`.
error: could not compile `hello_world`.

To learn more, run the command again with --verbose.
```

</p>
</details>
Repository: vscode
Issue: Task terminal truncates long/quick output.
Labels: bug,tasks,terminal-process

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->
<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: https://code.visualstudio.com/insiders/ -->

<!-- Use Help > Report Issue to prefill these. -->
VS Code version: Code 1.43.0 (78a4c91400152c0f27ba4d363eb56d2835f9903a, 2020-03-09T19:44:52.965Z)
OS version: Linux x64 5.4.25

### Steps to Reproduce

Run "test" task using this `.vscode/tasks.json`:
```json
{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "test",
            "type": "shell",
            "command": "seq 1000 | sed 's/$/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/'",
        }
    ]
}
```

### Expected behavior
All 1000 lines are printed, the last 3 lines being:
(this is how it works when ran in a regular VSCode Terminal)
```
998XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
999XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1000XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
```

### Actual behavior
Task output is truncated randomly, these being two example runs' last 3 lines:
```
741XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
742XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
743XXXXXXXXXXXXXXXXX
```
```
754XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
755XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
756XXXXXXXXXXXXXXX
```

### Additional background
Reading the description of #75139, I'm *pretty sure* it's the same bug.
It was marked as a duplicate of #38137, but I'm not sure that's correct.

I've only seen this in the last few months, *after* #38137 was supposedly fixed, and assumed the problem was a change in the process producing the output, or some bug/setting in SSH, which is why I haven't reported it earlier.

However, after coming across #75139, I did some experimentation, and even a task that only does `cat build-log` results in truncation (`build-log` is 128kB and has 2665 lines, the current output from a real workload).
And then I simplified that to the command above, which reproduces easily.

Even `seq 1000` alone was truncated once, at `841`.
And `seq 10000` truncates even easier, example last 3 lines from some runs:
```
9595
9596
959
```
```
7437
7438
7439
```
```
8143
8144
814
```
Repository: godot
Issue: node_added isn't triggered for nodes in the Main Scene
Labels: bug,topic:core

**Godot version:**
v3.2.1.stable.mono.official

**OS/device including version:**
Windows 10

**Issue description:**
I have an auto-loaded `Node` that connects to `node_added` in `_Ready()`.
My connected function triggers to nodes that are added by AddChild (even for nodes added in the Main Scene's _Ready()).
By logging, I confirmed the `node_added` signal is connected before the Main Scene's `_Ready()` is called.

**Steps to reproduce:**
(All in C#)
1. Create a node and have it connect to `node_added` in its `_Ready()` method.
2. Set that node to Auto Load in your project settings
3. Setup a scene with multiple nodes
4. Make that scene your Main Scene in your project settings
5. Run the project and notice that node_added is not triggered for any of the nodes in your Main Scene.

**Minimal reproduction project:**
[NodeAddedIssue.zip](https://github.com/godotengine/godot/files/4465343/NodeAddedIssue.zip)
Repository: rust
Issue: Lint exported_private_dependencies misses public dependency via trait impl
Labels: A-lints,A-visibility,T-compiler,C-bug,F-public_private_dependencies

Tracking issue: #44663, RFC: rust-lang/rfcs#1977

Cargo.toml:

```toml
cargo-features = ["public-dependency"]

[package]
name = "playground"
version = "0.0.0"
edition = "2018"

[dependencies]
num-traits = "0.2"
```

lib.rs:

```rust
pub struct S;

impl std::ops::Add for S {
    type Output = S;

    fn add(self, _: Self) -> Self::Output {
        unimplemented!()
    }
}

impl num_traits::Zero for S {
    fn zero() -> Self {
        unimplemented!()
    }
    fn is_zero(&self) -> bool {
        unimplemented!()
    }
}
```

Also, a plain `pub use` seems to be missed as well.
Repository: flutter
Issue: Ensure that macOS rebuilds are fast
Labels: tool,platform-mac,a: desktop,a: build,P2,team-macos,triaged-macos

We need to audit the macOS build pipeline and ensure that we aren't doing excessive work on what should be minimal rebuilds.

I believe there are still some known issues in how `assemble` interacts with the Xcode build. @jonahwilliams are there existing bugs for that I should list as blockers?
Repository: flutter
Issue: Ensure that Windows rebuilds are fast
Labels: tool,platform-windows,a: desktop,a: build,P2,team-windows,triaged-windows

We need to audit the Windows build pipeline and ensure that we aren't doing excessive work on what should be minimal rebuilds.

Some areas I'm aware of needing investigation:
- The interaction with the Flutter build step.
- Unconditionally writing config files, which may cause VS to rebuild everything even when their contents haven't changed.
Repository: flutter
Issue: Ensure that Linux rebuilds are fast
Labels: tool,platform-linux,a: desktop,a: build,P3,team-linux,triaged-linux

We need to audit the Linux build pipeline and ensure that we aren't doing excessive work on what should be minimal rebuilds.

This is something we should wait until we've switched to `CMake` to investigate, as there's no reason to tune the current Make builds.