sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: angular
Issue: Service Worker "Quota exceeded" can break all JS (ERR_FAILED)
Labels: type: bug/fix,effort2: days,help wanted,freq1: low,area: service-worker,state: confirmed,P3

<!--🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅

Oh hi there! 😄

To expedite issue processing please search open and closed issues before submitting a new one.
Existing issues often contain information about workarounds, resolution, or progress updates.

🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅-->


# 🐞 bug report

### Affected Package
<!-- Can you pin-point one or more @angular/* packages as the source of the bug? -->
<!-- ✍️edit: --> The issue is caused by package @angular/service-worker


### Is this a regression?

<!-- Did this behavior use to work in the previous version? -->
<!-- ✍️--> Not sure


### Description


The service worker fails to load core JS files with `DOMException: Quota exceeded.`

This results in just a white page being shown, with a broken app.

Angular 9.0.4
Chromium 80

![image](https://user-images.githubusercontent.com/697707/76769191-ca076080-67a4-11ea-8690-93f4030e0a5b.png)

![image](https://user-images.githubusercontent.com/697707/76769205-cf64ab00-67a4-11ea-8f2a-ccaaa3a407e2.png)

I've migrated from a custom workbox based serviceworker to the angular native service worker and now running into this.

Force reloading (`ctrl+f5`) makes everything load, but the error returns on the next normal load.

After using DevTools to debug it, I found that the error is `DOMException: Quota exceeded.`  and occurs in this block: 

![image](https://user-images.githubusercontent.com/697707/76770457-acd39180-67a6-11ea-8f76-3c1cf34f2c14.png)


## 🔬 Minimal Reproduction

Hard to reproduce unfortunately, needs low disk space or a big app being cached.

## 🔥 Exception or Error
<pre><code>
The FetchEvent for ".../runtime-es2015.91c3f469886b8efa1fca.js" resulted in a network error response: the promise was rejected.
Promise.then (async)
onFetch @ ngsw-worker.js:1993
(anonymous) @ ngsw-worker.js:1928
</code></pre>


## 🌍  Your Environment

**Angular Version:**
<pre><code>9.0.4</code></pre>

**Anything else relevant?**
<!-- ✍️Is this a browser specific issue? If so, please specify the browser and version. -->

<!-- ✍️Do any of these matter: operating system, IDE, package manager, HTTP server, ...? If so, please mention it below. -->

Might be related to #21412 and #33793 which both appear fixed.

I'm not sure what the right fix here would be, I think fallback to network might be appropriate rather than completely failing the request.
Repository: go
Issue: cmd/go: document/clarify how `go env` infers `CC` and `CXX` when not set.
Labels: Documentation,NeedsFix

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.14 linux/amd64

</pre>

### Does this issue reproduce with the latest release?

I don't know

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
fred@fred-linux:~/src/server/build$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/fred/.cache/go-build"
GOENV="/home/fred/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/fred/go:/home/fred/src/server/Gofred/"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/linuxbrew/.linuxbrew/Cellar/go/1.14/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/linuxbrew/.linuxbrew/Cellar/go/1.14/libexec/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc-5"
CXX="g++-5"
CGO_ENABLED="1"
GOMOD=""
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-build142698688=/tmp/go-build -gno-record-gcc-switches"

</pre></details>

### What did you do?

I probably had `gcc-5` as the default compiler on my ubuntu system.  Then I did change the default compiler (with `update-alternative`)  so that `gcc` now invokes `gcc-8` (same for g++).

I have some c++ code I try to bridge with cgo that relies on c++ 17.   I try to build it this way

     go build -x  -o /home/fred/src/server/build/libcppgow.so -buildmode=c-shared main.go

The output shows me it is using `g++-5` (and the build fails, of course).  `go env` also shows:
     
     CC="gcc-5"
     CXX="g++-5"

Somehow, `go` does not want to use the default compiler.  He might have cache somewhere the default compiler from an earlier invocation.  Or it might use the compiler at the time I installed `go` (using `brew`).


<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->



### What did you expect to see?

I expect the `CC/CXX` are inferred to be the default compiler of the platform.
If I'm wrong, then you should clearly document how `CC/CXX` are inferred.
Repository: rust
Issue: found a bug in the borrow checker
Labels: A-borrow-checker,T-compiler,C-bug,fixed-by-polonius

<!--
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.
-->

I tried this code:

```rust
fn main() {
    let mut zero = &mut 0;
    let mut one = 1;

    {
        let mut _r = &mut zero;
        let mut y = &mut one;
        _r = &mut y;
    }

    println!("{}", one); // compiler complains that there's a mutable reference.
    println!("{}", zero);

}
```

I expected to see this happen: print 1 then 0.

Instead, this happened: compile error

### 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-pc-windows-msvc
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>

```
error[E0502]: cannot borrow `one` as immutable because it is also borrowed as mutable
  --> src\main.rs:11:20
   |
7  |         let mut y = &mut one;
   |                     -------- mutable borrow occurs here
...
11 |     println!("{}", one);
   |                    ^^^ immutable borrow occurs here
12 |     println!("{}", zero);
   |                    ---- mutable borrow later used here
```

</p>
</details>


EDIT:  Here's a concise version of the original snippet which produces the same error:

```
fn main() {

    let mut v1 = &mut 0;
    let mut v2 = 1;

    {
        let mut x = &mut &mut v2;
        x = &mut v1;
    }
    
    println!("{}", v2); // compiler would complain there's a mutable reference.
    println!("{}", v1);
}
```

it is weird since the buggy behavior depends on the access order between the variables v1 and v2, if change the order or access only one of the two variables, the compiler error disappears
Repository: rust
Issue: Type Parameter Name becomes “_” in Part of Error Message
Labels: C-enhancement,A-diagnostics,T-compiler,D-papercut

```rust


fn main() {
    let x1 = [Ok(1), Ok(0)];
}
```

([Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=bc4501ab19de8c78f0c5326351412108))

Errors:

```
   Compiling playground v0.0.1 (/playground)
error[E0282]: type annotations needed for `[std::result::Result<i32, _>; 2]`
 --> src/main.rs:4:15
  |
4 |     let x1 = [Ok(1), Ok(0)];
  |         --    ^^ cannot infer type for type parameter `E` declared on the enum `Result`
  |         |
  |         consider giving `x1` the explicit type `[std::result::Result<i32, _>; 2]`, where the type parameter `E` is specified

error: aborting due to previous error

For more information about this error, try `rustc --explain E0282`.
error: could not compile `playground`.

To learn more, run the command again with --verbose.

```
Above, note the “consider giving `x1` the explicit type…” part of the error message, where it mentions `E`, but in the type we only have a `_`.


In a more straightforward case (without the array) the error message is
```
  |
4 |     let x0 = Ok(1);
  |         --   ^^ cannot infer type for type parameter `E` declared on the enum `Result`
  |         |
  |         consider giving `x0` the explicit type `std::result::Result<i32, E>`, where the type parameter `E` is specified
```
which makes a lot more sense, since the `E` actually appears in the type.
Repository: pytorch
Issue: Semantic differences between forward and backward of upsampling2d/3d in channels last (NHWC, NDHWC) format.
Labels: triaged,module: memory format

## 🚀 Feature
Preserving memory input memory format in upsampling nearest model op. Forward and backward.

## Motivation

At the moment, upsample nearest kernels, forward and backward, return output in the contiguous format, ignoring the input memory format. For example, if the input was channel last the output will still be in contiguous, channels first, format.

This PR introduces https://github.com/pytorch/pytorch/pull/34597/, introduces upsample nearest in channel last format (for 2d/3d variants), but only does so for forward calls. The backward of the ops are still in the contiguous memory format. Thus it introduces a discrepancy where the forward pass preserves the input memory format during upsample nearest 2d/3d but backward pass of the same op does not.

## Pitch

Ideally each op returns the tensor in not `.contiguous()` format but in `.contiguous(input.suggest_memory_format())` thus preserving the input format.



cc @VitalyFedyunin @jamesr66a
Repository: pytorch
Issue: [JIT] Tensor.add_ incorrect schema matching on overloads
Labels: oncall: jit,triaged

# Reproduce

```
#!/usr/bin/env python3

import torch
from torch import Tensor
from torch.testing import FileCheck
from torch.testing._internal.common_utils import TestCase


class JitAtenOp(TestCase):
    def test_use_in_place_add(self):
        """
        For native::add_(..), JIT chose the wrong overload once,
        put this test case to avoid this from hapenning again.
        """

        def use_in_place_add(param: Tensor, grad: Tensor, clr: float) -> Tensor:
            # pyre-ignore [16]: `Tensor` has no attribute `add_`.
            return param.add_(clr, grad)

        initial_param = torch.ones(2, 5)
        grad = torch.randn(2, 5)
        clr: float = -1e-2

        # Scenario 1, function is NOT scripted
        py_param = initial_param.clone()
        py_result = use_in_place_add(py_param, grad, clr)
        self.assertNotEqual(initial_param, py_param)

        # Scenario 2, function is scripted
        # Overload has problem, expect error at this step.
        use_in_place_add_ts = torch.jit.script(use_in_place_add)
        print(use_in_place_add_ts.graph)
        FileCheck().check("aten::add_").run(str(use_in_place_add_ts.graph))
        ts_param = initial_param.clone()
        ts_result = use_in_place_add_ts(ts_param, grad, clr)
```


PythonArgParser gives warning and use the correct overload,
```
caffe2/torch/csrc/utils/python_arg_parser.cpp:739: UserWarning: This overload of add_ is deprecated:
	add_(Number alpha, Tensor other)
Consider using one of the following signatures instead:
	add_(Tensor other, Number alpha)
  TORCH_WARN_ONCE(msg);
```

JIT use the wrong overload and insert a `aten::SclarImplicit`,
because it by default allows conversion.

https://github.com/pytorch/pytorch/blob/c235be42ddecc3c4e1cdf192ca2764455082c1c6/torch/csrc/jit/frontend/schema_matching.cpp#L102


cc @suo
Repository: rust
Issue: Bad diagnostic for match ergonomics
Labels: E-hard,C-enhancement,A-diagnostics,P-low,T-compiler,E-medium

This is a reopening of https://github.com/rust-lang/rust/issues/51743 to not lose track of the diagnostic issue which still remains to this day.

Match ergonomics can create quite confusing errors.

For instance:
```rust
fn main() {
    let option = MyOption::MySome(String::new());
    option.take();
}

enum MyOption<T> {
    MyNone,
    MySome(T),
}

impl<T> MyOption<T> {
    fn take(&mut self) -> Option<T> {
        match self {
            MyOption::MySome(value) => {
                *self = MyOption::MyNone;
                Some(value)
            },
            MyOption::MyNone => None,
        }
    }
}
```
([playground](http://play.rust-lang.org/?gist=60bcff8572f84305326419697eb11df6&version=stable&mode=debug))
gives the following error message:
```
error[E0308]: mismatched types
  --> src/main.rs:16:22
   |
16 |                 Some(value)
   |                      ^^^^^ expected type parameter, found &mut T
   |
   = note: expected type `T`
              found type `&mut T`
```

This error message is not even helping the user to figure out what the problem is.
Here, it's like if value was of type `&mut T` instead of `T`.
Repository: go
Issue: x/crypto/acme: better document Register behavior when account already exists
Labels: Documentation,NeedsInvestigation

Currently when `Client.Register` is called and an account already exists the behavior diverges based on the server implementation. If the server is pre-8555 it just returns the account object and no error, if it is 8555 compliant it returns no account object and a `ErrAccountAlreadyExists` error. In the latter case it will also store the account KID internally, allowing for follow-up requests (although this is not documented).

Ideally for 8555 servers `Client.Register` should return the account object when it already exists (perhaps in conjunction with the `ErrAccountAlreadyExists` error) so that the user doesn't have to do two requests to actually get the object (`Client.Regiser` and `Client.GetReg`), but at the least the documentation should be improved to actually say what happens in this circumstance.
Repository: node
Issue: RFC: update Pull Requests with summary of CI failures
Labels: meta

`ncu-ci` is quite useful to get summary of failures in our CI, but it still requires us to use an external program to fetch the information from Jenkins. We could use our `github-bot` to post the information generated by `ncu-ci` back to the PR, either as a new comment or by editing the bot's comment on that PR. This would also allow us to keep a history of CI failures (since our Jenkins jobs are not persistent).

Is that something other collaborators want as well? I'm looking for feedback before implementing it.

If folks want example of what this would look like, I've updated all CI runs with their respective summaries in https://github.com/nodejs/node/pull/32116. It would look like this:

![img-2020-03-16-112234](https://user-images.githubusercontent.com/4048656/76788625-7ed75880-6778-11ea-8b4b-b278c06a05c7.png)
![img-2020-03-16-112246](https://user-images.githubusercontent.com/4048656/76788623-7e3ec200-6778-11ea-9e14-f564d82b81b3.png)

Or, as a standalone comment:

![img-2020-03-16-112340](https://user-images.githubusercontent.com/4048656/76788709-afb78d80-6778-11ea-9599-eff5072e508c.png)
Repository: thefuck
Issue: Feature request - "fuck" for "fuck" that's misspelled 
Labels: wontfix

If I say fruck or fuk, I want to say "fuck" and it should give me the corrent version of the first fuck.
Repository: pytorch
Issue: NO_CUDA and NO_DISTRIBUTED referenced in docs
Labels: module: docs,triaged

## 📚 Documentation

The old build variables NO_CUDA and NO_DISTRIBUTED are referenced in CONTRIBUTING.md
Repository: TypeScript
Issue: Structural Comparison of Circular Tuples
Labels: Bug,Domain: Conditional Types,Rescheduled

**TypeScript Version:**  3.8.2

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** structure, resolve, compare, equality, type, mismatch, circular, tuple, cycle, recursive

**Code**

I'm trying to represent some type information for runtime use. I define the following enum:

```ts
enum Type {
  Int = "Int",
  List = "List",
}
```

And I define a `Codec` type: a tuple, within which the first element is the given `Type` enum value, and the second element––which is optional––is another `Codec`:

```ts
type Codec<
  T extends Type,
  C extends Codec<Type> | undefined = undefined
> = C extends undefined ? [T] : [T, C];
```

I'm able to assign `Codec`s as expected:

```ts
const c1: Codec<Type.Int> = [Type.Int];
const c2: Codec<Type.List, Codec<Type.Int>> = [Type.List, [Type.Int]];
```

And I'm able to create helpers for the `Type.Int` `Codec`:

```ts
type IntCodec = Codec<Type.Int>;
const createIntCodec = (): IntCodec => [Type.Int];
const intCodec = createIntCodec(); // signature is `[Type.Int]`
```

However, I'm unable to create helpers for `Codec`s which nest other `Codec`s:

```ts
type ListCodec<C extends Codec<Type>> = Codec<Type.List, C>;
const createListCodec = <C extends Codec<Type>>(of: C): ListCodec<C> => [Type.List, of]; // error
```

This results in an error: `Type '[Type.List, C]' is not assignable to type 'Codec<Type.List, C>'. ts(2322)`.

[Playground Link](http://www.typescriptlang.org/play?#code/KYOwrgtgBAKgngB2FA3gKClAkiALlAXigCIddiAaDKAGQEsBnfI4+pytAXzTV0WQDCAewAmwAMYAeajCjAAHrlAiGsflUwC5i5auFip8JAD4oAHyhgQYgGZ0QwEYUvXgdhyLSmiWhUuuqVrb2jlAA-FAA2jAAulAAXFEwFFACMQDcPOJCIExQ4gCMifoSkkbAAHRk3kn8VXgZaNm5+OIATMWipeUVbLgpJYZ11TXRdX0pY0j1uDGNvPzYeIPOg2XDeMaZzXniAE7AAIZKZCtEABQAlImnXeKEplOVZI07+Pa4Z-kHx8C3BldMgskLRGJ87pJfDoAqkIeVjDU1j0Jqktk0crsfko+l9Idp-CpYQZ1iZjOchDZitdQUw1gJvI9kWCUhTGkA)

Any thoughts would be greatly appreciated! Thank you!
Repository: pytorch
Issue: [torch.jit.script] Support tensor indexing after an Ellipsis
Labels: oncall: jit,triaged,enhancement

## 🚀 Feature

Support Tensor indexing after an ellipsis: right now the following code:

```python
@torch.jit.script
def zero_diag(inputs: torch.Tensor) -> torch.Tensor:
    dim = inputs.shape[-1]
    inputs[..., torch.range(0, dim), torch.range(0, dim)] = 0
```

fails with:

```
Ellipses followed by tensor indexing is currently not supported:
  File "<ipython-input-105-deac139d15e2>", line 4
def zero_diag(inputs: torch.Tensor) -> torch.Tensor:
    dim = inputs.shape[-1]
    inputs[..., torch.range(0, dim), torch.range(0, dim)] = 0
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <--- HERE
```

## Motivation

For our application, we would like to manipulate the diagonal of a batch of matrices, which is most easily expressed by manipulating `inputs[..., range(N), range(N)]`. Unfortunately, Torch does not currently support this when using `torch.jit.script`.

Another use-case is to vectorize a batch of symmetric matrices: ideally, we could do something like:
```
ind = torch.triu_indices(N, N)
vectors = matrices[..., ind[0], ind[1]]
```

cc @suo
Repository: pytorch
Issue: [torch.jit.script] Allow `range` to index into Tensor
Labels: oncall: jit,triaged,enhancement

## 🚀 Feature
Support using `range` objects as indexes into a Tensor.

Right now, code like:

```
@torch.jit.script
def f(inputs):
    inputs[range(5), range(5)]
```

will fail with

```
RuntimeError: 
range cannot be used as a value:
  File "<ipython-input-120-c84b77ea824c>", line 3
@torch.jit.script
def f(inputs):
    inputs[range(5), range(5)]
           ~~~~~~~ <--- HERE
```

## Motivation

Using `range` makes it easier to express certain diagonal manipulations of matrices (e.g. for Toeplitz matrices). This isn't a huge deal, because `torch.range` exists, but it is a small papercut.

cc @suo
Repository: terminal
Issue: Strange behavior with ENABLE_VIRTUAL_TERMINAL_INPUT | ENABLE_LINE_INPUT | ENABLE_PROCESSED_INPUT
Labels: Product-Conhost,Help Wanted,Area-Input,Issue-Bug,Priority-2,Area-CookedRead

# Environment

```none
Windows build number: Microsoft Windows [Version 10.0.19041.153]
PowerShell Core 7.0.0
.NET Core 3.1.200
```

# Steps to reproduce

C# program:

```csharp
using System;
using System.Diagnostics;
using System.Text;
using static Vanara.PInvoke.Kernel32;

namespace Test
{
    static class Program
    {
        static void Main()
        {
            var stdin = GetStdHandle(StdHandleType.STD_INPUT_HANDLE);

            Debug.Assert(GetConsoleMode(stdin, out CONSOLE_INPUT_MODE inMode));

            inMode |= CONSOLE_INPUT_MODE.ENABLE_VIRTUAL_TERMINAL_INPUT;

            Debug.Assert(SetConsoleMode(stdin, inMode));

            Console.WriteLine(Console.ReadLine());
        }
    }
}
```

(Uses the `Vanara.PInvoke.Kernel32` NuGet package for convenience.)

You will need to test this program in both CMD and PowerShell Core.

Try doing these:

1. Type `aaa bbb ccc` and press backspace a couple times.
2. Type `aaa bbb ccc` and press control + backspace several times.

Also, try using special keys (such as arrow keys) after the program closes.

# Actual behavior

For the first part:

1. Words are deleted with each backspace press.
2. Characters are deleted with each control + backspace press.

This behavior happens in both CMD and PowerShell Core.

For the second part:

After closing the program, you'll notice that e.g. using the arrow keys echoes VT sequences (such as `^[[D^[[A^[[C` for left, up, right) rather than doing what they're supposed to. This behavior persists even if the `ReadLine` + `WriteLine` is removed from the program.

This behavior only happens in CMD. PowerShell Core seems fine.

# Expected behavior

I have no idea to what extent, if any, this behavior is actually buggy/unintended. But here is what I would expect as a user:

* Backspace and control + backspace behavior should not be swapped like this. This seems very strange and unlike other terminals.
* Console modes set from within a program should not persist after that program exits. PowerShell Core appears to get this right, while CMD does not, for whatever reason.

Perhaps worth noting that running CMD and PowerShell Core under Windows Terminal has no impact on the behavior seen here.

Also, I wasn't sure whether to file this as two separate issues. I can do that if necessary.
Repository: rust
Issue: Pattern matching on constant in nested macro invocation
Labels: A-macros

I am not sure if this is bug or known issue, but I came across strange behavior when trying to match constant expression in macro:
```rust
macro_rules! format_index {
    (0) => ("_0");
}

pub fn main() {
    println!("{}",format_index!(0));  // This line compiles
}
```
This code works just fine, as expected - it matches constant 0 and prints "_0"

However, if the same thing invoked through nested invocation, it does not longer work:
```rust
macro_rules! format_index {
    (0) => ("_0");
}

macro_rules! x {
    ($arg:expr) => (format_index!($arg));
}

pub fn main() {
    // println!("{}",format_index!(0));  // This line compiles
    println!("{}",x!(0));   // This line does not compile (
}
```

Error I get is this:
```
error: no rules expected the token `0`
  --> src/main.rs:6:35
   |
1  | macro_rules! format_index {
   | ------------------------- when calling this macro
...
6  |     ($arg:expr) => (format_index!($arg));
   |                                   ^^^^ no rules expected this token in macro call
...
11 |     println!("{}",x!(0));   // This line does not compile (
   |                   ----- in this macro invocation

error: aborting due to previous error
```
Is this a known behavior? Is there way to pattern match `0` when invoked from `x`?

[Playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=bee2d9d24b765f77e4949a359f28b8e7)

This reproduces on both stable and nightly.