sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: create-react-app
Issue: Workbox.core.clientsClaim is not a function
Labels: issue: needs investigation

Hello guys!
I activate the serviceWorker.register() in my project.
I'm running the build and then I run `serve -s build`

When I use chrome to connect to localhost:5000 I see this error in the console and my service worker is not registered and in application tab I see that service worker in not installed.

`workbox.core.clientsClaim is not a function at service-worker.js:26`

This is my config project
```
"dependencies": {
    "@ionic/react": "^0.0.5",
    "axios": "^0.18.0",
    "dotenv": "^6.2.0",
    "react": "^16.8.6",
    "react-dom": "^16.8.6",
    "react-router": "^5.0.0",
    "react-router-dom": "^5.0.0",
    "react-scripts": "3.0.1",
    "use-react-router": "^1.0.5"
  },
```

yarn 1.7.0
npm 6.1.0

I don't know if it is a bug or just my configuration is failing...

I printed in console the workbobox.core object
![Schermata 2019-05-26 alle 11 50 14](https://user-images.githubusercontent.com/6689594/58380063-81c84900-7fac-11e9-89e6-2317348f5216.png)


Thanks for support
Repository: node
Issue: No content length on DELETE and OPTIONS
Labels: confirmed-bug,help wanted,http

Looking through https://github.com/nodejitsu/node-http-proxy/commit/8a24a1e18f384d29a125eda1d2311bdd8ec66871 and reading through the node code. I do believe we have an unhandled case.

I believe we are missing something here: https://github.com/nodejs/node/blob/master/lib/_http_outgoing.js#L349

To ensure content-length and transfer-encoding are correct.

Am I on to something or should I drop this?
Repository: go
Issue: cmd/compile: prefer to cheaply re-materialize after call site instead of spilling
Labels: Performance,NeedsInvestigation,compiler/runtime

go tip

While working on changing runtime.growslice to not return the length of the new slice (like was done for runtime.makeslice https://github.com/golang/go/commit/020a18c545bf49ffc087ca93cd238195d8dcc411) I ran into the issue of not being able to make the compiler rematerialize the new slice length instead of spilling it in https://github.com/golang/go/blob/d97bd5d07ac4e7b342053b335428ff9c97212f9f/src/cmd/compile/internal/gc/ssa.go#L2479

There generally seems to be a missed opportunity for the compiler to prefer recomputing a value that is cheap to compute from other values that too need to be loaded after a call.

Hand distilled example:
```
//go:noinline
func spilltest(s []int, a int) (int, int) {
	b := a + 1
	if b > len(s) {
		somecall()
	}
	return a, b
}
```

produces:
```
  0x450380	MOVQ FS:0xfffffff8, CX			
  0x450389	CMPQ 0x10(CX), SP			
  0x45038d	JBE 0x4503d8				
  0x45038f	SUBQ $0x10, SP				
  0x450393	MOVQ BP, 0x8(SP)			
  0x450398	LEAQ 0x8(SP), BP			
  0x45039d	MOVQ 0x30(SP), AX			
  0x4503a2	LEAQ 0x1(AX), CX // first computation of b			
  0x4503a6	MOVQ 0x20(SP), DX			
  0x4503ab	CMPQ DX, CX				
  0x4503ae	JG 0x4503c4				
  0x4503b0	MOVQ AX, 0x38(SP)			
  0x4503b5	MOVQ CX, 0x40(SP)		
  0x4503ba	MOVQ 0x8(SP), BP			
  0x4503bf	ADDQ $0x10, SP				
  0x4503c3	RET					
  0x4503c4	MOVQ CX, 0(SP) // Avoid this spill					
  0x4503c8	CALL main.somecall(SB)			
  0x4503cd	MOVQ 0x30(SP), AX			
  0x4503d2	MOVQ 0(SP), CX // do LEAQ 0x1(AX), CX here instead to compute b
  0x4503d6	JMP 0x4503b0				
  0x4503d8	CALL runtime.morestack_noctxt(SB)	
  0x4503dd	JMP main.spilltest(SB)			
```

Neither
```
func spilltest(s []int, a int) (int, int) {
	b := a + 1
	if b > len(s) {
		somecall()
		b = a + 1
	}
	return a, b
}
```

Or
```
func spilltest(s []int, a int) (int, int) {
	b := a + 1
	if b > len(s) {
		somecall()
	}
        c := a + 1
	return a, c
}
```
avoids the spilling.

@josharian @randall77 @cherrymui
Repository: go
Issue: strings,bytes: tune inliner for Contains or add ContainsByte
Labels: Performance,NeedsInvestigation

For strings.Index there already exists a specialized version strings.IndexByte besides strings.IndexRune.  
There currently is no Byte variant of strings.Contains but strings.ContainsRune exists.

Sampling from a large go code corpus:
* ~1/3 of calls to strings.Contains use a string of length 1 with an ASCII character
* strings.Contains appears ~100 times more frequently than strings.ContainsRune
* strings.Contains appears ~6 times more frequently then strings.Index and strings.IndexByte together.

There is overhead for both the binary code size, loading the string from memory and generally performance loss when using Contains or ContainsRune instead of ContainsByte (that uses IndexByte).

Make the inliner sufficiently aware  of Contains and ContainsRune (+possible code layout change) to inline IndexByte calls directly.

### Alternative ###
Add a specialized ContainsByte function to strings and bytes package.

Downside: current code does not immediately get the benefits without change.

### Data ###
```
name                  time/op
Contains              5.88ns ± 1%
ContainsByte          3.30ns ± 0%
ContainsRune          5.40ns ± 1%
ContainsRuneFastPath  5.33ns ± 1%
```

Benchmark (I have seen 2 clock cycle variances due to branch addresses depending on where benchmark loops are, these here favor Contains on my Workstation)
```
var global bool
var data = "golang:contains"

func ContainsByte(s string, b byte) bool {
	return strings.IndexByte(s, b) >= 0
}

func ContainsRuneFastPath(s string, r rune) bool {
	if r <= utf8.RuneSelf {
		return strings.IndexByte(s, byte(r)) >= 0
	}
	return strings.IndexRune(s, r) >= 0
}

func BenchmarkContains(b *testing.B) {
	var sink bool
	for i := 0; i < b.N; i++ {
                // ...
                // LEAQ 0x4c655(IP), AX  // = 7 bytes			
                // MOVQ AX, 0x10(SP)	 // = 5 bytes	
                // MOVQ $0x1, 0x18(SP)   // = 9 bytes
		sink = strings.Contains(data, ":")
	}
	global = sink
}

func BenchmarkContainsByte(b *testing.B) {
	var sink bool
	for i := 0; i < b.N; i++ {
                // ...
                // MOVB $0x3a, 0x10(SP) // = 5 Bytes
                // CALL internal/bytealg.IndexByteString(SB)						
		sink = ContainsByte(data, ':')
	}
	global = sink
}

func BenchmarkContainsRune(b *testing.B) {
	var sink bool
	for i := 0; i < b.N; i++ {
                // ...
                // MOVL $0x3a, 0x10(SP) // = 8 bytes	
		sink = strings.ContainsRune(data, ':')
	}
	global = sink
}

func BenchmarkContainsRuneFastPath(b *testing.B) {
	var sink bool
	for i := 0; i < b.N; i++ {
		sink = ContainsRuneFastPath(data, ':')
	}
	global = sink
}
```
Repository: pytorch
Issue: Track running stats regardless of track_running_stats=False
Labels: module: nn,triaged

## 🐛 Bug

Since v1.1.0, `BatchNorm` tracks running stats even its `track_running_stats` option is `False` on the fly.

## To Reproduce

```python
>>> import torch
>>> bn = torch.nn.BatchNorm2d(3)
>>> bn.track_running_stats = False
>>> bn(torch.rand(1, 3, 2, 2))
>>> bn.running_mean
tensor([0.0711, 0.0396, 0.0542])
```

## Expected behavior

It looks like a design issue. If we decide to make `track_running_stats` as an immutable option, to modify this option should raise `AttributeError`.

Or, if we decide to allow to modify `track_running_stats` after initialization, `BatchNorm.forward()` shouldn't track running stats if it is `False`. Here's a possible fix:

```diff
- if self.momentum is None:
+ if self.momentum is None or not self.track_running_stats:
      exponential_average_factor = 0.0
  else:
      exponential_average_factor = self.momentum
```

## Environment

```
PyTorch version: 1.1.0
Is debug build: No
CUDA used to build PyTorch: 9.0.176

OS: Ubuntu 16.04.5 LTS
GCC version: (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609
CMake version: version 3.5.1

Python version: 3.6
Is CUDA available: Yes
CUDA runtime version: 9.0.176
GPU models and configuration:
GPU 0: Tesla P40
GPU 1: Tesla P40
GPU 2: Tesla P40
GPU 3: Tesla P40
GPU 4: Tesla P40
GPU 5: Tesla P40
GPU 6: Tesla P40
GPU 7: Tesla P40

Nvidia driver version: 410.104
cuDNN version: /usr/lib/x86_64-linux-gnu/libcudnn.so.7.4.1

Versions of relevant libraries:
[pip] numpy==1.15.4
[pip] torch==1.1.0
[pip] torchvision==0.2.1
[conda] Could not collect
```
Repository: vscode
Issue: [folding] Fold All in selection
Labels: feature-request,editor-folding

Issue Type: <b>Feature Request</b>

Currently the Fold All works like a Fold All In FIle. So it would be great to make the Fold All applied only to the selection if there is any.

VS Code version: Code 1.30.1 (dea8705087adb1b5e5ae1d9123278e178656186a, 2018-12-18T18:12:07.165Z)
OS version: Windows_NT x64 10.0.17134


<!-- generated by issue reporter -->
Repository: PowerToys
Issue: Strong Search engine in "Open with" right click context menu
Labels: Idea-New PowerToy

As the title says, it would be really awesome to have some sort of search engine directly integrated in the "Open With" right click context  menu. 

Current Scenario: 
1) right click on the file you want to open with a custom .exe;
2) choose "Open With" and wait for the relative window to pop up;
3) check the list and  scroll down to the end;
4) click on "Find another app in this PC"
5) manually locate inside windows explorer the locaton of the .exe you want to use;
6) do everything again from the start if you want that program to be the default one.

Enanched Scenario:
1) right click on the file ---> open with
2) start typing the name of the .exe you want to use
3) select the .exe in the search's result list
4) flag the nearby checkbox if you want to make it default
Repository: flutter
Issue: Make data formatting initialization optional in material_localizations.dart 
Labels: framework,f: material design,a: internationalization,c: proposal,P2,team-design,triaged-design

## Steps to Reproduce

I'm implementing a custom AZ localization extends LocalizationsDelegate<MaterialLocalizations>. In my application I need date formatters, date formatting is already exists in Intl package for AZ locale. 

The problem is that if I init date formatting by initializeDateFormatting() than I see exception "Cannot write to unmodifiable Map", if I don't call initializeDateFormatting(), then I observe error "Invalid locale 'az_AZ'" (my custom locale) calling date formatters.

Some investigation shows that date formatters work perfect if i do following two things:
1. Comment line util.loadDateIntlDataIfNotLoaded();
in material_localizations.dart 
2. Call  initializeDateFormatting() from application code.

Is there any correct way to do (any of):
1. Make date formatters initialization for supported locales optional (in material_localizations.dart).
2. Convert some unmodifiable map to modifiable (sorry didn't investigated which one throws an exception described above)
3. Add custom locale to list of locales used in util.loadDateIntlDataIfNotLoaded() to initialize date formatters of custom locale same time as existing locales.

Issue is actually related to [https://github.com/flutter/flutter/issues/32090](url)
Repository: angular
Issue: useAnimation params doesn't support query and stagger params
Labels: type: bug/fix,area: animations,freq1: low,P4

# 🐞 bug report

### Affected Package
The issue is caused by package @angular/animations

### Is this a regression? I don't think so.

### Description
`query` parameter cannot be used as an animation parameter of `useAnimation()`. Same behavior for stagger.


## 🔬 Minimal Reproduction
https://stackblitz.com/edit/angular-animation-query-params

## 🔥 Exception or Error
<pre><code>
ERROR DOMException: "'{{ selector }}' is not a valid selector"
The provided timing value "{{stagger}}" is invalid.
</code></pre>


## 🌍  Your Environment

**Angular Version: 7.2.*
<pre><code>
Angular CLI: 7.3.3
Node: 10.15.0
OS: win32 x64
Angular:
...
Package                      Version
------------------------------------------------------
@angular-devkit/architect    0.13.3
@angular-devkit/core         7.3.3
@angular-devkit/schematics   7.3.3
@schematics/angular          7.3.3
@schematics/update           0.13.3
rxjs                         6.3.3
typescript                   3.2.4
</code></pre>
Repository: godot
Issue: Shader material visual bug when reading DEPTH_TEXTURE in the fragment function while using cull_disabled
Labels: bug,topic:rendering,confirmed

**Godot version:** 3.1.1

**OS/device including version:** Win 10 64 bit

**Issue description:** In the fragment function of a shader, if I read from DEPTH_TEXTURE in any way while I'm using the `cull_disabled` render mode, it makes the mesh render strangely. This happens in both GLES3 and GLES2.
![image](https://user-images.githubusercontent.com/32691832/58387601-2f545000-7fdf-11e9-90ce-0e6cd0cfd089.png)

The shader code I'm using in this example is:
```hlsl
shader_type spatial;
render_mode cull_disabled;

void fragment() {
	float depth = textureLod(DEPTH_TEXTURE, SCREEN_UV, 0.0).r;
}
```

**Minimal reproduction project:** [Shader Cull Issue.zip](https://github.com/godotengine/godot/files/3221132/Shader.Cull.Issue.zip)
Repository: TypeScript
Issue: Widen eligibility of Instrinsic Element names in JSX/TSX beyond lowercase names
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 read the FAQ first, especially the "Common Feature Requests" section.

-->

## Search Terms
JSX, compilation, Intrinsic Elements

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

## Suggestion
Allow more flexibility in defining Intrinsic Elements in JSX. The lowercase/uppercase convention works for React but doesn't represent the range of the spec. Any name should be allowed to be registered as an Intrinsic Element.

<!-- A summary of what you'd like to see added or changed -->

## Use Cases
JSX is just an XML like syntax language that gets compiled down to JavaScript. How that compilation works and what it outputs could be different depending on the library. Assuming case or character set to determine Intrinsic Elements outside the spec makes it much more difficult to support TypeScript for other JSX libraries.
<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->

## Examples
 Suppose a library wanted wanted to allow control flow to be precompiled using a $ symbol to prevent interference with the range of Value Elements the end user could use:
```jsx
<$ each={ items }>{ item => <div>{ item.title }</div>}</$>
```
This is perfectly valid JSX and could be compiled away before runtime.

Or how about something like NativeScript which uses a PascalCase syntax for it's intrinsic elements? It should be perfectly fine to set aside a few of these without having mess with per file imports or messing with Global scope.

I mean given the trend to compile down, and idea very much at the heart of JSX, it seems incredibly limiting to restrict this to a convention, no matter how popular it is. If the spec allows so should Typescript.

Yet today, you cannot set $ nor Button as Intrinsic JSX elements. I mean you can but they just get ignored.

I am unclear whether it's breaking. But I believe it would not be as it would just allow more elements to be eligible and not take anything away. Although I know there is some implicit behavior here (when there are no Intrinsic Elements declared). I suppose that could stay the same.

<!-- Show how this would be used and what the behavior would be -->

## 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: ant-design
Issue: <Upload /> component does not handle its inner input's `onFocus` events
Labels: Inactive,⌨️ Accessibility

- [x] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### Reproduction link
[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/embed/antd-reproduction-template-yjtz4)

### Steps to reproduce
1. Add an `<Upload />` component to any form or page
2. Try to trigger an `onFocus` callback using any method (either by clicking on the Upload component, or by pressing tab until it focuses, etc)
3. Any attached `onFocus` props will not be fired

### What is expected?
Form inputs need `onFocus` event callbacks; it's expected that any focusable input has it, and this has been standard input behavior for decades now. Tthe underlying file input allows all the regular methods of focusing, thus it is expected that the focus event callback would exist on `<Upload />` like it does with any other form field.

### What is actually happening?
`onFocus` callbacks are not fired for any of keyboard, mouse, or screen-reader focus events.

| Environment | Info |
|---|---|
| antd | 3.19.0 |
| React | 16.8.6 |
| System | macOS 10.14 |
| Browser | Chrome 74 |

---
Beyond it being expected/standard behavior, the absence of `onFocus` here adds unnecessary difficulty and extra code when implementing nice accessibility features, smooth client-side validations, and other misc dev tasks that don't really need to be more tedious than they already can be. XD


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: go
Issue: archive/tar: Does not handle extended pax values with nulls
Labels: NeedsDecision

### What version of Go are you using (`go version`)?

<pre>
go version go1.12.5 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes

### What did you do?

Read a tar file generated by `git archive`:

```shellsession
$ git clone https://github.com/SSW-SCIENTIFIC/NNDD.git
$ cd NNDD
$ git archive --format tar c21b98da2ca7f007230e696b2eda5da6589fe137 > nndd.tar
```

Alternatively you can fetch this archive directly from github: https://github.com/SSW-SCIENTIFIC/NNDD/tarball/c21b98da2ca7f007230e696b2eda5da6589fe137

If you try to read this with golang's `archive/tar` you will get a `tar.ErrHeader` on one of the entries. Here is a reproduction program:

```go
package main

import (
	"archive/tar"
	"compress/gzip"
	"fmt"
	"io"
	"log"
	"net/http"
	"os"
)

func main() {
	// Read tar from file if specified, otherwise fetch directly from github
	var r io.Reader
	if len(os.Args) > 1 {
		f, err := os.Open(os.Args[1])
		if err != nil {
			log.Fatal(err)
		}
		defer f.Close()
		r = f
	} else {
		resp, err := http.Get("https://github.com/SSW-SCIENTIFIC/NNDD/tarball/c21b98da2ca7f007230e696b2eda5da6589fe137")
		if err != nil {
			log.Fatal(err)
		}
		defer resp.Body.Close()
		gr, err := gzip.NewReader(resp.Body)
		if err != nil {
			log.Fatal(err)
		}
		defer gr.Close()
		r = gr
	}

	tr := tar.NewReader(r)
	for {
		_, err := tr.Next()
		if err == io.EOF {
			break
		}
		if err != nil {
			log.Fatal(err)
		}
	}
	fmt.Println("Successfully read tar")
}
```

If you try read the same file with bsdtar or gnutar they both read the whole tarball. bsdtar (depending on version) will log a warning to stderr but still extract the rest of the tarball.

The archive contains a symbolic link which instead of a path for value, contains a large value which includes null. The `validatePAXRecord` explicitly disallows null from appearing in the value for PAX values for links. This leads to `tar.Reader.Next()` returning `tar.ErrHeader`.

https://github.com/golang/go/blob/go1.12.5/src/archive/tar/strconv.go#L321-L322

I reported this to the git mailing list: https://public-inbox.org/git/CAMVcy0Q0TL6uEGR2NeudJrOiXdQ87XcducL0EwMidWucjk5XYw@mail.gmail.com/T/#u Read that issue for more details on the "bad" entry in the archive.

The opinion there seems to be that generating values that aren't C-strings for links is valid. Not all tarballs are destined for filesystems. And the latest bsdtar and gnutar do not complain about the value. gnutar will write the symbolic link value upto the first null.

### What did you expect to see?

I think any of the follow behaviours would be better:

- Be able to read the rest of the tar if encountering a recoverable error.
- Allow nulls in all PAX values.
- Truncate up to first null in PAX value. (consistent with gnutar)

### What did you see instead?

`tar.ErrHeader` on a tarball both bsdtar and gnutar can read.
Repository: realworld
Issue: NewUser definition email field has no format property set
Labels: v2

I've been looking at specs and noticed that `NewUser` definition `email` field has no `format` set:
https://github.com/gothinkster/realworld/blob/1d58c002fc3da07e386489ddfc2df2e85fa45bdf/api/swagger.json#L834:L836 .

Not having an email validation is bad for demonstration purposes because:
1. any realistic MVP would have such primitive validation;
1. having a user to be able to register with any string as an email is a clearly a bug;
1. validation logic is one of the pillars of the web interaction with users, this is one the things that you consider when looking at framework;
1. most of the frameworks provide validation for emails out of the box, so it does not actually cost anything to have it. 

So would you be interested in having PR that adds `"format": "email" ` for `NewUser` definition `email` field?
Repository: neovim
Issue: API: all buffer-related functions should ensure buffer is loaded
Labels: enhancement,api,complexity:low,has:plan,events

I'm working on a plugin for debugging functionality and trying to optimize some of the code paths. One problem we have is that there doesn't seem to be a way to load a buffer to a window and then run autocommands on it as if the user opened the buffer themselves.

Given a sequence of steps
* user triggers event with window 2 selected
* plugin calls `nvim_win_set_buf` for window 1 with some other buffer

you get a raw buffer loaded into window 1 with no syntax highlighting and no autocommands ran for other plugins that might depend on it. So the work around I've used is

    target_window.buffer = new_buffer
    previous_window = vim.current.window
    vim.current.window = target_window
    vim.command("doauto SomeAutocmd")
    vim.current.window = previous_window

Clearly this is a clumsy workaround. Something along the lines of

    target_window.buffer = new_buffer
    vim.api.run_autocommand("BufEnter", target_window.buffer)

would be much nicer.