sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Missing IntelliSense for generic parameters of decorators
Labels: Bug,Domain: Completion Lists

**TypeScript Version:**  3.7.3 and nightly

**VSCode Version:** 1.42.0-insider (and 1.41.1)

**Search Terms:**
- Generic decorators
- Decorator parameter suggestion

**Example Code:**
In order to simplify the code, I used `keyof T` as parameter type. It should accept any type expression.
```ts
function GenericDecorator<T>(propertyOfClass: keyof T) {
    return (target: T, prop: string, dec: PropertyDescriptor) => { ... }
}

export class TestClass {

    propertyOne: object = new Object();
    propertyTwo: string = "abcdef";
    propertyThree: number = 123456;

    @GenericDecorator("propertyOne")
    testFunction() { ... }

}
```

**Expected behavior:**
Getting valid parameters suggested by IntelliSense.
```ts
@GenericDecorator(..suggestion..)
```

**Actual behavior:**
Compiler is working as expected. Wrong values are underlined / marked as an error, for example:
```ts
@GenericDecorator("propertyOne") // works as expected
...
@GenericDecorator("Not_a_property_of_TestClass") // fails as expected
```

**Playground Link:**
[https://www.typescriptlang.org/play/?experimentalDecorators=true#code/LAKAZgr...](https://www.typescriptlang.org/play/?experimentalDecorators=true#code/LAKAZgrgdgxgLgSwPZQAQHECmVMCcEwAimMSuAhnGQDwAqAfABQAOuSzecAngPJgDCAG3IBnEQC5UAa0xckYVLQCUqAN6hUm1LkxwIuNIzjlcAc12TaAGlSt2kkXHxRTNgCYlJABTYdc3YhEYfGYqXBUAXno1VABfUHiQUEwAD2YyOFQYYTFFTEchURE1UA0tOz9uHhxJJAAjACsSTIjUHAB3VB5G5sYlAG4yzQrOLlp2pAcnBBdUVoAicjqYDzB5wZAtW19R2gALHUxJKAgAWzq8OdQARgAmAGYAFgBWADYNodQAASwcfCISGRKGRGPMRv4xhN5kpPhNcFIZqZiKQKGE+iUkpstIktp8ftg8ARkUC0fMAHJIOAAfXIVPB3Cp8iptHycEKYmhnyglIA6mQES5iaiQSp1JitolEkA)

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
N/A

If needed, I can add some example use cases for this request.
Repository: TypeScript
Issue: VSCode JSDoc doesn't recognize members that are classes from default imported object.
Labels: Needs Investigation

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!--
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
-->
**VSCode Version:**  1.41.1

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
jsdoc export import class object type

**Code**

a.js
```js
export default class A {
	constructor() {
		this.m = 2;
	}
}
```

b.js
```js
export default class B {
	constructor() {
		this.n = 4;
	}
}
```

lib.js
```js
import A from './a';
import B from './b';

const Lib = {
	A,
	B
};

export default Lib;
```

app.js
```js
import Lib from './lib';

/**
 * @param {Lib.A} a
 * @param {Lib.B} b
 */
function foo(a, b) {
}

function bar() {
	const a = new Lib.A();
	foo(new Lib.A(), new Lib.B());
}
```

**Expected behavior:**
When I hover over the `Lib` in the `@param` jsdoc of app.js `foo` function, the tooltip should read something similar to what happens in the bar function:

```
(alias) const Lib: {
    A: typeof A;
    B: typeof B;
}
import Lib
```

And when I hover over the `Lib.A` in the same area, the tooltip should read something similar to what happens in the bar function:

```
(property) A: new () => A
```

**Actual behavior:**
When I hover over the `Lib` or `Lib.A` in the `@param` jsdoc of app.js `foo` function, the types are `any`, not being recognized as a particular type.

The hovering over types in actual javascript within the bar function works great.

**Related Issues:** <!-- Did you find other bugs that looked similar? -->

I searched, but I'm not seeing any similar issue. Maybe I'm missing something obvious?

**Notes**
I don't believe I saw this behavior in earlier versions of VSCode (maybe even October or September 2019 releases). My code base hasn't changed, but the editor has been upgraded.
Repository: kubernetes
Issue: Suggest `listType=map` if we can guess good key options
Labels: sig/api-machinery,lifecycle/frozen,wg/api-expression

We currently fail with an error when generating the openapi if `listType` is missing on lists, and that's a good thing, but we can be even more useful and suggest `listType=map` along with `listMapKeys=...` if we can figure out a good key name.

For example, if we detect that the list is a list of structs that have a field name, that list is probably a map with name as the key, we should help the user and let them know.

This can (and probably should)  happen in multiple places:
- [ ] kube-openapi generation. When we generate the kube-openapi, we could replace the existing error by a more useful error suggesting the map value.
- [ ] in kubebuilder, we could also suggest the key in kube-builder as we parse the tags.
- [ ] For CRDs, we could update the status to mention this is a possible useful configuration.
Repository: flutter
Issue: Test that embedders can post native thread tasks recursively.
Labels: a: tests,engine,P2,team-engine,triaged-engine

Not caught earlier because of LUCI [not exercising AOT modes](https://github.com/flutter/flutter/issues/49733).
Repository: go
Issue: x/tools/gopls: replace "verboseOutput" with a log label
Labels: gopls,Tools

Rather than having the `"verboseOutput"` setting, we should tag some log messages with a verbose label.
Repository: terminal
Issue: InputEngineTest::RoundTripTest Fails
Labels: Product-Conpty,Area-VT,Issue-Task

Roses are red,
Violets are blue,
InputEngineTest::RoundTripTest fails,
So I left a TODO.
Repository: godot
Issue: intersect_ray() ignores any TileMap cells with collision polygons after a call to TileMap.set_cell()
Labels: bug,confirmed,topic:physics,regression,topic:2d

**Godot version:** 3.2

**OS/device including version:** Manjaro Linux 18.1.5

**Issue description:** If you change a cell (on a TileMap) from a tile with collision polygon to a tile without collision polygon, the next call to Physics2DDirectSpaceState.intersect_ray() will not collide with any TileMap cells. This only happens if a call to intersect_ray() is made during next _physics_process tick right after set_cell() call had happened on a _process() tick.
![Peek 2020-01-30 02-36](https://user-images.githubusercontent.com/33941345/73409974-839b9680-4309-11ea-9712-daf7536beea8.gif)
 I believe it is a regression, since this does not happen on version 3.1.2.

**Steps to reproduce:**
1) During _process() tick, call TileMap.set_cell() and change a cell from a tile with collision polygon to a tile without.
2) On the next _physics_process() tick, call Physics2DDirectSpaceState.intersect_ray() directed at a TileMap cell with a collision polygon.

**Minimal reproduction project:**
[ReproductionProject.zip](https://github.com/godotengine/godot/files/4131627/ReproductionProject.zip)
Repository: flutter
Issue: Desktop app frame rate isn't synced to display
Labels: engine,c: performance,platform-mac,platform-linux,a: desktop,perf: speed,has reproducible steps,P2,found in release: 3.19,found in release: 3.22,team-macos,triaged-macos

I'm running on a 120hz monitor, I've scheduled a persistent frame callback and can see that I get ~60fps. It would be great if Flutter could use something like CADisplayLink on MacOS to sync frame rendering with the display. 

Gist of a simple app showing this: https://gist.github.com/luigi-rosso/0e3ed273e52764bf1d7bdacca49cccd2

![image](https://user-images.githubusercontent.com/454182/73402560-713a4200-42a2-11ea-87b3-2680aea714c3.png)

I can see in various [sites](https://jsfiddle.net/greggman/ULxVp/), apps, and games that the display is actually refreshing at 120hz.
![image](https://user-images.githubusercontent.com/454182/73402973-4dc3c700-42a3-11ea-90d0-9c30b0274a5b.png)

Previously filed here: https://github.com/google/flutter-desktop-embedding/issues/656

Fix status:
* [X] Windows (note: has the right rate, but may be out of phase)
* [x] macOS
* [ ] Linux
Repository: tensorflow
Issue: Ability to calculate projected memory usage for a given model
Labels: stat:awaiting tensorflower,type:feature,comp:keras,TF 2.1

<em>Please make sure that this is a feature request. As per our [GitHub Policy](https://github.com/tensorflow/tensorflow/blob/master/ISSUES.md), we only address code/doc bugs, performance issues, feature requests and build/installation issues on GitHub. tag:feature_template</em>


**System information**
- TensorFlow version (you are using): 2.1
- Are you willing to contribute it (Yes/No): Yes, but I would likely need assistance/guidance



**Describe the feature and the current behavior/state.**
The closest feature I can find to this is `tf.keras.Model.summary()`. This feature calculate the trainable and non-trainable parameters per-layer but doesn't attempt to calculate any memory usage statistics.

The proposed feature would extend `tf.keras.Model.summary()` by also calculating memory requirements per-layer and for the complete model. If multiple compute devices are used in the model then a per-device memory breakdown would also be useful.

**Will this change the current api? How?**
This could either just add functionality to `tf.keras.Model.summary()` without changing the interface, or it could add extra parameters to `tf.keras.Model.summary()`. Alternatively, a new function could be added, whatever is deemed most appropriate.

**Who will benefit with this feature?**
Anyone with a desire to get an idea about how much memory their model will need for either training or inference. It should be possible for someone to determine whether the model they wish to train/evaluate will fit into RAM (either system of GPU) that they have available.

**Any Other info.**
My focus is on the `tf.keras.Model.summary()` API, but this feature should probably be extended to other means of model creation.
Repository: puppeteer
Issue: request.headers() does not give all headers that are used when making the request
Labels: bug,upstream,confirmed,P3

```js
const browser = await puppeteer.launch();
const page = await browser.newPage();

page.on('request', async (request) => {
  await request.headers();
});

await page.goto('http://gajus.com');

```

just gives:

```
'upgrade-insecure-requests': '1',
'user-agent': 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/79.0.3945.0 Safari/537.36',
'sec-fetch-user': '?1'

```

whereas the actual headers include additional headers such as: accept, accept-language and accept encoding.

Related:

* https://github.com/puppeteer/puppeteer/issues/3436 (closed without a solution)
Repository: rust
Issue: ExitCodeExt: Please provide an extension method for the "raw" exit code
Labels: T-libs-api,C-feature-request

On Unix platforms, `ExitCode` wraps the exit code received from the system, and provides helper functions to distinguish "exited normally with exit code" from "exited with signal number". However, some command-line tools (those that execute another program) want to exit with the same exit status as the program they run. Please consider providing a function to obtain the "raw" exit status, suitable to pass directly to `sys::process::exit`.
Repository: TypeScript
Issue: `lib.d.ts` isn't ordered appropriately for signature help
Labels: Bug

![image](https://user-images.githubusercontent.com/972891/73424580-13c6e500-42e4-11ea-9e76-303c09efffc9.png)

This extremely broad signature help is occurring because `lib.d.ts` is ordered from oldest to newest. Unfortunately that means that users end up getting complex signatures that they never cared about. Even if we came up with a *Matcher* interface, it's not clear that that's even useful.
Repository: TypeScript
Issue: Define protocol type names for well-known symbols
Labels: Suggestion,Experience Enhancement

![image](https://user-images.githubusercontent.com/972891/73424783-acf5fb80-42e4-11ea-8932-fa12449e4143.png)

This is pretty hard to grok. Maybe we should have a named type for types like

```
{
    [Symbol.match](string: string): RegExpMatchArray;
}
```

It's not totally clear what we'd call these - they're awkward. Something like `RegExpMatcher`?
Repository: go
Issue: cmd/compile: prove misses obvious facts about constants
Labels: Performance,NeedsInvestigation,compiler/runtime

I noticed that left shifts by a constant are not being marked as bounded by prove. Prove consults ft.limits, but ft.limits doesn't contain limits for constants. Something similar happens for some other ops with easy limits.

This is pretty straightforward to fix: Write a wrapper around ft.limits accesses that generates limits in cases like these.

I have a prototype CL of this, and it mostly helps. But before it can be mailed, I need to investigate and fix a few more minor regressions from it. (The compiler is quite sensitive to the order in which optimizations occur.)

And before doing that, I wanted to check in about whether this was even the right kind of fix here.

cc @zdjones @rasky
Repository: pytorch
Issue: Error tracing custom autograd.Function
Labels: oncall: jit,triaged

## 🐛 Bug

I got an error when I tried to use jit to trace my autograd Function. In previous Pytorch versions(1.1.0), this works, but recently I updated to 1.4.0, and this stopped working. I'm not exactly sure which version exactly did this stopped working. 
## To Reproduce

Steps to reproduce the behavior:

1. Make sure you have Pytorch1.4.0
2. Make a custom autograd Function. In  my case, I'm using this one
```
class raw(autograd.Function):
    @staticmethod
    def forward(ctx, inp):
        ctx.a = (inp * inp + 1).reciprocal()
        ctx.b = ctx.a.sqrt()
        return inp * ctx.b

    @staticmethod
    def backward(ctx, grad_output):
        return grad_output * ctx.a * ctx.b
```
3. Trace this Function.
```
from torch import jit
jit.trace(raw.apply, example_inputs=tc.randn(1))
```
4. The error should orginate from the line of tracing and look like this:
```
......................
    jit.trace(raw.apply, example_inputs=tc.randn(1))
  File "...\Python37\lib\site-packages\torch\jit\__init__.py", line 903, in trace
    name = _qualified_name(func)
  File "...\Python37\lib\site-packages\torch\_jit_internal.py", line 696, in _qualified_name
    "__module__ can't be None.".format(name))
RuntimeError: Could not get qualified name for class 'apply': __module__ can't be None.
```

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior
I expect the tracing to work like how the previous versions did. 

<!-- A clear and concise description of what you expected to happen. -->

## Environment

Please copy and paste the output from our
[environment collection script](https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py)
(or fill out the checklist below manually).

You can get the script and run it with:
```
wget https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py
# For security purposes, please check the contents of collect_env.py before running it.
python collect_env.py
```

PyTorch version: 1.4.0+cpu
Is debug build: No
CUDA used to build PyTorch: None

OS: Microsoft Windows 10 Home
GCC version: Could not collect
CMake version: Could not collect

Python version: 3.7
Is CUDA available: No
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA

Versions of relevant libraries:
[pip3] numpy==1.16.3
[pip3] torch==1.4.0+cpu
[pip3] torchvision==0.5.0+cpu
[conda] Could not collect

## Additional context
I'm bad at using Github so if I missed something please tell me :)
<!-- Add any other context about the problem here. -->


cc @suo
Repository: go
Issue: strings/bytes: LastIndexByte is significantly slower than IndexByte
Labels: Performance,help wanted,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.13.1 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?
yes.

### What operating system and processor architecture are you using (`go env`)?
Both Linux/MacOS

### What did you do?

I was using multipart.NewReader() to process multi-part responses from Cloud REST API.
It turned out that ~1/3 of profile is spent in mime/multipart/multipart.go :: scanUntilBoundary() -> bytes.LastIndexByte().

After looking into it, it is no wonder as bytes.LastIndexByte() is not using any optimisations and compiled into simple loop iterating over bytes, no REP SCASB instruction is used on Intel (nor SSE).

### What did you expect to see?

bytes.LastIndexByte() to use SSE or at least REP SCASB optimised code.

### What did you see instead?

simple byte to byte loop in asm code.
Repository: go
Issue: x/website/cmd/golangorg: Add Content Security Policy
Labels: NeedsFix

CSP is an important protection against some of the higher risk web vulnerabilities and the official Go website doesn't currently adopt it.

Moreover CSP is a internal requirement for any website hosted on *.google.eTLD and the Go website is currently also hosted on golang.google.cn.

I can take care of fixing this or finding someone that can work on it if the proposal is accepted.

/cc @dmitshur @andybons
Repository: rust
Issue: Exponential trait selection when compiling a crate using combine 4
Labels: A-trait-system,I-compiletime,T-compiler,C-bug

Originally reported in https://github.com/Marwes/combine/issues/284 . It appears that the changes made between version 3 and 4 in https://github.com/Marwes/combine . Made trait selection exponential in some cases. The main change that I would suspect causing this is that combine-3 had `Input` as an associated type whereas combine-4 uses a type parameter.

The following minimized repo reproduces the slowdown, removing a few arguments from the `choice!` macro makes it compile quickly https://github.com/Marwes/combine-slow-compile . The commit before `master` contains a version with combine-3 which compiles instantaneously (after dependencies are compiled). (diff https://github.com/Marwes/combine-slow-compile/commit/21cf38a5429e32a703c2bc2ea02cbcbaf2985b01)

![Screenshot from 2020-01-30 10-51-55](https://user-images.githubusercontent.com/957312/73438941-24607500-434f-11ea-8077-a336fbc90e24.png)
Repository: node
Issue: Macos Derived exceptions seem to be affected by RTTI settings in the gypfile
Labels: build,macos

I don't know whether it will affect any nodejs user, but since it may and I found it out the hard way I'm putting this here:
```
'xcode_settings': {
'GCC_ENABLE_CPP_RTTI': 'NO'
}
```
will lead to that derived exeptions in a program linked against that library may not work anymore; so this tiny test programm linked against that library:
```
#include <stdexcept>
#include <iostream>
int main(int argc, char* argv[]) {

      std::cout << "start test" << std::endl;
      try {
                   std::cout << "throw The Error" << std::endl;
                   throw std::runtime_error(std::string("test"));
      }
      catch (std::exception const& x) {
        std::cout << "catch error" << std::endl;
      }
      return 1;
}
```
may result in `catch error` not being printed, but a runtime exception happening. 

If you don't find this usefull - simply close it.
Repository: pytorch
Issue: MKLDNN doesnt work and is slower than normal cpu mode
Labels: triaged,module: mkldnn

## 🐛 Bug

MKLDNN seems not to have any effect on runtime performance. Its even some times, slower than normal cpu mode!
The issue exists both on 1.3.1 and 1.4.0. 
## To Reproduce

Steps to reproduce the behavior:

Run this on a supporting platform such as Linux (e.g. ubuntu 18.04)

```python
import torch
print(f'Pytorch version : {torch.__version__}')
print(*torch.__config__.show().split("\n"), sep="\n")

from torchvision import models
from torch.utils import mkldnn as mkldnn_utils
import time 

def forward(net, use_mkldnn=False, iteration=1, batch_size=10):
  net.eval()
  batch = torch.rand(batch_size, 3,224,224)
  if use_mkldnn:
    net = mkldnn_utils.to_mkldnn(net)
    batch = batch.to_mkldnn()

  start_time = time.time()
  for i in range(iteration):
      net(batch)
  return time.time() - start_time

net = models.resnet18(False)
iter_cnt = 100
batch_size = 1

no_mkldnn   = forward(net, False, iter_cnt, batch_size)
with_mkldnn = forward(net, True,  iter_cnt, batch_size)

print(f"time-normal: {no_mkldnn:.4f}s")
print(f"time-mkldnn: {with_mkldnn:.4f}s")
print(f"mkldnn is {with_mkldnn/no_mkldnn:.2f}x slower!")

```
Or simply run this on a [Google Colab : ](https://colab.research.google.com/drive/1OKBSZY5rc5w9QIKfyo5trS3JTgBEvpPp) 

## Expected behavior

Should be 10x or more faster than the normal CPU mode. 

## Environment

 - PyTorch Version (e.g., 1.0): 1.4.0+cpu
 - OS (e.g., Linux): 18.04.3 LTS
 - How you installed PyTorch (`conda`, `pip`, source): pip
 - Build command you used (if compiling from source): - 
 - Python version: tested on both 3.6 / 3.7.3
 - CUDA/cuDNN version: tested both on gpu and cpu builds: 10.1.243 / 7.6.5
 - GPU models and configuration: None
 - Any other relevant information: -


cc @gujinghui @PenghuiCheng @XiaobingSuper @jianyuh
Repository: flutter
Issue: video_player: Autoplay support
Labels: c: new feature,platform-web,p: video_player,package,P3,team-web,triaged-web

Im aware browser might block autoplay videos but this is only partially true.
This is also stated in the article youve referenced:

> Chrome's autoplay policies will change in April of 2018 and I'm here to tell you why and how this is going to affect **video playback with sound**
[https://developers.google.com/web/updates/2017/09/autoplay-policy-changes](https://developers.google.com/web/updates/2017/09/autoplay-policy-changes)

Coming from webdev, adding `playsinline` and `muted` attributes will enable autoplaying in most browsers.

> Chrome's autoplay policies are simple:
>    - Muted autoplay is always allowed.
> [...]

## Use case
Many

## Proposal

Autoplay videos.