sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: crypto/ecdsa: make PublicKey implement encoding.TextMarshaler/TextUnmarshaler using PEM
Labels: Unfortunate,Proposal-Accepted,NeedsFix,Proposal-Crypto

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.12.7 darwin/amd64
</pre>
and whatever play.golang.org uses.

### Does this issue reproduce with the latest release?
It is the latest release as of now. It can also be reproduced here: https://play.golang.org/p/cbsOhB8lHxe


### 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=""
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/path/to/my/gocode"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.12.7/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.12.7/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/td/yb98xptn12d60pfrjw87kkm80000gn/T/go-build432091977=/tmp/go-build -gno-record-gcc-switches -fno-common"
</pre></details>

### What did you do?

https://play.golang.org/p/cbsOhB8lHxe

```go
package main

import (
	"crypto/ecdsa"
	"crypto/elliptic"
	"crypto/rand"
	"encoding/json"
	"log"
)

func main() {

	privKey, _ := ecdsa.GenerateKey(elliptic.P256(), rand.Reader)
	jsonKey, err := json.Marshal(privKey)
	if err != nil {
		log.Fatalf("error marshalling private key: %v", err)
	}

	var retrieveKey ecdsa.PrivateKey

	if err := json.Unmarshal(jsonKey, &retrieveKey); err != nil {
		log.Fatalf("error parsing json: %s", err)
	}
}
```

### What did you expect to see?

A key struct created from json that has just been created from the very same data structure.

The same process does succeed for RSA: https://play.golang.org/p/FFYREV4NMfv , although not on the playground, where I get "Program exited: process took too long." I did test it locally and I'm actually using it as a workaround. 

### What did you see instead?

error parsing json: json: cannot unmarshal object into Go struct field PrivateKey.Curve of type elliptic.Curve

I have also written the jsonKey to file and verified that it is valid json.
Repository: go
Issue: cmd/compile: mention shadowing of predeclared identifiers in errors they cause
Labels: help wanted,NeedsFix

(Related: #31064, #14494)

# What version of Go are you using (`go version`)?

1.12, but N/A

### Does this issue reproduce with the latest release?

I believe so?

### What operating system and processor architecture are you using (`go env`)?

N/A

### What did you do?

Horrible monstrous things. Examples:

```
const iota = 0
type int struct{}
var nil = "haha"
```

Okay, fine, those are stupid. But you know what I've done *unintentionally*?

```
...
len := a -b
...
for i := 0; i < len(x); i++ {
...
```

and then get confused by the weird error message about len not being a function.

### What did you expect to see?

I think redeclaring predeclared identifiers should be an error. Or, since that's probably impractical, it should be a thing in `go vet`.

### What did you see instead?

Really weird and misleading error messages when I forget that something is a predeclared identifier. I've hit this most often with `len`, because that's a natural variable name and when I'm naming something that I'm usually not thinking about the function.
Repository: go
Issue: cmd/go: do not lookup "parent" modules automatically to resolve imports
Labels: NeedsInvestigation,early-in-cycle,modules

One of the most annoying missteps the go command makes is when you mistype an import path in your own module and it goes looking for parent modules that might provide the import. In general that's fine, but I think automatic download and search of parents of the main module should be disabled - it's almost always a typo, and if not the user can run go get explicitly.

For example if I am in module rsc.io/tmp/x and import rsc.io/tmp/x/foo instead of rsc.io/tmp/x/boo, it should not try to download rsc.io/tmp and rsc.io to find rsc.io/tmp/x/foo.

/cc @bcmills @jayconrod
Repository: pytorch
Issue: torch.nn.functional.grid_sample with 'circular' border conditions
Labels: module: nn,triaged

In ```torch.nn.functional.grid_sample```, it would be nice to have the circular border conditions implemented as well.

## 🚀 Feature
<!-- A clear and concise description of the feature proposal -->

## Motivation

<!-- Please outline the motivation for the proposal. Is your feature request related to a problem? e.g., I'm always frustrated when [...]. If this is related to another GitHub issue, please link here too -->

## Pitch

<!-- A clear and concise description of what you want to happen. -->

## Alternatives

<!-- A clear and concise description of any alternative solutions or features you've considered, if any. -->

## Additional context

<!-- Add any other context or screenshots about the feature request here. -->
Repository: pytorch
Issue: `suggest_memory_format` has ambiguity & cannot represent intended layout format for corner cases
Labels: module: internals,triaged

## 🐛 Bug

`suggest_memory_format` has ambiguous meaning for two cases:
1. tensor with NCHW where C = 1.
   we could use stride of C as a hint to tell the intended memory format.
2. tensor with NCHW where H == W == 1.
   there's no way to identify the intended memory format from strides.

The problem with this is: There's no proper way to correctly represent desired memory format for tensor with shape NC11. (yes, we can always hack it by utilizing/special casing stride for size 1 dimension. hence the emphasis on *proper*)

This would impact our cudnn setup. For 1x1 convolution, we have filter size with KC11. We would want to specify memory format properly for this case as it would impact the algo we get.
Repository: TypeScript
Issue: Non-Nullable Objects in params don't have properties parsed
Labels: Domain: JSDoc,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 `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.5.2

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** object param 

**Code**

```ts
/**
 * Converts a type to a markdown string.
 * @param {!Object} [opts]
 * @param {boolean} [opts.narrow] Combine type and description.
*/
```

**Expected behavior:**

![Screenshot 2019-08-09 at 21 08 50](https://user-images.githubusercontent.com/21156791/62799607-ebef8500-bae9-11e9-940f-950e3a74811e.png)

**Actual behavior:**

![Screenshot 2019-08-09 at 21 09 19](https://user-images.githubusercontent.com/21156791/62799625-fb6ece00-bae9-11e9-83b1-d0676179d261.png)


**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: pytorch
Issue: [JIT] script doesn't convert dtypes back to torch.dtype from long
Labels: oncall: jit,triaged

```
import torch

def foo(x):
    return x.dtype

scripted = torch.jit.script(foo)
x = torch.rand(3, 4)

print('non-scripted', foo(x))
print('scripted', scripted(x))
```

Output

```
non-scripted torch.float32
scripted 6
```

We probably need to mirror this logic: https://github.com/pytorch/pytorch/blob/489cc46686e7e689e7130e78b73fe77a9edac5ed/torch/csrc/jit/pybind_utils.h#L338 into toPyObject https://github.com/pytorch/pytorch/blob/489cc46686e7e689e7130e78b73fe77a9edac5ed/torch/csrc/jit/pybind_utils.h#L536
Repository: react
Issue: textarea does not show warning when switching from uncontrolled to controlled like inputs do
Labels: Type: Bug,Component: DOM

<!--
  Note: if the issue is about documentation or the website, please file it at:
  https://github.com/reactjs/reactjs.org/issues/new
-->

**Do you want to request a *feature* or report a *bug*?**

Bug

**What is the current behavior?**

While things like `<input>` correctly get a warning when switching from uncrontrolled to controlled, I'm noticing `<textarea>` does not

**If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle (https://jsfiddle.net/Luktwrdm/) or CodeSandbox (https://codesandbox.io/s/new) example below:**

Here's a codesandbox. Type in the input field, we see error (correct), change to textarea and start over, type in field and we don't see the error (incorrect I think) https://codesandbox.io/s/recursing-dawn-jls8i

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**

16.8
Repository: TypeScript
Issue: VS Code indicates available code action but doesn't actually offer a quick fix
Labels: Bug,Domain: Quick Fixes

In VS Code, I noticed that sometimes, it seems to indicate available code actions to convert a `Promise.then()` function to `async/await` with the three grey dots but then, when actually trying to execute the Quick Fix, it shows "No code actions available".

![image](https://user-images.githubusercontent.com/406937/62804668-3f63d200-baee-11e9-8bc2-0fb9850f1f25.png)

![image](https://user-images.githubusercontent.com/406937/62804695-4ee31b00-baee-11e9-96ba-ad9b190c02f9.png)


From my investigation, this seems to happen because one of the Promises inside the function has an `any` type.

I've found the current behavior really confusing because the combination of the three grey dots and then an unavailable Quick Fix is a strange combination.

**TypeScript Version:**  3.6.0-dev.20190808

**Search Terms:** code action async await promise

**Code**

```ts
let somePromise;

function myFunction() { // VS Code shows three grey dots and "This may be converted to an async function.ts(80006)" on hover
  return Promise.resolve()
  .then(() => {
    return somePromise
    .then(() => {
      return 'Yeah!';
    });
  });
}

```

**Expected behavior:**
Either:
- VS Code doesn't indicate an available code action in the first place
- It provides some kind of hint why it can't execute a quick fix or how to enable it
- The code action still works and does the conversion anyway

**Actual behavior:**
VS Code shows a possible available code action but then there is none
Repository: pytorch
Issue: [RPC] Add type annotations for RPC-related Python files
Labels: triaged,better-engineering,module: rpc

@ezyang suggested that, as `torch.distributed.rpc` will be PY3 only, we should enforce type annotations immediately.  

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera
Repository: go
Issue: cmd/go: clean -x removes *.so but doesn't list such files in output
Labels: help wanted,NeedsInvestigation

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.12.7 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/zephyrtronium/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/zephyrtronium/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/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-build755048247=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

```
~/mygo/plugintest$ printf 'package main\n\nvar String = "Hello, world!"\n' >plugin.go
~/mygo/plugintest$ go build -buildmode=plugin
~/mygo/plugintest$ go clean -x
```


### What did you expect to see?

`rm -f` including `plugintest.so`, or `plugintest.so` still present in the directory.

### What did you see instead?

```
cd /home/zephyrtronium/go/src/github.com/zephyrtronium/plugintest
rm -f plugintest plugintest.exe plugintest.test plugintest.test.exe plugin plugin.exe
```

`plugintest.so` was removed by `go clean`, but not listed in its output. It seems that any files removed via https://github.com/golang/go/blob/master/src/cmd/go/internal/clean/clean.go#L323 aren't printed, which includes `*.so` (which the documentation says come from SWIG).
Repository: TypeScript
Issue: Contextually infer parameters for type aliases/interfaces
Labels: Suggestion,In Discussion

## Search Terms

type alias parameter inference contextual 

## Suggestion

The type parameters of a type alias (or interface) should be able to be inferred when a value is being assigned/cast to that type/interface.

## Use Cases/Examples

My program defines a few common types/interfaces to be used as contracts between components. E.g.

```ts
// type for an object holding a function + its inverse
type FunctionPair<T, U> = { apply(it: T): U, reverse(it: U): T }; 
```

Then, throughout the program, I need to make objects of this type. If I have a factory function (or use a class with its constructor), this isn't too bad:

```ts
function makeFunctionPair<T, U>(apply: (it: T) => U, reverse: (it: U) => T) {
  return { apply, reverse } as FunctionPair<T, U>;
}
```

However, I'd like to be able to just write these (simple) domain objects with literals, rather than using a factory function, and then signal the type (with the implied relation between the `apply` and `reverse` properties) to the compiler with a type annotation/assertion inline:

```ts
const a: FunctionPair<string, () => string> = {
    apply(it: string) { return () => it + "!!!"; },
    reverse(it) { return it().slice(0, -3); }
}
```

However, the above is a bit verbose, in that I have to add `<string, () => string>` to the type annotation, whereas it seems like this should be inferrable. I'm proposing to be able to just do: 

```ts
 /* FunctionPair type param values inferred contextually from the assigned object  */
const a: FunctionPair = {
    apply(it: string) { return () => it + "!!!"; },
    reverse(it) { return it().slice(0, -3); }
}
```

Here's another example: imagine a runtime that uses the idea of effects as data. The user sends into the runtime an object describing the effect to perform, and a callback to call with any result: 

```ts
type EffectNamesWithReturnTypes = { 
    x: { status: 0 | 1 },
    y: { changes: string[] }, 
};

type EffectDescriptor<T extends keyof EffectNamesWithReturnTypes> = { 
  name: T; 
  cb: (result: EffectNamesWithReturnTypes[T]) => void
}
```

It would be nice to be able to write:

```ts
const effect = <EffectDescriptor>{ name: "x", cb: (it) => it.status };
```

Rather than having to write:

```ts
const effect = <EffectDescriptor<"x">>{ name: "x", cb: (it) => it.status };
```

## 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: flutter
Issue: Enable hot restart on profile mode
Labels: c: new feature,tool,c: performance,customer: dream (g3),P3,team-tool,triaged-tool

Currently, performance debugging in profile mode is really time consuming because every small change requires a cold restart, which could take several minutes.

While hot reload is impossible in AOT profile build, hot restart should be possible according to @cbracken .

Let's enable it in flutter tools to significantly speedup our customers' performance debugging process.
Repository: pytorch
Issue: Allow incompatible shapes in load_state_dict(strict=False)
Labels: module: serialization,triaged,enhancement

## 🚀 Feature
Right now, `module.load_state_dict(strict=False)` allows the following:
* loading a dict with missing parameters
* loading a dict with more parameters than needed

And it returns an object containing the information about what are missing or what parameters are unexpected.

But it will throw an error if there are parameters with the same name but different shape. It would be good to also allow this behavior, and return information about the unmatched parameters. 

## Motivation

This will help with work in transfer learning, for example.

## Pitch
User can write
```
ret = model.load_state_dict("pretrained.pkl")
for x in ret.incompatible_keys:
    logger.warn("x is not loaded because it has shape xx in checkpoint but shape yy in the model") 
```
## Alternatives

User now have to manually modify the state_dict for such use cases.
UPDATE: it's error-prone for users to do it manually, because some modules (e.g. quantization observers) by design expect to support loading checkpoints with incompatible shapes. It's hard for users to distinguish them from the unsupported incompatible shapes.

Some related discussions at https://github.com/pytorch/pytorch/issues/8282#issuecomment-520101919
Repository: godot
Issue: RemoteTransform2D scale only with global coordinates enabled is wrong
Labels: enhancement,topic:core,documentation

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if non-official. -->
3.2dev, 3.1.1, 3.1, 3.0.6 and maybe others

**OS/device including version:**
<!-- Specify GPU model and drivers if graphics-related. -->
Windows 10

**Issue description:**
<!-- What happened, and what was expected. -->
Looks like when you get the scale from a `Transform2D` the coordinates it uses aren't the ones one would expect as per issue https://github.com/godotengine/godot/issues/21020

This makes the  `RemoteTransform2D` scale behavior when its `use global coordinates` enabled (the default) and only the scale selected to behave unexpectedly

![https://i.imgur.com/zIksz7f.gifv](https://i.imgur.com/zIksz7f.gif)

**Steps to reproduce:**
Check the MRP

**Minimal reproduction project:**
<!-- Recommended as it greatly speeds up debugging. Drag and drop a zip archive to upload it. -->
[remotetransform2d_scale_issue.zip](https://github.com/godotengine/godot/files/3488578/remotetransform2d_scale_issue.zip)
Repository: TypeScript
Issue: Flag 'instanceof' expressions that are provably always true or false
Labels: Suggestion,Awaiting More Feedback

## Suggestion
When refactoring code, TypeScript is generally very good at finding and reporting situations where existing code will break due to type changes. This allows "refactoring with confidence". This isn't surprising given that one of the primary goals of TypeScript is to "statically identify constructs that are likely to be errors".

There's one common case where TypeScript is "blind" and doesn't report errors when types are refactored. This case involves the use of the 'instanceof' operator. This operator can be used in situations where it makes no sense -- e.g. where the type specified on the LHS has no possible relation to the type specified on the RHS.

To help developers avoid this common programming error, I propose that TypeScript report an error for any 'instanceof' expression that is provably always true or false at compilation time. Any such expression will likely be unintended by the programmer and should be flagged as errors. At best, such operations represent unnecessary code that imposes runtime overhead.

## Example

```typescript
// ClassB is a subclass of ClassA.
class ClassA {}
class ClassB extends ClassA {}

// ClassC has nothing to do with either
// ClassA or ClassB.
class ClassC {
    method1() {}
}

function function1(param1: ClassB) {
    // Static analysis can prove this expression
    // will always evaluate to false. It's a common
    // source of programming errors, especially during
    // refactoring.
    if (param1 instanceof ClassC) {
        // This call isn't even valid given that param1
        // was declared as type ClassB.
        param1.method1();
    }

    // Static analysis can prove this expression will
    // always evaluate to true, so at best it's unnecessary
    // runtime overhead and more commonly is a behavior
    // that is unintended by the programmer.
    if (param1 instanceof ClassA) {
        // ...
    }
}
```

Are there any legitimate uses of 'instanceof' where the result is statically provable to be true or false in all cases? I can't think of any, but it's possible I'm overlooking some specialized cases. If there are, this check could be added as an optional compiler switch to preserve the current behavior.