sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: [folding] Move line up/down should skip over folded regions or folded sections
Labels: help wanted,feature-request,editor-folding,editor-commands

<!-- Please search existing issues to avoid creating duplicates. -->
<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: https://code.visualstudio.com/insiders/ -->

<!-- Use Help > Report Issue to prefill these. -->
- VSCode Version:1.30.0-insider
- OS Version: windows 10

I think when code is in a folded region or section it should never unfold unless explicitly commanded, so if you are moving a line using move command, the line should skip over both folded regions and folded sections
Steps to Reproduce:

1. create a folded region using #region #endregion
2. fold some code section
3. move a line using alt+up/down over the folded region/section
![vscodemovelinebug](https://user-images.githubusercontent.com/6554605/49209732-84b4f900-f3d0-11e8-9bbb-e4f1b4fd018f.gif)


<!-- Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes
Repository: go
Issue: bytes: tests are slow on arm
Labels: NeedsInvestigation

I was watching windows/arm build output, and I noticed that `bytes` package tests are pretty slow

https://farmer.golang.org/temporarylogs?name=windows-arm&rev=311d87dbebbb0238196d3aa13fd9a37f655e1fc3&st=0xc4704774a0

```
ok  	bytes	146.447s
```

and then I looked at linux/arm too, and it is slow too

https://farmer.golang.org/temporarylogs?name=linux-arm&rev=311d87dbebbb0238196d3aa13fd9a37f655e1fc3&st=0xc4576f58c0

```
ok  	bytes	121.089s
```

I just felt sorry for the builders, and decided to create this issue.

I run byte tests here, and they are fast

```
c:\>go test -count=1 bytes
ok      bytes   1.106s
```

I also did not notice any particular test that is slow than others.

Maybe there is `bytes` package code that can be made faster? Maybe some tests can be adjusted to make arm builders faster? Maybe nothing can be done? Then just close the issue.

Thank you.

Alex
Repository: TypeScript
Issue: JSDoc : add support for @method (and @property)
Labels: Suggestion,In Discussion,Domain: JSDoc,Domain: JavaScript

## Search Terms

* JSDoc
* `@method`
* `@property`
* support 

## Suggestion

It would be great to add support for `@method` and `@property` (and maybe `@memberof`) now that annotations are on their way.

I found bug #15715 that only talks about `@property` support but I think this makes more sense to see those in a same light because they should have a very common implementation and moreover they meet the same goals as a whole. At least I think and I explain my reasoning about this below!

## Use Cases

I have functions that do add methods and/or getters on a class right now, waiting for annotations to get their way in JS/TS. But let's say this: when annotations are here, those 2 flags support will be needed anyway (or at least I think so: I don't see how to make IntelliSense work without those)!

```js
/**
* Some class
 * @class
 */
class Test {
  /* whatever */
}

// this adds a #foo() method on the class prototype as well as a #bar getter(/setter)
someMethodAddingABehavior(Test, ...params);
```

And tomorrow with annotations:
```js
/**
* Some class
 * @class
 */
@someAnnotationAddingABehavior(...params)
class Test {
  /* whatever */
}
```

## Examples

I'd like to be able to document those doing something like:
```js
/**
 * What foo is doing is great!
 * @method foo
 * @param {string} testParam some testing parameter
 * @returns {string} some random string
 * @memberof Test.prototype
 */
/**
 * Bar is awesome too!
 * @property {number} bar
 * @memberof Test.prototype
 */
someMethodAddingABehavior(Test, ...params);
```

Or at least to be able to document them in the class itself:

```js
/**
* Some class
 * @class
 */
class Test {
  /* whatever */

  /**
   * What foo is doing is great!
   * @method foo
   * @param {string} testParam some testing parameter
   * @returns {string} some random string
   */
  /**
   * Bar is awesome too!
   * @property {number} bar
   */
}
```

With support of these, I would expect `vscode` to suggest to me the `foo` method and the `bar` property when completing properties of a value of type `Test`.

## 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: react
Issue: Sometimes controlled email inputs break in Chrome due to punycoding
Labels: Type: Bug,Component: DOM

**Do you want to request a *feature* or report a *bug*?**

Report a  bug

**What is the current behavior?**

In Chrome, when typing a sharp S (ß, a German letter) in an input field with `type="email"`, it converts the `ß` to `ss` (~~expected~~ unexpected behaviour) and the cursor jumps back to the beginning of the input field (unexpected behaviour). This does only happen if the `ß` is part of the domain.
Trying to type `test@testß.de` will end as `.detest@testss`:
![Example](https://i.imgur.com/SWQ0p4f.gif)

It can be tested with the latest Google Chrome: 
https://codepen.io/anon/pen/MzzEqB
If you don't have a `ß` on your keyboard, you can reproduce the bug by just Copy&Pasting it.

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**

Tested with Chrome Version 70.0.3538.110 (Official Build) (64-bit) on Ubuntu 18.04 and React 16.6.3

In Firefox, this does not happen, as it does not convert `ß` to `ss`. I didn't test other browsers.
Repository: go
Issue: proposal: text/template/v2: return errors from HTMLEscape and JSEscape
Labels: v2,Proposal

`template.HTMLEscape` and `template.JSEscape` each accept an `io.Writer` and write to it. However, they ignore errors from `Write`.

That's fine when the destination `io.Writer` is one that cannot fail (such as a `*bytes.Buffer`), but can mask real errors in general (see also https://github.com/golang/go/issues/20803#issuecomment-312318808).

It is possible for the caller to detect those errors by wrapping the `io.Writer`, but wrapping an `io.Writer` to capture an error that it already returns needlessly complicates the code.

These functions should return errors, and leave the decision about whether those errors are safe to ignore up to the caller.

**Compatibility**

This change would be call-site compatible (leaving the vast majority of callers unchanged), but would break programs that pass or assign `template.HTMLEscape` or `template.JSEscape` as a `func(io.Writer, []byte)`. Such uses should be rare.

As an alternative, we could add variants of those functions that do return errors; however, separate variants would mask missing error checks from analysis tools. I believe it would be better to simply change the signature in a Go 2 cleanup.
Repository: pytorch
Issue: [Caffe2] How to fetch trainable parameters? 
Labels: caffe2

This is what I tried
```python
with core.DeviceScope(core.DeviceOption(caffe2_pb2.CUDA, 0)):
        # DenseNet is a class where all the methods have been added
        obj = DenseNet((1, 3, 224, 224))
        workspace.SwitchWorkspace(obj.current_workspace)
        workspace.RunNetOnce(obj.model.param_init_net)
        for name in workspace.Blobs():
                # because the input image blob name is input
                if name != 'input':
                    print("{}:\n{}".format(name, workspace.FetchBlob(name).shape))
        for operations in obj.model.net.Proto().op:
            print(operations.input)
Repository: rust
Issue: debuginfo tests should detect a python-less gdb
Labels: A-testsuite,C-enhancement,T-testing-devex

Some of the debuginfo tests require a Python-enabled gdb.  If this isn't available, they should be disabled.  See https://github.com/rust-lang/rustc-guide/pull/243 and https://github.com/rust-lang/rust/issues/52452
Repository: go
Issue: cmd/go: document module-mode behavior of multi-element GOPATHs
Labels: Documentation,help wanted,NeedsFix

    go version devel +311d87dbeb Thu Nov 29 08:30:13 2018 +0000 linux/amd64

```
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/mvdan/go/cache"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/mvdan/go/land:/home/mvdan/go"
GOPROXY=""
GORACE=""
GOROOT="/home/mvdan/tip"
GOTMPDIR=""
GOTOOLDIR="/home/mvdan/tip/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
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-build190148469=/tmp/go-build -gno-record-gcc-switches"
```

In my case, `mvdan.cc/sh/cmd/gosh` is a main package inside the second GOPATH directory. It's also a module, so it can be built in either mode.

```
$ cd ~/go/src/mvdan.cc/sh/cmd/gosh
$ GO111MODULE=on go list -f {{.Target}}
/home/mvdan/go/land/bin/gosh
$ GO111MODULE=off go list -f {{.Target}}
/home/mvdan/go/bin/gosh
```

I understand why the GOPATH build puts the binary where it does - that's the old and documented logic.

And I too sort of understand why the module build goes into the first `GOPATH` entry - it's not building the package within any one `GOPATH`, so it just picks the first.

However, this can be very confusing. In my case, I ended up with two binaries, and because of `PATH` I was always running the older. The only mention is brief, under `go help modules`:

> and installed commands (in GOPATH/bin, unless GOBIN is set)

I realise now that my fix should be to either set up a global `GOBIN`, or to stop using a multi-element `GOPATH`. I still think the documentation could be clearer, though. I think we should discourage the use of a multi-element GOPATH with no GOBIN in the modules world, because of the tricky scenario above.

/cc @bcmills @myitcv @rogpeppe
Repository: flutter
Issue: Detect Java network issues when running `flutter doctor --android-licenses`
Labels: tool,t: flutter doctor,a: first hour,P3,team-tool,triaged-tool

We've had reports of users needing to set the Java network proxy before being able to accept the Android licenses.  We should be able to write a simple Java executable that probes for basic network connectivity:

```java
import java.net.InetAddress;
import java.net.InetSocketAddress;
import java.nio.channels.SocketChannel;

public class NetworkProber {
  private static final int HTTP_PORT = 80;

  public static void main(String[] args) {
    try {
      InetAddress google = InetAddress.getByName("www.google.com");
      InetSocketAddress address = new InetSocketAddress(google, HTTP_PORT);
      SocketChannel channel = SocketChannel.open(address);
      System.out.println("Network OK");
      closeChannelSilently(channel);
      System.exit(0);
    } catch (Throwable t) {
      System.err.println(t.getMessage());
      System.err.println("Network unreachable");
      System.exit(1);
    }
  }

  private static void closeChannelSilently(SocketChannel channel) {
    try {
      channel.close();
    } catch (Exception e) {
    }
  }
}
```

We could prebuild that tool into a JAR file in the engine repo and upload that with our other prebuilt artifacts, then use it in flutter_tools to ensure that we'll be able to reach the network when accepting Android licenses here:

https://github.com/flutter/flutter/blob/72926bdff72e7915136c653c8448107ba9252e36/packages/flutter_tools/lib/src/android/android_workflow.dart#L167

To do this, we can directly invoke Java, as discovered from the Android SDK here:

https://github.com/flutter/flutter/blob/72926bdff72e7915136c653c8448107ba9252e36/packages/flutter_tools/lib/src/android/android_sdk.dart#L447
Repository: neovim
Issue: smarter filename completion CTRL-x CTRL-f
Labels: enhancement,has:workaround

<!-- Before reporting: search existing issues and check the FAQ. -->

- `nvim --version`: 0.3.1
- Vim (version: ) behaves differently? No.
- Operating system/version: Fedora 29
- Terminal name/version: zsh 5.6.2
- `$TERM`: xterm-256color

### Steps to reproduce using `nvim -u NORC`

Try to do file autocomplete on an assignment like this:
`export FILE=/path/to/file`

### Actual behaviour
Pattern not found.

### Expected behaviour
`isfname` is overridden in the pattern search to offer completions for file paths that are valid if the `=` and preceding characters were removed, while still completing paths that would be valid if the characters remained.

I made a post here in the Vim repo:

https://github.com/vim/vim/issues/3645

But it was immediately shot down without any discussion, and I was treated like I didn't know what I was doing and was asking for help. I was told just to make a custom completion script instead of patching the existing one, because this limitation is a "feature" and not a bug.

I thought I would see what the folks at NeoVim think, as I see there are already some existing autocomplete improvement issues and I wanted to offer something much more limited in scope which could be realized without too much hassle. This could be the dealbreaker for me to finally make a switch.
Repository: TypeScript
Issue: Inference of parameter fail
Labels: Bug,Domain: JSX/TSX,Domain: Refactorings

**TypeScript Version:**  3.2.1
**Search Terms:** vscode, typescript, parameter, infer, inference

**Code**
Private repository so I cannot share the repro. However, here is the idea:

Work if one parameter is not defined:
![2018-11-29_13-31-06](https://user-images.githubusercontent.com/1014796/49254344-e039b380-f3dd-11e8-94c6-25ca817feeea.gif)

Does not work if all of them are not defined:
![2018-11-29_18-22-39](https://user-images.githubusercontent.com/1014796/49264666-0d995800-f404-11e8-9286-dae757caad01.gif)

**Expected behavior:**
All the parameter that can be infered to be infered. Does that cannot to be `any`.

**Actual behavior:**
The feature does not appear at all. No clue why is given.

**Playground Link:** Not available.

**Related Issues:** No
Repository: vscode
Issue: Emmet support for custom HTML tags / attributes
Labels: feature-request,html,emmet

Continuation of #62976.

Cusom tags / attributes should go into emmet's registry, so all emmet features work as expected for them.
Repository: pytorch
Issue: libtorch exports protobuf symbols
Labels: high priority,module: build,module: protobuf,module: cpp,module: abi,triaged

## Problem

libtorch, the amazing c++ interface for Pytorch, exports the symbols of it's linked libprotobuf. 

This apparently requires me to use the same version of libprotobuf and protoc for my project when depending on libtorch. 

Attempting to link another version of protobuf caused memory corruption [in my case](https://github.com/protocolbuffers/protobuf/issues/5401). 

## Proposed Solutions

A) Don't export the symbols, if that's possible. 
B) Document the libprotobuf version used by libtorch. This way, I could at least fall back to that version for now. However, I was not able to find the used version.
Repository: godot
Issue: Multiple overlapping sprites with normal maps blended incorrectly
Labels: bug,topic:rendering,confirmed

**Godot version:**
3.1 gles3

**Issue description:**
When you have overlapping sprites with normalmaps like in the gif and the project, the are incorrectly blended together. It looks like the normalmap from sprite below is going through the other one
![ezgif-4-38c0bd09aa95](https://user-images.githubusercontent.com/2963404/49261433-769fc080-f442-11e8-9682-8f5bfc524e6c.gif)

**Minimal reproduction project:**
https://drive.google.com/open?id=19TOz7OEjTpsPJkOcpVv7IlfFy-Xi2ise
Repository: TypeScript
Issue: Add type predicate to Object.is
Labels: Suggestion,In Discussion,Domain: lib.d.ts

<!-- 🚨 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

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

object.is

type predicate

## Suggestion

<!-- A summary of what you'd like to see added or changed -->

When a is b, a and b has to same type, so I suggest adding a few generic overloads with type predicates

```typescript
interface ObjectConstructor {
  is<A, B extends A> (a: A, b: B): a is B
  is<A extends B, B> (a: A, b: B): b is A
  is (a: any, b: any): boolean
}
```

## 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: TypeScript
Issue: AMD Module Names Directives Rewrite CommonJS require's.
Labels: Bug

**TypeScript Version:**  3.2.1

**Search Terms:** AMD, directive

**Code**: https://github.com/ahawkins/typescript-amd-bug. Run `npm test` to see a failing build.

**Expected behavior:** AMD `module-names` should not change requires when building CommonJS modules. 

**Actual behavior:** CommonJS modules require's rewritten to use the AMD module name. If I remove the AMD directives from the sample code then things work as expected.

**Related Issues:** Uncertain.
Repository: rust
Issue: Shipping clang as a rustup component
Labels: T-dev-tools

Sometimes it is beneficial (or even necessary) for mixed-language projects to build C/C++ with a Clang version that matches Rust's LLVM version. [Cross-language LTO](https://github.com/rust-lang/rust/issues/49879) is one of these cases.

Since Rust's LLVM hardly ever matches a specific release and is often ahead of the current stable release, it would be great if we provided an easy way to get ahold of the right Clang binaries. It looks like we are already building Clang for Rust-enabled LLDB anyway. Could we make also make it available via rustup? Either as a standalone component, or as part of `lldb` or `llvm-tools`?

cc @rust-lang/infra @rust-lang/release
Repository: TypeScript
Issue: Infer parameter types from usage quick fix infers to any from React component props
Labels: Bug

<!-- 🚨 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 `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.3.0-dev.20181130
**@types/react Version:** 16.7.10

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

Infer parameter types from usage quick fix react jsx

**Code**

```ts
import React from "react";

function handle(e) {
    console.log(e);
}

function Button() {
    return <button onClick={handle} />;
}
```

**Expected behavior:**

Trigger "Infer parameter types from usage" quick fix for `e` and it should add `React.MouseEvent<HTMLButtonElement>` type for the `e` parameter

**Actual behavior:**

It adds `any` type

**Related Issues:** <!-- Did you find other bugs that looked similar? -->

https://github.com/Microsoft/TypeScript/issues/22357

https://github.com/Microsoft/TypeScript/issues/28766
Repository: go
Issue: proposal: encoding/json: add error var to compare  the returned error when using json.Decoder.DisallowUnknownFields()
Labels: Proposal,Proposal-Hold

### What version of Go are you using (`go version`)?

<pre>
$ go version

go version devel +ffc7bc55f3 Tue Oct 9 10:35:08 2018 +0000 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jaswdr/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/jaswdr"
GOPROXY=""
GORACE=""
GOROOT="/home/jaswdr/go"
GOTMPDIR=""
GOTOOLDIR="/home/jaswdr/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
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-build749620831=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

```go
package main

import (
	"log"
	"bytes"
	"encoding/json"
)

type T struct {
	Bar string `json:"bar"`
}

func main() {
	str := []byte(`{"foo":"bar"}`)
	obj := new(T)
	
	dec := json.NewDecoder(bytes.NewReader(str))
	dec.DisallowUnknownFields()
	err := dec.Decode(&obj)
	if err != nil { // Whant to check if the specific unkown fields error happen
		log.Fatal(err)
	}
	
	log.Println(obj)
}
```

### What did you expect to see?

Some way to check if the error happen.

```go
...
if err == json.UnknownFieldsError {
 ...
}
...
```

### What did you see instead?

No way to do this instead of checking the error string

---

If this is accepted I really want to work on it.
Repository: TypeScript
Issue: Unexpected (unhelpful) autocomplete suggestions inside function call when spreading an array
Labels: Suggestion,In Discussion,Domain: Completion Lists

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.2.1

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** spread autocomplete

**Code**
![unbenannt](https://user-images.githubusercontent.com/17641229/49286941-f60dae00-f49b-11e8-8653-1c1cb4f85ce7.PNG)

I'm not 100% sure what causes this, but its reproducible in this project even after closing VSCode.
I don't think it has to do with the error below, as that vanishes when I delete the line:
https://github.com/AlCalzone/create-adapter/blob/65e5f59ce824a9f405c441091d3d7fad13ee70b5/src/lib/questions.ts#L104

**Expected behavior:**
No autocomplete

**Actual behavior:**
This super unhelpful autocomplete
![unbenannt](https://user-images.githubusercontent.com/17641229/49286987-1f2e3e80-f49c-11e8-8fd8-fd201f035bb3.PNG)

**Playground Link:** nope

**Related Issues:** nope