sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/compile: inlined messaging is unclear when inlining functions from other packages
Labels: NeedsInvestigation,compiler/runtime

<pre>
$ go version
go version go1.14 darwin/amd64
</pre>
(latest)

### What did you do?

main.go
```go
package main

import (
	"bufio"
	"os"
)

func main() {
	os.Stdout.WriteString("Name: ")
	name, _ := bufio.NewReader(os.Stdin).ReadString('\n')
	os.Stdout.WriteString("Hi " + name)
}
```
```bash
go build -gcflags='-m' main.go
``` 
vs 
```bash
go build -gcflags='-m -l' main.go
```
### What did you expect to see?
Nothing moved to heap for both.

### What did you see instead?
The inlined version moved an allocation to heap while the non-inlined version did not.
The relevant part of -gcflags="-m -m":
```
./main.go:10:28: make([]byte, bufio.size) escapes to heap:
./main.go:10:28:   flow: {heap} = &{storage for make([]byte, bufio.size)}:
./main.go:10:28:     from make([]byte, bufio.size) (non-constant size) at ./main.go:10:28
```
It appears the const that's passed-in becomes non-const or isn't realized to be const because of the passed-in indirection. The inlining part of the output:
```
./main.go:10:28: inlining call to bufio.NewReader func(io.Reader) *bufio.Reader { return bufio.NewReaderSize(bufio.rd, int(4096)) }
./main.go:10:28: inlining call to bufio.NewReaderSize func(io.Reader, int) *bufio.Reader { var bufio.b·4 *bufio.Reader; bufio.b·4 = <N>; var bufio.ok·5 bool; bufio.ok·5 = <N>; bufio.b·4, bufio.ok·5 = bufio.rd.(*bufio.Reader); if bufio.ok·5 && len(bufio.b·4.buf) >= bufio.size { return bufio.b·4 }; if bufio.size < int(16) { bufio.size = int(16) }; var bufio.r·6 *bufio.Reader; bufio.r·6 = <N>; bufio.r·6 = new(bufio.Reader); bufio.r·6.reset(make([]byte, bufio.size), bufio.rd); return bufio.r·6 }
./main.go:10:28: inlining call to bufio.(*Reader).reset method(*bufio.Reader) func([]byte, io.Reader) { *bufio.b = bufio.Reader literal }
./main.go:10:49: inlining call to bufio.(*Reader).ReadString method(*bufio.Reader) func(byte) (string, error) { var bufio.bytes·5 []byte; bufio.bytes·5 = <N>; var bufio.err·6 error; bufio.err·6 = <N>; bufio.bytes·5, bufio.err·6 = bufio.b.ReadBytes(bufio.delim); return string(bufio.bytes·5), bufio.err·6 }
```
Repository: pytorch
Issue: [jit] Hook support tracking
Labels: high priority,triage review,oncall: jit,triaged

TorchScript today does not support hooks (either on modules or tensors). Hooks can be:

1. Module forward hooks
2. Module pre-forward hooks
3. Module backward hooks
4. Tensor backward hooks

This example shows an `nn.Module` with forward and pre-forward hooks. The module compiles fine but is silently different from eager Python since the hooks are not run. The hooks should instead be compiled and run at the same time as they are in eager. They should also be serialize-able and still run if someone re-loads a module in Python.


```python
def fn1(self, inputs):
    print("fn1", inputs)
    return (inputs[0] + 10,)

def fn2(self, inputs, outputs):
    print("fn2", inputs, outputs)

def fn3(self, inputs, outputs):
    print("fn3", inputs, outputs)
    return outputs + 30

class M(nn.Module):
    def forward(self, x):
        return x + 2

m = M()
m.register_forward_pre_hook(fn1)
m.register_forward_hook(fn2)
m.register_forward_hook(fn3)

scripted_m = torch.jit.script(m)
print("Eager result", m(torch.tensor(0)))
print("Script result", scripted_m(torch.tensor(0)))
```
```
fn1 (tensor(0),)
fn2 (tensor(10),) tensor(12)
fn3 (tensor(10),) tensor(12)
Eager result tensor(42)
Script result tensor(2)
```

Hooks are also currently not supported in the PyTorch C++ API for ``nn::Module``s (#25888). The the TorchScript C++ API `script::Module` methods can only be run by fetching them explicitly, e.g. `my_module.forward(the_inputs)` or `my_module.get_method("forward")(the_inputs)`, so I don't think it makes sense to run hooks in C++ until we fix the C++ API to include a `my_module(the_inputs)`.

cc @ezyang @gchanan @zou3519 @bdhirsh @gmagogsfm @suo
Repository: TypeScript
Issue: Directly setting an object which contains an optional item defined with an interface doesn't bypass `Object is possibly 'null' or 'undefined'.`
Labels: Bug

**TypeScript Version:**  3.9.0-dev.20200305

**Search Terms:**
* object is possibly 'null' or 'undefined'

**Code**
https://github.com/mckaysalisbury/typescript-direct-set



```ts
// See the above repo for a little more self containment.
// Most notably `"strictNullChecks": true`
interface I {
  optional?: (I | null);
  required: number;
}

let workaround: I;
workaround = {
  optional: { required: 2 },
  required: 1
};

workaround.optional.required;  // This is where the error occurs
```

**Expected behavior:**
This code should properly compile without errors, even with `"strictNullChecks": true`
**Actual behavior:**
With `"strictNullChecks": true`, there is a possibly undefined error.

**Playground Link:**
[Typescript Playground](https://www.typescriptlang.org/play/?ts=3.9.0-dev.20200304&ssl=1&ssc=1&pln=35&pc=1#code/JYOwLgpgTgZghgYwgAgJLIN4FgBQzkD2ADmMASHADYD8AXMgBToA+yIArpZQJQDcu+KBACO7YEIAm9DgFsARtH44AvrlwJyAZzDIA7vXQBeTAMIkyFSvQzIho8RCnIATMmUAaU3bGT6ARlxlJVxdADpiUnIqUO8HCV5kAHpEtGQEOBBkAGtQCUIYZE0IFF0ACwBPZDBS4E00ghkiSjhQTVDUiAAPJuAEYDBKSokIBGbJKtK4HWqUMHKiFAICmeQANzgoYDg5ShQpidngGUWCorBSEABzNIzkBTZOZp2INRxcXZ1dAigsjYJ2EBOVBKL4-P4AvLGbB4MyRSzWWwiHyOeiuDxeJFxfyBYI4UG-KD-QHhcxRSgxTGSBJJFIAFRqdXIKHQ1VAWWQtT0hKu7VQAHIZMguj0+gNKmcLtcVutKOwUKAJpz0kVQq8NCBtHpvgSiRJaQQAOra8GAgzIKEY+y+ZB+TwqEHGwkQ-VGsFO4kRCxUc2YRFWlE2twJZLIADKBFSk1WswjwsovX6g0KYCms0m01KKBlcvyirqREJCygcw5dRABB0HC4VQjlwgGfl4AggMcdwgUbIUFe+JNesNjt1JLh0ViVJpyHpnKZyAkBAgmhAfJ0Ub2yALBGeMjVWh0VEgUAokFdOud-bdurNFphnrJCNHAb8bjtgkpD7tQVee+gh4gx97LoHCEhy9SgAEIKX9eJx0nOpNFKf5KAkRcdHuEARnnTQNnKdoAFEIDCXAgA)

**Related Issues:**
* https://github.com/microsoft/TypeScript/issues/35523
***Not that related***
* https://github.com/microsoft/TypeScript/issues/36193
* https://github.com/microsoft/TypeScript/issues/35964
Repository: rust
Issue: Unhelpful error when returning reference in `move` closure
Labels: A-diagnostics,A-lifetimes,A-closures,A-borrow-checker,T-compiler,D-confusing

The following code:

```rust
struct Foo;

fn bad_closure() {
    let captured_foo = Foo;
    move || {
        &captured_foo
    };
}
```

gives the following error:

```
error: lifetime may not live long enough
 --> src/main.rs:8:9
  |
7 |     move || {
  |     -------
  |     |     |
  |     |     return type of closure is &'2 Foo
  |     lifetime `'1` represents this closure's body
8 |         &captured_foo
  |         ^^^^^^^^^^^^^ returning this value requires that `'1` must outlive `'2`
```

We have two spans pointing the closure itself, but nothing that specifically mentions `captured_foo`, or the fact that the closure is `move`. If there's more indirection involved (e.g. returning something which ends up outliving `captured_foo`), it may be difficult to tell what the root cause is.
Repository: rust
Issue: Consider warning when comparing wide pointers with vtables (as their address identity is unstable)
Labels: A-lints,A-trait-system,T-lang,T-compiler

vtable addresses [may differ cross codegen units](https://github.com/rust-lang/rust/issues/46139). To mitigate this, it would be good to have a lint that warns against comparing wide pointers with vtables.

### Original report

This is a regression from the 2/27 to 2/28 nightly.

```rust
pub trait Trait {}
impl Trait for i32 {}

pub struct Obj<'a, T: 'static + Trait> {
    ptr: &'a T,
    trait_ptr: *const dyn Trait,
}

impl<'a, T: Trait + 'static> Drop for Obj<'a, T> {
    fn drop(&mut self) {
        assert_eq!(self.trait_ptr, self.ptr as *const dyn Trait);
    }
}

fn main() {
    let ptr = 5;
    let _name = Obj {
        ptr: &ptr,
        trait_ptr: &ptr,
    };
}
```

When this program is built with `rustc main.rs`, it runs without any trouble. When it's built with `rustc main.rs -C incremental=`, I receive the following output:
```
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `0x7ffee7d23864`,
 right: `0x7ffee7d23864`', main.rs:11:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```

From the [regression window](https://github.com/rust-lang/rust/compare/abc3073c9...6d69caba1), I suspect https://github.com/rust-lang/rust/pull/67332.
Repository: kubernetes
Issue: Add tests for DeleteOptions apiserver deserialization
Labels: priority/important-soon,sig/api-machinery,kind/feature,lifecycle/frozen

Unfortunately, kube-apiserver accepts almost anything right now. It should continue to do so or an unknown number of clients will break due to a later seemingly benign "bug fix".
Repository: godot
Issue: Cannot change project display size property programmatically in mono
Labels: topic:core,documentation

**Godot version:** 3.2.1 RC2 Mono Version

**OS/device including version:** MacOS Catalina. MBP 2018.

**Issue description:** Changing window size programmatically in the ProjectSettings singleton takes no effect.

**Steps to reproduce:** Create a Godot mono project with any resolution different from the bellow example. Create a scene and attach a C# script to it with the following code in the _Ready() function:

```
ProjectSettings.SetSetting("display/window/size/width", 200);
ProjectSettings.SetSetting("display/window/size/height", 100);

GD.Print($"{ProjectSettings.GetSetting("display/window/size/width")}");
GD.Print($"{ProjectSettings.GetSetting("display/window/size/height")}");
```
This print actually prints the values you set right before, but the actual window size does not change from the one you set in the project settings inside the Godot editor.

**Minimal reproduction project:** NA
Repository: PowerToys
Issue: Mouse Button remapper
Labels: Idea-New PowerToy,Product-Mouse Utilities

# Summary of the new feature/enhancement

## The problem
* Windows only support switch left and right mouse button (since many many years)
* Each mouse with more that three buttons come with a different configuration tool
  * not all but the most (from known companies)
  * when only buy mouses from one company you can use one tool
  * but these tool are only support a few of generation mouses of the from the same comapnie

## The Solution
Introduce a new module witch allows the user to remap the mouse buttons

## Key features
* Support remap the typical five mouse buttons
  * left, right, middle, forward, backward
* Support remap to another mouse button
* Support remap to keyboard keys
* Support remap to keyboard keys with modifiers

## Nice to have
* Support remap all mouse buttons
* Support remap to multimedia key (play, pause, next track, etc.)

## No-Goals (or after first version)
* Support hardcore/esoteric mouses with more then 10 buttons.

## Possible problems
* Inaccessibly of the mouse buttons from OS 
* Different APIs (inside the different drivers from the different companies)
* Loops (when press a remapped mouse button)

## Current alternatives

### Windows
* [X Mouse Button Control ](https://www.highrez.co.uk/downloads/XMouseButtonControl.htm)
  * Support only five mouse buttons 😢
Repository: TypeScript
Issue: Completion list incorrectly uses generic default when the constraint type would be better (?)
Labels: Bug,Domain: Completion Lists

**TypeScript Version:**  3.8.3


**Search Terms:** completion, generic, base constraint, default

**Expected behavior:** Show `a` and `b` in the completion

**Actual behavior:** Doesn't show `a` and `b` in the completion anymore. This works perfectly fine in 3.7.5, see [3.7.5 Playground](https://www.typescriptlang.org/v2/en/play?ts=3.7.5#code/CYUwxgNghgTiAEAXAngBwQeVYglgewDsBneAXngG8AoeeKAfgC54CBXAWwCMQYb5Om8Iohg4CAcyoBfKlVCRYCAGasCYXIXgqCAHgAq8EAA9EIAsBJYNxMpSkA+ABSxxzPQEpmANzw5gsqm1HalppdyA). However now it's not working anymore in 3.8.3 (as well as any 3.8.x). [3.8.3 Playground](https://www.typescriptlang.org/v2/en/play?ts=3.8.3#code/CYUwxgNghgTiAEAXAngBwQeVYglgewDsBneAXngG8AoeeKAfgC54CBXAWwCMQYb5Om8Iohg4CAcyoBfKlVCRYCAGasCYXIXgqCAHgAq8EAA9EIAsBJYNxMpSkA+ABSxxzPQEpmANzw5gsqm1HalppdyA)

Note, that the autocompletion works, if I don't provide the `= {}` default type.

<!-- Did you find other bugs that looked similar? -->
**Related Issues:** https://github.com/microsoft/TypeScript/issues/30507

**Code**
```ts
declare type Options = {
  a?: number
  b?: string
}

declare function fun<T extends Options = {}>(arg: T): void


fun({
  /** cursor **/
})
```



<details><summary><b>Output</b></summary>

```ts
"use strict";
fun({});

```


</details>


<details><summary><b>Compiler Options</b></summary>

```json
{
  "compilerOptions": {
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "alwaysStrict": true,
    "esModuleInterop": true,
    "declaration": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "moduleResolution": 2,
    "target": "ES2017",
    "jsx": "React",
    "module": "ESNext"
  }
}
```


</details>

**Playground Link:** [Provided](https://www.typescriptlang.org/v2/en/play?ts=3.8.3#code/CYUwxgNghgTiAEAXAngBwQeVYglgewDsBneAXngG8AoeeKAfgC54CBXAWwCMQYb5Om8Iohg4CAcyoBfKlVCRYCAGasCYXIXgqCAHgAq8EAA9EIAsBJYNxMpSkA+ABSxxzPQEpmANzw5gsqm1HalppdyA)
Repository: godot
Issue: Rigidbody doesn't rotate when linear movement restriction on all axis is applied
Labels: bug,discussion,confirmed,topic:physics

**Godot version:**
3.2 stable

**OS/device including version:**
Windows 10


**Issue description:**
rigidbody wont rotate when the linear movement on all the axis is locked


**Steps to reproduce:**
- make a rigidbody
- attach a collision shape as a child of the rigidbody and select a box shape
- adjust the collision shape extents and translation, so the parent pivot is on the side of it
- on the rigidbody, restrict the linear movement on all the axis, and restrict the angular movement on the x and z axis ([see image](https://imagebin.ca/v/5EfpCkLKgxlt))
- use a kinematic body as the player ([see image](https://imagebin.ca/v/5EfqteTAFOC5))
- play the scene and try to push the rigidbody with the player: the rigidbody should rotate around its y axis, but it doesn't, instead the player goes trough it
- now unlock the linear movement on one of the axis of the rigidbody
- play the scene and try to push again the rigidbody with the player: it should rotate around the y axis, and move along the unlocked axis (except if you unlocked the y axis)


**Minimal reproduction project:**

[IssueExample.zip](https://github.com/godotengine/godot/files/4297954/IssueExample.zip)
Repository: electron
Issue: Feature request: nodeIntegrationInSubFrames for preload scripts
Labels: enhancement :sparkles:

### Preflight Checklist
<!-- Please ensure you've completed the following steps by replacing [ ] with [x]-->

* [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
* [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
* [x] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

### Problem Description
I want the preload script of a webview to run in ALL subframes of that webview, such as iframes, so that I can detect anchor tags within these subframes. This is required to fix [this issue](https://github.com/Jelmerro/Vieb/issues/13) for one of my projects.
Correct me if I am wrong, but it would seem that this was possibly before, but it was considered a bug: https://github.com/electron/electron/issues/18429
The purpose of the `nodeIntegrationInSubFrames` is now ill-defined, and does not do what it says it does regarding the preload script, at least according to my interpretation of the documentation:
```
nodeIntegrationInSubFrames Boolean (optional) - Experimental option for enabling Node.js support in sub-frames such as iframes and child windows.
All your preloads will load for every iframe, you can use process.isMainFrame to determine if you are in the main frame or not.
```

### Proposed Solution
I would like restore this behavior for preload scripts, possibly with a separate setting to enable it. If there is any existing way to run preload scripts for iframes that are inside a webview, please enlighten me, because I have not found any other way to achieve this.

### Alternatives Considered
I have tried to run my preload script for iframes inside webview, by enabling `nodeIntegrationInSubFrames`, but so far without success. After I discovered https://github.com/electron/electron/issues/18429, I decided it was time to open a feature request in order to resolve this confusing situation.

### Additional Information
I would like to answer this question once and for all, because the documentation is now inconsistent with the actual behavior. It would seem that I am not the only one who is confused by this change:
https://github.com/electron/electron/pull/19260#issuecomment-512557257
Repository: rust
Issue: std::net::IpAddr: is_loopback failing on ipv4-in-ipv6 addresses 
Labels: T-libs-api,C-bug

## Summary: 
The issue arises when trying to determine if an `IpAddr` is coming from localhost in a mixed IPv4/IPV6 environment.
The `is_loopback` [function](https://doc.rust-lang.org/std/net/enum.IpAddr.html#method.is_loopback) should return `true` for loopback IPs such as *127.0.0.1* or *[::1]*. This fails if a socket is bound to *[::]* which responds to IPv4 as well as IPv6. Here, IPv4 is automatically wrapped in IPv6 and *127.0.0.1* is becoming *[::ffff:127.0.0.1]* which is not recognized as a loopback address.

## Detailed story
If I bind a server to *0.0.0.0* or *[::1]* and telnet/curl from localhost, I can easily tell whether the connection came from a local user or not by using the `is_loopback` call on `IpAddr`, `Ipv4Addr` or `Ipv6Addr`.

Once I bind my server to *[::]* to work on IPv4 AND IPv6 at the same time and then connect to it via v4 to *127.0.0.1* the `is_loopback` call returns `false`.
I then have to manually try conversion of the `Ipv6Addr` into an `Ipv4Addr` (using `to_ipv4`) and perform a second check with `is_loopback`.

In my opinion, this behavior should either be clearly documented in the standard library or better yet should happen automatically (at least in `IpAddr`) since an ipv6 encapsulated ipv4 loopback address is still a perfectly valid loopback address.

The current documentation in `Ipv6Addr` states that it is a check for *[::1]* but a clear statement that IPv4 in IPv6 loopback addresses are not covered might help. I also guess that having the current minimal checks in both variants (v4 and v6) make sense to keep but the general `is_loopback` in `IpAddr` itself could provide the convenient conversion as it covers v4 and v6 anyways.

## Example Code

```rust
use std::net::{Ipv4Addr, Ipv6Addr};

fn main() {
    let ipv4 = Ipv4Addr::new(127, 0, 0, 1); // regular 127.0.0.1
    let ipv6 = Ipv6Addr::new(0, 0, 0, 0, 0, 0, 0, 0x1); // regular [::1] 
    let v4_in_v6 = Ipv6Addr::new(0, 0, 0, 0, 0, 0xffff, 0x7f00, 0x1); // if binding socket to [::] and connecting from ipv4 localhost
    
    println!("{} is loopback? {} ", ipv4, ipv4.is_loopback());
    println!("{} is loopback? {} ", ipv6, ipv6.is_loopback());
    println!("{} is loopback? {} ", v4_in_v6, v4_in_v6.is_loopback());
    println!("{} is loopback? {} ", v4_in_v6, v4_in_v6.to_ipv4().unwrap().is_loopback());
}
```

([Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=edf5df48850f188f042dfea062490b67))

Output:

```
127.0.0.1 is loopback? true 
::1 is loopback? true 
::ffff:127.0.0.1 is loopback? false 
::ffff:127.0.0.1 is loopback? true 

```
Repository: flutter
Issue: Google SignIn on IOS : Thread 1: EXC_BAD_ACCESS (code=1, address=0x10)
Labels: c: crash,platform-ios,p: google_sign_in,package,P2,c: fatal crash,team-ios,triaged-ios

Hi,

I have an issue only on IOS (no problem with Android).

My code :

>  GoogleSignIn _googleSignIn = GoogleSignIn(
>                                     scopes: [
>                                       'email',
>                                       'https://www.googleapis.com/auth/contacts.readonly',
>                                     ],
>                                   );
> GoogleSignInAccount result = await _googleSignIn.signIn();

And after, I'm logged to google, app crash here => 

> - (void)respondWithAccount:(id)account error:(NSError *)error {
>   FlutterResult result = _accountRequest;
>   _accountRequest = nil;
>   result(error != nil ? getFlutterError(error) : account);
> }

In debug, it shows "result" is null.

I did something wrong ?


Thx.
Repository: flutter
Issue: Automatic supported browser detection for Flutter web 
Labels: c: new feature,framework,platform-web,c: proposal,P3,team-web,triaged-web

<!-- Thank you for using Flutter!

     If you are looking for support, please check out our documentation
     or consider asking a question on Stack Overflow:
      * https://flutter.dev/
      * https://api.flutter.dev/
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     If you have found a bug or if our documentation doesn't have an answer
     to what you're looking for, then fill our the template below. Please read
     our guide to filing a bug first: https://flutter.dev/docs/resources/bug-reports
-->

## Use case
The web platform could have an out of the box mechanism (maybe optional) that detects the current browser and if Flutter is supported in this or not.
This will help developers solve the issue of getting their application(s) reach more users and (automatically) resolve customer support in case of unsupported browsers.

<!--
     Please tell us the problem you are running into that led to you wanting
     a new feature.

     Is your feature request related to a problem? Please give a clear and
     concise description of what the problem is.

     Describe alternative solutions you've considered. Is there a package
     on pub.dev/flutter that already solves this?
-->

## Proposal

If the browser is greenlit then things go ahead as normal.
If not, an alternative to run the app to be presented to the user in a default page:
- either update the current browser to a supported version 
- or choose another supported browser from a list with links to its install page 

<!--
     Briefly but precisely describe what you would like Flutter to be able to do.

     Consider attaching images showing what you are imagining.

     Does this have to be provided by Flutter directly, or can it be provided
     by a package on pub.dev/flutter? If so, maybe consider implementing and
     publishing such a package rather than filing a bug.
-->