sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: BinaryHeap::peek_mut borrow check error (previously worked with -Z polonius)
Labels: A-borrow-checker,T-compiler,C-bug,NLL-polonius

The code below ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=8129d2dbcf17e4027fe851e877a31988)) gives an apparently spurious borrow check error. Intuitively, I would expect the first mutable borrow of `heap` to end when `p` is consumed by `PeekMut::pop`. I probably wouldn’t be filing this as a bug except that `rustc -Z polonius` agreed with my intuition until a few days ago.

Works: rustc 1.44.0-nightly (699f83f52 2020-03-29) with `-Z polonius`
Fails: rustc 1.44.0-nightly (211365947 2020-03-30) with `-Z polonius`
[Commits in `699f83f52`...`211365947`](https://github.com/rust-lang/rust/compare/699f83f525c985000c1f70bf85117ba383adde87...2113659479a82ea69633b23ef710b58ab127755e)

```rust
use std::collections::binary_heap::{BinaryHeap, PeekMut};

fn main() {
    let mut heap = BinaryHeap::from(vec![1, 2, 3]);
    if let Some(p) = heap.peek_mut() {
        PeekMut::pop(p);
        heap.push(4);
    };
}
```

```
error[E0499]: cannot borrow `heap` as mutable more than once at a time
 --> src/main.rs:7:9
  |
5 |     if let Some(p) = heap.peek_mut() {
  |                      ---------------
  |                      |
  |                      first mutable borrow occurs here
  |                      a temporary with access to the first borrow is created here ...
6 |         PeekMut::pop(p);
7 |         heap.push(4);
  |         ^^^^ second mutable borrow occurs here
8 |     };
  |      - ... and the first borrow might be used here, when that temporary is dropped and runs the destructor for type `std::option::Option<std::collections::binary_heap::PeekMut<'_, i32>>`
```

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.44.0-nightly (853c4774e 2020-04-04)
binary: rustc
commit-hash: 853c4774e26ea97b45fe74de9a6f68e526784323
commit-date: 2020-04-04
host: x86_64-unknown-linux-gnu
release: 1.44.0-nightly
LLVM version: 9.0
```
Repository: create-react-app
Issue: Line numbers reported in TypeScript syntax errors can be incorrect
Labels: issue: needs investigation,issue: bug report

Sometimes syntax errors have the wrong line numbers.

Needless to say, this is confusing.

### Environment

```
Environment Info:

  current version of create-react-app: 3.4.1
  running from /Users/sophiebits/.npm/_npx/57068/lib/node_modules/create-react-app

  System:
    OS: macOS High Sierra 10.13.6
    CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
  Binaries:
    Node: 8.12.0 - ~/.nvm/versions/node/v8.12.0/bin/node
    Yarn: 1.16.0 - /usr/local/bin/yarn
    npm: 6.4.1 - ~/.nvm/versions/node/v8.12.0/bin/npm
  Browsers:
    Chrome: 80.0.3987.162
    Firefox: 71.0
    Safari: 13.1
  npmPackages:
    react: ^16.13.1 => 16.13.1 
    react-dom: ^16.13.1 => 16.13.1 
    react-scripts: 3.4.1 => 3.4.1 
  npmGlobalPackages:
    create-react-app: Not Found
```

### Steps to reproduce

<!--
  How would you describe your issue to someone who doesn’t know you or your project?
  Try to write a sequence of steps that anybody can repeat to see the issue.
-->

(Write your steps here:)

1. Run `npx create-react-app --template typescript bug`
2. Replace `bug/src/App.tsx` with the following:

```
const x = useReducer<A, B>((state, action) => {
  here();
  are();
  some();
  lines();
  to();
  demonstrate();
  the();
  line();
  number();
  can();
  be();
  way();
  off();
  case 'hello':
});
```


### Expected behavior

When loading the project in a browser, expected the error message:

```
Unexpected token (15:2)

  13 |   way();
  14 |   off();
> 15 |   case 'hello':
     |   ^
  16 | });
  17 | 
```

### Actual behavior

Got the error message:

```
./src/App.tsx
SyntaxError: /path/to/src/App.tsx: Unexpected token, expected ";" (1:25)

> 1 | const x = useReducer<A, B>((state, action) => {
    |                          ^
  2 |   here();
  3 |   are();
  4 |   some();
```

NB: `yarn tsc` does output the right line number in this case, so I don't think it's a TS bug:

```
$ yarn tsc
src/App.tsx:15:3 - error TS1128: Declaration or statement expected.
15   case 'hello':
```

Interestingly, the bug goes away if you remove the type param `<A, B>`.

### Reproducible demo

https://github.com/sophiebits/cra-typescript-line-numbers-bug
Repository: flutter
Issue: AnnotatedRegion not working on iOS (to set status bar icon color)
Labels: platform-ios,framework,customer: money (g3),a: layout,has reproducible steps,P2,found in release: 3.3,found in release: 3.7,team-ios,triaged-ios

Internal: b/153083915 [Videos in attached bug]

I am currently trying to use the suggested AnnotatedRegion widget in order to control the status bar icon color.

Basically, after going to a new page which sets the status bar icon color, then going back to the original page, the original page status bar icon color is not reverted to the original one set by the AnnotatedRegion widget.

To reproduce:

```dart
import 'package:flutter/material.dart';
import 'package:flutter/services.dart';

void main() {
  runApp(MaterialApp(
    title: 'Named Routes Demo',
    // Start the app with the "/" named route. In this case, the app starts
    // on the FirstScreen widget.
    initialRoute: '/',
    routes: {
      // When navigating to the "/" route, build the FirstScreen widget.
      '/': (context) => FirstScreen(),
      // When navigating to the "/second" route, build the SecondScreen widget.
      '/second': (context) => SecondScreen(),
    },
  ));
}

class FirstScreen extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final systemUiOverlayStyle = const SystemUiOverlayStyle(
      statusBarColor: Colors.transparent,
      statusBarIconBrightness: Brightness.dark,
    );

    return AnnotatedRegion<SystemUiOverlayStyle>(
      value: systemUiOverlayStyle,
      child: Container(
        color: Colors.white,
        child: Center(
          child: RaisedButton(
            child: Text('Launch screen'),
            onPressed: () {
              // Navigate to the second screen using a named route.
              Navigator.pushNamed(context, '/second');
            },
          ),
        ),
      ),
    );
  }
}

class SecondScreen extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        brightness: Brightness.dark,
        backgroundColor: Colors.black,
        title: Text("Second Screen"),
      ),
      body: Center(
        child: RaisedButton(
          onPressed: () {
            // Navigate back to the first screen by popping the current route
            // off the stack.
            Navigator.pop(context);
          },
          child: Text('Go back!'),
        ),
      ),
    );
  }
}
```

It only occurs on iOS, on Android it works as expected (the status bar icon color reverts to original color when returning to the original page).
Repository: pytorch
Issue: torch.multinomial is misnamed. 
Labels: module: distributions,triaged,module: ux

The [multinomial distribution](https://en.wikipedia.org/wiki/Multinomial_distribution) has two inputs: weights <i><b>p</b></i> and the number of trials <i>N</i>, and one output the number of results in each category <b>n</b>. Note that the concept of with or without replacement doesn't enter the picture, and the output as the same shape as the weights, but with a different data type (an integer that sums to <i>N</i> along the axis that the weights sum to 1). 

There is a distribution that related to the multinomial distribution by the question of replacement, and that's the [multi-variate hypergeometric distribution](https://en.wikipedia.org/wiki/Hypergeometric_distribution#Multivariate_hypergeometric_distribution), but that, too, will have an output with the same shape as weights (and weights will have to contain integers, instead of floats). 

The hypergeometric distribution is about drawing a fixed number of objects from a population that has a fixed number of each type of object without replacing between individual draw, and then counting how many of each type you drew. A multinomial distribution can be gotten from the same process where the objects are replaced after each draw.

Regardless, that's not what torch.multinomial is returning. When you're returning the result of each draw, you're repeatedly sampling either the [categorical distribution](https://en.wikipedia.org/wiki/Categorical_distribution) (the with replacement variant), or a distribution I cannot find a name for (draw?). Although the constraint that the number of draws be less than the number of categories means that the without replacement variant doesn't correspond to any probability distribution I know of, at all.

So, I would suggest renaming torch.multinomial to torch.categorical.

cc @vincentqb @fritzo @neerajprad @alicanb @vishwakftw @nikitaved
Repository: vue
Issue: .once modifier did'nt perform as expected if my event handler return null
Labels: improvement

### Version
2.6.11

### Reproduction link
[https://jsfiddle.net/q0v6m8dr/1/](https://jsfiddle.net/q0v6m8dr/1/)







### Steps to reproduce
1. bind a handler to an event which with a '.once' modifier 
3. set null for the hanlder's return value
2. trigger the event,  and  trigger again

### What is expected?
only the first trigger will invoke handler,  under '.once' influence

### What is actually happening?
subsequent trigger will also invoke handler beside the first one

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: go
Issue: x/image/tiff: add 32bit float grayscale support
Labels: NeedsInvestigation,FeatureRequest

Please add support for 32bit float grayscale tiff images. This is a common format in scientific and medical imaging.
Repository: godot
Issue: [TRACKER] List of unused signals
Labels: bug,topic:core,topic:editor,tracker

**Godot version:**
4.0.dev.custom_build. 321ce4d4c

**Issue description:**

With help of https://github.com/qarmin/godot_signal_checker (which could be rewritten to python to be able to put it inside CI in Godot repository) I found lot of potential unused signals with this methodology:

Added signals have at the beginning of line `ADD_SIGNAL(MethodInfo(\"`
Emitted signals have at the beginning of line `emit_signal(CoreStringNames::get_singleton()->`, `emit_signal(SceneStringNames::get_singleton()->` or `emit_signal(\"`
Connected signals have at the beginning of line `->connect(\"` or `connect_compat(\"`

**Signals which are emitted and connected but never added**
- [x] - dpi_changed
- [x] - drop_attempted
- [x] - modal_closed (#41920)

**Signals which are added but never emitted or connected**
- [x] - bake_finished
- [x] - clear_request
- [x] - copy_request
- [x] - item_custom_button_pressed
- [x] - item_group_status_changed
- [x] - item_lock_status_changed
- [x] - pause_pressed
- [x] - search

**Signals which are added and connected but never emitted**
- [ ] - autoload_changed
- [ ] - export_presets_updated
- [ ] - group_edited
- [x] - inputmap_changed
- [ ] - localization_changed
- [ ] - multiple_properties_changed
- [ ] - node_added
- [ ] - node_removed
- [ ] - preview_invalidated
- [ ] - property_edited
- [x] - removed_from_graph
Repository: rust
Issue: Consider renaming (`Re`)`EarlyBound` to `ReParam` and (`Re`)`LateBound` to `Bound`.
Labels: C-cleanup,A-type-system,A-lifetimes,T-compiler,T-types

This convention would be slightly less confusing due to aligning better with `Ty` and `ty::Const`.

On the other hand, the early-bound vs late-bound terminology is so baked-in that this might be hard.

cc @rust-lang/wg-traits @matthewjasper
Repository: pytorch
Issue: [DISCUSSION] Better user experience for debugging on Windows
Labels: module: build,module: windows,triaged

## Background
With https://github.com/pytorch/pytorch/pull/36039, we are now printing the traceback of exceptions in the command prompt. For example, before this change, if we throw an exception `c10::Error(SourceLocation, msg)`, it will only print something like `(no backtrace available)` But now we will get something below.
```cpp
00007FF6731716B9 00007FF6731716B0 bound_shape_inference [source.cpp @ 223]
00007FFBFAF3FAFF 00007FFBFAF3FA50 crt_at_quick_exit [C:\WINDOWS\System32\ucrtbase.dll @ <unknown line number>]
00007FFBFD1C7BD4 00007FFBFD1C7BC0 BaseThreadInitThunk [C:\WINDOWS\System32\KERNEL32.DLL @ <unknown line number>]
00007FFBFD32CED1 00007FFBFD32CEB0 RtlUserThreadStart [C:\WINDOWS\SYSTEM32\ntdll.dll @ <unknown line number>]
```

## Problem
However, even with https://github.com/pytorch/pytorch/pull/36039, it won't be that useful if PDBs are not distributed with the binaries. For example, you'll get something below without the PDBs.
```cpp
00007FF6731716B9 <unknown symbol address> <unknown symbol name> [source.exe @ <unknown line number>]
00007FFBFAF3FAFF 00007FFBFAF3FA50 crt_at_quick_exit [C:\WINDOWS\System32\ucrtbase.dll @ <unknown line number>]
00007FFBFD1C7BD4 00007FFBFD1C7BC0 BaseThreadInitThunk [C:\WINDOWS\System32\KERNEL32.DLL @ <unknown line number>]
00007FFBFD32CED1 00007FFBFD32CEB0 RtlUserThreadStart [C:\WINDOWS\SYSTEM32\ntdll.dll @ <unknown line number>]
```
So the major problem here are listed below:
1. Should we distribute the PDBs in the release / CI builds?
2. How do we distribute them?

## Plans
We definitely should distribute the PDBs when users need some debugging info. The possible options are listed below.
1. Distribute in the release builds. (use `/DEBUG:FULL` in the linker flags)
This is the easiest option, both for devs and users. However, the size of the binaries will be much larger. You may expect the package size to be nearly 1GB after the change.
2. Distribute them separately
It is based on the idea that when users needs debugging, they may download them and install them to the existing package. However, we may need to design the build job to generate them.

Any thoughts? cc @peterjc123 @malfet @ezyang
Repository: godot
Issue: GDScript cannot always infer types
Labels: topic:gdscript

**Godot version:**
3.2.1

**OS/device including version:**
Windows 10

The gdscript editor cannot seem to infer object types most of the time making it impossible to get popup help for near enough all objects. Without this functionality, coding is near impossible, especially for newcomers or those wishing to ensure the method/constant they are typing is correct. 

i.e. you expect on pressing '.' that the editor knows what the object type is and provide the correction information. Most other dynamically typed language editors provide this.

Example:
In the image below a collider was retrieve, yet on typing 'collider.' only top level functions were provided. It was only when the type was explicitly declared as with collider2, that the extra functions, specifically 'is_in_group' in my test case became available.

![image](https://user-images.githubusercontent.com/12863685/78500161-e451b000-774c-11ea-9f29-6296001a756d.png)
Repository: create-react-app
Issue: create-react-app should allow TypeScript imports outside `src`
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?

Code reuse is a good thing. It is not uncommon that a backend and a frontend can use the same code, and live in the same repository. The need for sharing code is particularly strong with TypeScript type definitions, because developers on the backend and the frontend want to make sure that they are building against a common types.

### Describe the solution you'd like

I don't know the CRA internals, but maybe one of the following:
- Allow `baseUrl` to point outside `.` to enable absolute imports like `import * as foo from 'common/foo``.
- Enable relative imports outside `src` like `import * as foo from '../../common/foo'`.

### Describe alternatives you've considered

There are [work-arounds](https://stackoverflow.com/a/61043925/1804173) using a combination of third-party cra-patching libraries. They are tedious to setup though (I worked 3 evenings on coming up with a solution), potentially fragile, and the use case seems so fundamental that I'm very surprised that it is not to supported out-of-the-box.
Repository: rust
Issue: Running rustdoc on code using quote generates false lint warnings for unused_braces
Labels: A-lints,P-medium,T-compiler,regression-from-stable-to-stable,C-bug,ICEBreaker-Cleanup-Crew

I tried this code:

```toml
[package]
name = "repro"
version = "0.1.0"
edition = "2018"

[dependencies]
quote = "=1.0.3"
```

```rust
use quote::quote;

pub fn repro() {
    let many = [1, 2, 3];

    let _together = quote! {
        #(#many),*
    };
}
```

I think this is a basic and common usage of the [quote](https://crates.io/crates/quote) crate.

I expected to see no warnings:

```
% RUSTFLAGS=-Dwarnings cargo +nightly-2020-04-04 build
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s

% RUSTFLAGS=-Dwarnings cargo +nightly-2020-04-04 doc
 Documenting repro v0.1.0 (/private/tmp/repro)
    Finished dev [unoptimized + debuginfo] target(s) in 0.82s
```

Instead, warnings are generated (and my CI build fails due to the `deny`):

```
% RUSTFLAGS=-Dwarnings cargo +nightly-2020-04-04 build
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s

% RUSTFLAGS=-Dwarnings cargo +nightly-2020-04-04 doc
 Documenting repro v0.1.0 (/private/tmp/repro)
warning: unnecessary braces around block return value
  |
  = note: `#[warn(unused_braces)]` on by default

    Finished dev [unoptimized + debuginfo] target(s) in 0.82s
```

Note that the warning only appears when running rustdoc.

### Meta

`rustc +nightly-2020-04-04 --version --verbose`:

```
rustc 1.44.0-nightly (74bd074ee 2020-04-03)
binary: rustc
commit-hash: 74bd074eefcf4915c73d1ab91bc90859664729e6
commit-date: 2020-04-03
host: x86_64-apple-darwin
release: 1.44.0-nightly
LLVM version: 9.0
```
Repository: go
Issue: encoding/xml: XMLName value of embedded structs type not used in Marshaller
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.14.1 windows/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
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Constantine\AppData\Local\go-build
set GOENV=C:\Users\Constantine\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=D:\Develop\golib
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=D:\Develop\go1.14.1
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=D:\Develop\go1.14.1\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\CONSTA~1\AppData\Local\Temp\go-build125187114=/tmp/go-build -gno-record-gcc-switches

</pre></details>

### What did you do?

Try to use XMLName in embedded type [play](https://play.golang.org/p/UyMZcLQG8R5) [stackoverflow](https://stackoverflow.com/questions/61041521/why-xmlname-value-of-embedded-structs-type-not-used-in-marshaller)

<pre>
type XMLForm struct {
	XMLName xml.Name
}
type Test struct {
	XMLForm
}
var t Test
t.XMLName.Local = "c:test"

xml.Marshal(&t)
</pre>

### What did you expect to see?

`<c:test></c:test>`

### What did you see instead?

`<Test></Test>`

It fails on go1.14.1\src\encoding\xml\marshal.go:  can't cast to xml.Name
```
482: } else if v, ok := xmlname.value(val).Interface().(Name); ok && v.Local != "" {
483:       start.Name = v
484: }
```
I also find a reason for this error https://golang.org/src/encoding/xml/typeinfo.go
Need to add idx of embed type to slice
```
78:   if tinfo.xmlname == nil {
++                                        && inner.xmlname != nil {
79:      tinfo.xmlname = inner.xmlname
++      tinfo.xmlname.idx = append([]int{i}, inner.xmlname.idx...)
80:   }
```
Repository: electron
Issue: MacOS: "Ask for a Review" functionality using SKStoreReviewController API 
Labels: enhancement :sparkles:,platform/macOS

Update: you can find a paid bounty for this issue here: https://bountify.co/electron-call-macos-requestreview-api

First working solution gets the bounty. Payout will continue to increase until a solution is found. I will make it public domain if the submitter doesn't.

---

For electron on MacOs, how do we call the "requestReview()" method in Apple's native SKStoreReviewController API?

In recent MacOS and iOS apps, Apple gave developers an easy way to just "ask for a review" using a simple requestReview() API call. It's an absolutely necessary feature, since getting ratings and reviews can be the difference-maker between a successful app and a failure. Apple has made it extremely seamless for users to rate your app in a single touch without leaving your app and going to the app store, which has been shown to make a significant impact between getting app reviews or not. However I have no idea how to implement it using Electron. It's such an essential feature in 2020.

> You can ask users to rate and review your app at appropriate times throughout the user experience. Make the request when users are most likely to feel satisfaction with your app, such as when they’ve completed an action, level, or task. Make sure not to interrupt their activity.
> To give users an easy way to provide feedback on the App Store or the Mac App Store, use the SKStoreReviewController API. You can prompt for ratings up to three times in a 365-day period. Users will submit a rating through the standardized prompt, and can write and submit a review without leaving the app.
> 

It's a simple API call with not much back and forth needed, and then you have seamless app review functionality. How do we implement this? It can be the difference maker between Electron being a successful app development framework for Mac App Store developers.

You can read more about the SKStoreReviewController API here:

https://developer.apple.com/app-store/ratings-and-reviews/

For example, if this is something that can be done using node's child_process.execFile, is there any documentation that shows where to store compiled native code inside the .App and call them from electron using node's child process?
Repository: godot
Issue: Switching views overlays 3D image on 2D view
Labels: bug,topic:rendering,topic:editor

Current master branch: 94fab213482fd944debc50e255e7b395d391cc33
Windows 10 (latest NVIDIA drivers)

As in GIF. Of course that's not proper use of views, nodes I've put are for 3D usage, but I can't recall that previous versions preserved similar behavior of caching 3D image on top of 2D view.

![godot-overlay](https://user-images.githubusercontent.com/1110337/78504280-57b6ea00-776c-11ea-9b7b-6d5046321612.gif)