sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: incorrect return type of NodeListOf.item()
Labels: Suggestion,Awaiting More Feedback

typescript version: 3.9.2

method `item()` of nodelist should return a node or **null** (if index out of range)
(see: https://developer.mozilla.org/en-US/docs/Web/API/NodeList/item)

Typescript behavior is incorrect (lib.dom.d.ts)
```typescript
interface NodeListOf<TNode extends Node> extends NodeList {
    item(index: number): TNode;
}
```
Repository: nvm
Issue: Feature Request: install a custom local build of nodejs
Labels: installing node,feature requests

First: I love `nvm`, its amazing, I use it all the time. :smile_cat: 

I'm experimenting with building forks of nodejs.
I'd like to be able to add these builds to nvm's locally installed versions.

here's what I imagine the usage looks like 
```bash
nvm install-local 'xyz-v1.0.0' ./out/Release
nvm which current
# ~/.nvm/versions/node/xyz-v1.0.0/bin/node
```

I'd expect it to copy the built release so that it doesn't change when I rebuild.
I don't have strong opinions about how the version number works.

Is this currently possible? if not, does this seem reasonable?
Repository: godot
Issue: c_unescape() does not work for Unicode "\u" escape
Labels: bug,topic:core

**Godot version:**
Tested in 3.2.1
**OS/device including version:**
Windows 10
**Issue description:**
GDScript String method c_unescape() does not work for Unicode "\u" escape. However, it does work for other escapes.
**Steps to reproduce:**
```
func _ready():
	print("\u0054") # prints "T"
	var test := "\\u0054"
	print(test) # prints "\u0054"
	print(test.c_unescape()) # prints "\u0054"
	var test2 := "tab\\ttab"
	print(test2) # prints "tab\ttab"
	print(test2.c_unescape()) # prints "tab	tab"
```
"\u0054" also is not unescaped when it is part of localized text, which I'm guessing is the same issue.

Probably different but tangential issue: I noticed that "\U" gives an editor error "parse error: invalid escape sequence". This is the standard C escape sequence for Unicode characters >0xFFFF (according to Wiki). Are these not supported in Godot at this time? I'd be much obliged if someone informed me so I can open either a feature request or doc issue (or both).
Repository: deno
Issue: Deno ListenOptions hostname does not bind to ipv6 by default
Labels: suggestion

When a `hostname` is not provided to a method the ListenOptions defaults it to `0.0.0.0`, the process binds to only ipv4 address and for binding an ipv6 address it requires explicit mentioning via the `hostname`, for example, the `hostname` should be set to `[::1]` to bind it to an ipv6 address and so on. Need to check whether to bind the ipv6 address by default, or keep the same functionality as of now.
Repository: TypeScript
Issue: Much better comment preservation
Labels: Needs Investigation

some comments are removed (even even removeComments to false)


**TypeScript Version:**  Version 3.9.1-rc

**Search Terms:**
Much better comment preservation

**Code**

```ts
// my comment 1
import { something } from './somefile.js';
// my comment 2
declare let test1: something;
let test = new something( {} );

// also
let item = [
    // my comment 3
        { a: 0 },
	{ a: 0 },
	{ a: 0 },
    // my comment 4
];

```

```js
**Expected behavior:**
// my comment 1
import { something } from './somefile.js';
// my comment 2
let test = new something( {} );

// also
let item = [
    // my comment 3
    { a: 0 },
    { a: 0 },
    { a: 0 },
   // my comment 4
];
```

**Actual behavior:**
```js
// my comment 1
import { something }from '/lib/backend/./somefile.js';
let test = new something({});

// also
let item = [
    // my comment 3
    { a: 0 },
    { a: 0 },
    { a: 0 },
];
```

**Related Issues:**
sound like previous bugs report but not.
#1665
#16727
Repository: go
Issue: cmd/compile: generated DWARF triggers objdump warning for large uint64 const
Labels: NeedsInvestigation,compiler/runtime


### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.14.2 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes.

### What did you do?

The Go compiler is emitting DWARF information for certain constants that is causing warnings from 'objdump --dwarf', details below.  This is a comparatively minor problem (since as far as I can tell the debugging experience is not impacted) but the warning makes it a pain to read objdump output while looking for other problems (as a Go developer, not a Go user).

Code:

```
package main

import "fmt"

const neg64 uint64 = 1 << 63

func main() {
	fmt.Println(neg64)
}
```

Symptoms:

```
$ go build neg64.go
$ objdump --dwarf=info neg64 >  /dev/null
objdump: Error: LEB value too large
objdump: Error: LEB value too large
objdump: Error: LEB value too large
objdump: Error: LEB value too large
objdump: Error: LEB value too large
objdump: Error: LEB value too large
```

### What did you expect to see?

clean objdump output with no warnings

### What did you see instead?

LEB value too large warnings.

DWARF output excerpt:

```
 <1><79f2b>: Abbrev Number: 9 (DW_TAG_constant)
    <79f2c>   DW_AT_name        : main.neg64
    <79f37>   DW_AT_type        : <0x3bf51>
    <79f3b>   DW_AT_const_value :objdump: Error: LEB value too large
 -9223372036854775808
```

where the type in question is listed as

```
 <1><3bf51>: Abbrev Number: 27 (DW_TAG_base_type)
    <3bf52>   DW_AT_name        : uint64
    <3bf59>   DW_AT_encoding    : 7	(unsigned)
    <3bf5a>   DW_AT_byte_size   : 8
    <3bf5b>   Unknown AT value: 2900: 11
    <3bf5c>   Unknown AT value: 2904: 0xdec0
```

I think what's happening here is that the abbrev entry looks like this:

```
    DW_TAG_constant    [no children]
    DW_AT_name         DW_FORM_string
    DW_AT_type         DW_FORM_ref_addr
    DW_AT_const_value  DW_FORM_sdata
    DW_AT value: 0     DW_FORM value: 0
```

Note the DW_FORM_sdata payload -- this is a signed value. I am assuming that objdump is interpreting this combination as something along the lines of "take this signed value and put it into an 8-byte signed container" (at which point it decides it can't fit).

A possible workaround would be to use a different abbrev with FORM_udata instead.

It's also arguable that we should instead file a binutils bug and ask them to change the objdump behavior -- you can make case that the Go DWARF is ok and it should be getting the "signedness" from the destination type and not the form  (just depends on how you interpret things).
Repository: rust
Issue: clippy is not installed to destination dir if 'tools' config variable not explicitly defined. 
Labels: T-bootstrap

Found whilst performing a extended tools release bootstrap build on aarch64:

Unless 'tools' is explicitly specified in config.toml with an extended build config, clippy is not installed, it is explicitly skipped as it does not appear in builder.config.tools (src/install.rs, Line: Line: 158, Line: 222)
Clippy is actually built for stage 2, but not installed by install.py.
Of the default extended tools built when extended-tools are enabled, only clippy seems to behave like this.

If this is intended behaviour, then a note in the config.toml indicating this would be helpful :-)

This occurs using the default channel (dev) in config.toml, constructed only using ./configure --enable-full-tools --prefix=$RUST_TOOLCHAIN_DIR --sysconfdir=$RUST_TOOLCHAIN_DIR on aarch64 native host.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":null}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: flutter
Issue: GeneratedPluginRegistrant.java still no re-generated using FlutterEngine still using PluginRegistry
Labels: platform-android,engine,a: quality,P2,team-android,triaged-android

I have a real project that already published on Play Store and App Store, but when I want to use [file_picker](https://pub.dev/packages/file_picker) it's giving me an [error](https://github.com/miguelpruivo/flutter_file_picker/issues/225).

As mentioned, the solution it's to `upgrading pre 1.12 Android projects` and I follow this [instruction](https://github.com/flutter/flutter/wiki/Upgrading-pre-1.12-Android-projects).

I also already add
```
<meta-data
            android:name="flutterEmbedding"
            android:value="2" />
```
Already update splash screen behavior and etc. Also on MainActivity.kt use this code.
```
package com.rifafauzi.fluttertestcamera

import androidx.annotation.NonNull;
import io.flutter.embedding.android.FlutterActivity
import io.flutter.embedding.engine.FlutterEngine
import io.flutter.plugins.GeneratedPluginRegistrant

class MainActivity: FlutterActivity() {
    override fun configureFlutterEngine(@NonNull flutterEngine: FlutterEngine) {
        GeneratedPluginRegistrant.registerWith(flutterEngine);
        // My logic native side here
    }
}
```

But after I upgrading that, I get the error too:
```
Type mismatch: inferred type is FlutterEngine but PluginRegistry! was expected
```

That because of my `GeneratedPluginRegistrant` not re-generate so still using `PluginRegistry` not using `FlutterEngine` like in `pre 1.12 Android projects` or if we create `new project` will generating `GeneratedPluginRegistrant` with `FlutterEngine` not with `PluginRegistry`.

So my question is, how to re-generate `GeneratedPluginRegistrant` class so I can use new classic with `FlutterEngine`?

Fyi, I already run `flutter clean`, `clean project`,  `rebuild project`, and also `Invalidate Cache and Restart` but still not re-generate.
Repository: go
Issue: x/build: reduce ambiguity in long test of main Go repo
Labels: Builders,NeedsInvestigation

Taking into account the build infrastructure at [build.golang.org](https://build.golang.org), local development, and issues such as #26473, #34707, I understand we currently have the goal of having good support for two well-known testing configurations (for a given GOOS/GOARCH pair) for the main Go repository:

- Short, as implemented by `all.bash`
  - target of 3-4 minutes, acceptable to skip slow tests as implemented by `go test -short`
- Long, as implemented by `-longtest` post-submit builders (e.g., `linux-amd64-longtest`)
  - no goal of skipping tests for performance reasons

While investigating #29252, I found that there is some ambiguity in what it means to test the main Go repo in long mode. It's not easy to say "in order to run a long test, do this" and have a predictable outcome. We currently say "run `all.bash` and `go test std cmd`" in some places, but there's room for improvement.

We want to ensure long tests are passing for Go releases. To support that goal, I think it will helpful to reduce ambiguity in what it means to run a long test on the Go repo.

This is a high level tracking issue for improvements in this area, and for any discussion that may need to happen.

/cc @andybons @cagedmantis @toothrot @golang/osp-team @bradfitz @rsc
Repository: go
Issue: github: consider downscoping "GitHub Editors" access to Triage role
Labels: Security,Builders,NeedsInvestigation,Community

The Go project offers access to a set of people to edit metadata on GitHub issues, in order to help with [gardening](https://golang.org/wiki/Gardening). This access is documented at https://golang.org/wiki/GithubAccess#editors.

Back when the "go-approvers" group was created, GitHub did not offer granular access levels, it was either Read (no access to triage), Write (access to triage and push), Admin. We used Write since it was the most fitting option.

The GitHub repository at https://github.com/golang/go is a mirror of the canonical repository at https://go.googlesource.com/go where code review happens, and any changes to it are automatically overwritten by [`gitmirror`](https://pkg.go.dev/golang.org/x/build/cmd/gitmirror). However, accidents happen occasionally, and people may unintentionally create new branches (e.g., see https://groups.google.com/d/msg/golang-dev/EqqZf5kTRqI/9BEDmjHwBwAJ).

By now, GitHub seems to offer more granularity in access controls, including a "Triage" role:

![image](https://user-images.githubusercontent.com/1924134/81849046-f3820580-9523-11ea-94b2-44a814c9605b.png)

It's documented in more details at https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization.

We should investigate and confirm whether it's safe to downscope the go-approvers team to Triage access without causing unintended inconvenience to people who rely on it, and if so, apply the change.

/cc @golang/osp-team @katiehockman @FiloSottile
Repository: pytorch
Issue: No MKL Compatible Conda installation for PyTorch 1.5
Labels: module: binaries,triaged,module: mkl

## 🚀 Feature
Right now having the conda nomkl package installed is a comfortable way to ensure that numpy is linking to openblas instead of Intel mkl, which is (in my experience) slower for AMD processors. If the no mkl package is installed, the conda pytorch installation resolves to an older pytorch version.

I.e. the command (in an otherwise empty conda environment)
`conda install pytorch torchvision cudatoolkit=10.2 -c pytorch`  

installs WITHOUT the nomkl package
`pytorch            pytorch/linux-64::pytorch-1.5.0-py3.7_cuda10.2.89_cudnn7.6.5_0`

and WITH the nomkl package
`pytorch            pytorch/linux-64::pytorch-1.0.0-py3.7_cuda9.0.176_cudnn7.4.1_1`

It would be great to have a conda compatible installation with nomkl, as AMD processors have gotten good in terms of # of fast cores and value. So if it would not require to much effort it would be great to have. And also a bit of documentation on how to ensure linking to openblas instead of mkl would be great as AMD processor have become more widespread in recent years.

## Alternatives
To get pytorch 1.5 with nomkl, one can simply install pytorch 1.5 via pip. 

cc @ezyang @seemethere
Repository: flutter
Issue: Allow copying engine artifacts before starting native build tool
Labels: tool,platform-windows,platform-linux,a: desktop,a: build,P3,team-tool,triaged-tool

Currently, for all of the desktop builds, we trigger the native build (Xcode, make, etc.) and that eventually calls into the backend script that copies engine artifacts like the library and the C++ client wrappers.

I'm in the process of converting Linux (and maybe Windows) to CMake, and with CMake the best option is to have the build files live next to the things they are building; in the case of then engine artifacts it would not only make the build structure cleaner and more modular, but it would mean that we could retain long-term control over those files. For instance, the client wrapper targets could be updated if the set of client wrapper files changed, without breaking existing consumers.

However, the CMake step is the very first step in the build, so we can't call it without already having all the `CMakeLists.txt` files in place. In order for them to live with the artifacts, we'd need to be able to trigger the artifact copying earlier, from, e.g., build_linux.dart, just before doing CMake generation.

/cc @jonahwilliams
Repository: angular
Issue: Angular Module instance never get destroyed
Labels: type: bug/fix,feature,area: router,core: NgModule,router: lazy loading,needs: discussion,feature: under consideration

No matter what we do lazy loading or eager loading Angular Module instance never gets destroyed.

When we route across components or use *ngIF Components get destroyed and recreated but its not the same case when we navigate from one module to another.

While lazy loading every module gets loaded dynamically. Also, the instance get created but that instance never gets destroyed.

To check the same I put the breakpoint in Module constructor.

Anybody know the reason for such behavior. I feel it bad because all services registered on those modules get remain forever then too.

I felt like it a bug than a feature request.
Repository: kubernetes
Issue: Add a `Plan` kind
Labels: sig/api-machinery,kind/feature,lifecycle/frozen,wg/api-expression

**What would you like to be added**:

A way (through a `Plan` kind?) to save a list of changes to be applied later, with
the guarantee to not cause any additional conflicts/resource addition/resource deletion.

The workflow would look like:

- Generate a `Plan` with `kubectl diff --recursive --server-side -oyaml -f manifests.yaml > plan.yaml`
  - This would be even more useful if/when `kubectl diff` supports `--prune` and `--selector` flags (that behave like their kubectl apply counterparts).
- Apply it with `kubectl apply --server-side -f plan.yaml`

**Why is this needed**:

Reviewing a change before applying it (`kubectl apply --dry-run` or `kubectl diff`) currently does not give confidence that the real change made to the cluster will match what was expected.

For example, if I want to update an already deployed resource:

- I run `kubectl diff` and validate that the output corresponds to what I expect
- Meanwhile, the resource is deleted in the cluster (I am not aware of that)
- I run `kubectl apply` expecting to update a field, but I actually create a resource

The same can lead to unexpected resource deletion (with `--prune` flag) or unexpected update of fields not owned by my workflow (with `--force-conflicts`).

This is especially true in a GitOps workflow where the diff is automatically printed in the PR to help the reviewer and the apply can take place several hours later.

Having a structured "plan" is also useful:

- For automated policy enforcement, e.g. using OPA
- To make `kubectl apply --recursive --prune` safer

/kind feature
/sig api-machinery
/wg api-expression
Repository: create-react-app
Issue: Allow full URL with hostname/port for PUBLIC_URL in development
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?

Recently there was a change so that PUBLIC_URL is no longer ignored in development mode. This is a great change, however it seems limited in that PUBLIC_URL in development can only be a path 
 while environments outside of development can be full URLs with hostname/port, etc.

### Describe the solution you'd like

<!--
  Provide a clear and concise description of what you want to happen.
-->

Please allow for PUBLIC_URL to specify a URL in development, not just a path.

### Describe alternatives you've considered

<!--
  Let us know about other solutions you've tried or researched.
-->

Only other solution we have to work with is change our entire server-side setup (quite involved) or utilize patch-package (ew)
Repository: flutter
Issue: "resizeToAvoidBottomInset property" Documentation  should have a video to demonstrate how it changes the view
Labels: framework,f: material design,d: api docs,d: examples,c: proposal,team-design,triaged-design

In the [documentation page](https://api.flutter.dev/flutter/material/Scaffold/resizeToAvoidBottomInset.html), there must be a video to show how changing the boolean value of "resizeToAvoidBottomInset" changes the view in the actual app.
For example, such a demonstration must be added ⬇
![Screenshot (177)](https://user-images.githubusercontent.com/55295915/81847650-839a6c00-9571-11ea-8658-ed5e807fa5c3.png) 
https://flutter.github.io/assets-for-api-docs/assets/material/app_bar.mp4
Repository: pytorch
Issue: [JIT] torch.tensor needs a Tensor overload
Labels: oncall: jit,module: bootcamp,triaged,small

## 🐛 Bug

`torch.tensor` in python eager can accept a Tensor, which it then copies into a new tensor. Because JIT does not have a tensor overload, an implicit conversion to float gets inserted which will fail at runtime. 

```
import torch
import torch.nn as nn
from typing import List

def foo(x):
    return torch.tensor(x)

input = torch.rand([2, 2])
foo(input)
# fine
torch.jit.script(foo)(input)
```
> ...  <--- HERERuntimeError: Cannot input a tensor of dimension other than 0 as a scalar argument


cc @suo
Repository: flutter
Issue: Tool crashes when launching adb when getcwd fails with EACCES.
Labels: c: crash,tool,P2,team-tool,triaged-tool

Sometimes when launched from an IDE, the tool can crash when the tool process does not have read/list permissions from / up to the cwd.

```
FileSystemException: FileSystemException: Getting current working directory failed, path = '' (OS Error: Operation not permitted, errno = 1)
  | at _Directory.current | (directory_impl.dart:49)
  | at Directory.current | (directory.dart:161)
  | at LocalFileSystem.currentDirectory | (local_file_system.dart:44)
  | at getExecutablePath | (common.dart:59)
  | at _getExecutable | (local_process_manager.dart:125)
  | at LocalProcessManager.run | (local_process_manager.dart:68)
  | at _DefaultProcessUtils.run | (process.dart:313)
  | at AndroidDevices.pollingGetDevices | (android_device_discovery.dart:54)
  | at PollingDeviceDiscovery._initTimer.<anonymous closure> | (device.dart:295)
  | at _rootRun | (zone.dart:1180)
  | at _CustomZone.run | (zone.dart:1077)
  | at _CustomZone.runGuarded | (zone.dart:979)
  | at _CustomZone.bindCallbackGuarded.<anonymous closure> | (zone.dart:1019)
  | at _rootRun | (zone.dart:1184)
  | at _CustomZone.run | (zone.dart:1077)
  | at _CustomZone.bindCallback.<anonymous closure> | (zone.dart:1003)
  | at Timer._createTimer.<anonymous closure> | (timer_patch.dart:23)
  | at _Timer._runTimers | (timer_impl.dart:398)
  | at _Timer._handleMessage | (timer_impl.dart:429)
  | at _RawReceivePortImpl._handleMessage | (isolate_patch.dart:168)
```

Supposing that `getAdbPath` ([here](https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/android/android_device_discovery.dart#L48)) is giving an absolute path, the problem seems to be in `package:process`, which tries to grab the cwd even though the path might be absolute ([here](https://github.com/google/process.dart/blob/master/lib/src/interface/common.dart#L59)). `package:process` should probably skip the cwd relative search if grabbing the cwd fails.
Repository: vscode
Issue: No images in jsdoc hover or notebooks in remote/web
Labels: bug,typescript,javascript,web,notebook-workbench-integration

- Add an image in markdown syntax to a jsdoc comment
- In a local vscode window, hover the identifier with the command
- The image is rendered
- Do the same in a remote window
- The image is broken

Same issue with notebooks. @mjbvz  Is it possible to hook into the same system that webviews use, or is that only tied to webviews?