sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Add suggestion/explanation to error on trying to mutably borrow immutable reference
Labels: C-enhancement,A-diagnostics,P-low,T-compiler,WG-diagnostics

```rust
    let mut mem_buffer : &[u8] = &b"foo"[..];
    let mut reader = &mut mem_buffer as &std::io::Read;
    let mut read_buffer = [0u8, 10];
    reader.read(&mut read_buffer);
```

reports

```
error[E0596]: cannot borrow immutable borrowed content `*reader` as mutable
 --> src/main.rs:5:5
  |
5 |     reader.read(&mut read_buffer);
  |     ^^^^^^ cannot borrow as mutable
```

Which is correct, but the fix is to modify the creation of the `reader` variable. While this case is easy, it's probably less so in the general case. Possible avenues of improvement:

1. The easy way this error message can be improved is to mention that the type is `&T`, but should be `&mut T`.
2. If there are explicit type annotations on the variable, a note should point to it
3. If the variable's type is inferred, a note should point to its initializer and maybe even do some primitive checks that can lead the developer towards the solution.
Repository: electron
Issue: Per monitor DPI awareness causes issues with window positioning and sizing
Labels: platform/windows,machine-dependent,bug :beetle:,bug/regression :leftwards_arrow_with_hook:,2-0-x,5-0-x,component/BrowserWindow

As per https://github.com/electron/electron/issues/9560 where previous issues regarding this were collapsed into.

If you have one monitor with non-100% scaling and one monitor with 100% scaling both `setSize` and `setPosition` do not act as expected (they always set incorrectly by a factor exactly equal to the scale factor of the screen)

A proposed workaround is #9708 but that simply reverts the addition of the feature instead of fixing the underlying cause.

All future issues regarding DPI scaling and window positioning / sizing should be merged into this one.
Repository: flutter
Issue: secondaryAnimation in Router buildTransitions is never started
Labels: framework,d: api docs,f: routes,P2,team-framework,triaged-framework

I’m trying to run second example from: https://docs.flutter.io/flutter/widgets/ModalRoute/buildTransitions.html

But it seems that `secondaryAnimation` is not started, it’s in `dismissed` state. When I print `secondaryAnimation.toString()` I’m getting
`kAlwaysDismissedAnimation➩ProxyAnimation➩ProxyAnimation`

From the sources of `animation.dart` I can read:
```
// An animation that is always dismissed.
//
// Using this constant involves less overhead than building an
// [AnimationController] with an initial value of 0.0. This is useful when an
// API expects an animation but you don't actually want to animate anything.
const Animation<double> kAlwaysDismissedAnimation = const _AlwaysDismissedAnimation();
```

And in `routes.dart` it’s indeed initialized to `final ProxyAnimation _secondaryAnimation = new ProxyAnimation(kAlwaysDismissedAnimation);`

Maybe I'm doing something wrong but I couldn't find a way to initialize `secondaryAnimation` with different value.
Repository: angular
Issue: Leave animation triggers child ngOnDestroy immediately
Labels: type: bug/fix,area: animations,freq2: medium,P3

<!--
PLEASE HELP US PROCESS GITHUB ISSUES FASTER BY PROVIDING THE FOLLOWING INFORMATION.

ISSUES MISSING IMPORTANT INFORMATION MAY BE CLOSED WITHOUT INVESTIGATION.
-->

## I'm submitting a...
<!-- Check one of the following options with "x" -->
<pre><code>
[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  <!-- Please search GitHub for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
</code></pre>

## Current behavior
<!-- Describe how the issue manifests. -->
`ngOnDestroy` is called when the `:leave` animation starts.

## Expected behavior
<!-- Describe what the desired behavior would be. -->
`ngOnDestroy` should be called after the `:leave` animation finishes.

## Minimal reproduction of the problem with instructions
<!--
For bug reports please provide the *STEPS TO REPRODUCE* and if possible a *MINIMAL DEMO* of the problem via
https://plnkr.co or similar (you can use this template as a starting point: http://plnkr.co/edit/tpl:AvJOMERrnz94ekVua0u5).
-->
[Reproduction plunkr](http://plnkr.co/edit/RL8FsFb0WtbTIuMAQGbq?p=preview)

1. Wait for the `:enter` animation to finish. The element background is red during the whole duration of the animation.
2. Click the "Hide" button. The red background is removed immediately when the animation starts.

If replays are necessary, use the "Show" button to restart the reproduction.

## What is the motivation / use case for changing the behavior?
<!-- Describe the motivation or the concrete use case. -->
If the destroy method makes visual changes to the component or directive, these will be visible during the leave animation. This results in unexpected behavior for the user.
 
## Environment

<pre><code>
Angular version: 4.4.6
Also reproducible in 5.0.0-rc.3
<!-- Check whether this is still an issue in the most recent Angular version -->

Browser:
- all
</code></pre>
Repository: rust
Issue: Failing tests for x86_64-unknown-linux-gnux32 
Labels: O-linux,C-bug,O-x32

As can see [here](https://travis-ci.org/rust-lang/rust/jobs/290436965), the are failing tests for x86_64-unknown-linux-gnux32

[run-pass](https://travis-ci.org/rust-lang/rust/jobs/290436965#L5218):
- `lto-unwind.rs`
- `backtrace-debuginfo.rs` (Fixed by https://github.com/rust-lang/rust/pull/45652)
- `backtrace.rs` (Fixed by https://github.com/rust-lang/rust/pull/45652)
- `command-before-exec.rs` (Fixed by https://github.com/rust-lang/rust/pull/45652)
- `command-exec.rs` (Fixed by https://github.com/rust-lang/rust/pull/45652)
- `out-of-stack.rs` (Fixed by https://github.com/rust-lang/rust/pull/45652)
- `stack-probes-lto.rs` (Fixed by https://github.com/rust-lang/rust/pull/45652)
- `stack-probes.rs` (Fixed by https://github.com/rust-lang/rust/pull/45652)
- `wait-forked-but-failed-child.rs` (Fixed by https://github.com/rust-lang/rust/pull/45652)

@alexcrichton [suggests](https://github.com/rust-lang/rust/pull/45391#issuecomment-338087194) that it is a problem with stack walk.

libstd:
- `net::tcp::tests::timeouts`
- `net::udp::tests::timeout`
- `sys::imp::ext::net::test::timeouts`
- `io::cursor::tests::test_box_slice_writer` (segfault)

The timeout are related with `timeval`, `setsockopt` and `SO_RCVTIMEO`.

Edit 1: update to include https://github.com/rust-lang/rust/pull/45652 fixes
Repository: TypeScript
Issue: Compiler gives two different errors for wrong number of type arguments
Labels: Bug,Domain: Error Messages

```ts
class B<T, U = number> {
    t: T
    u: U
}
class D extends B<string, string, string> {
                ~
                Generic type B<T, U> requires between 1 and 2 type arguments.
    d: number
}
let b = new B<string, string, string>()
        ~~~
        Expected 1-2 type arguments, but got 3.
```

**Expected behavior:**
You get a wordier, less helpful message when incorrectly extending a base class. You get a terser, more detailed, message when incorrectly creating an instance of the base class.


**Actual behavior:**
Both messages should be the new terse, detailed message. I forgot to change this when I added the new message.
Repository: TypeScript
Issue: Bug(?): Using attribute type of extended generic param and an intersection type
Labels: Bug

**TypeScript Version:**  2.7.0-dev.20171020

**Code**

```ts
interface Container {
  foo: Foo;
}

interface Foo {
  a: string;
}

interface Bar {
  b: string;
}

function example<T extends Container>(): T['foo'] & Bar {
  return {
    a: 'foo',
    b: 'bar',
  };
}
```

**Expected behavior:**

I expect the code to compile. `T` extends `Container`, so it knows `T['foo']` must be assignable to `Foo`, even if the interface is extended, as the function signature allows. Replacing `T['foo'] & Bar` in the function's return type with `Foo & Bar` works fine.

**Actual behavior:**

Compile error:

```
index.ts(15,5): error TS2322: Type '{ a: string; b: string; }' is not assignable to type 'T["foo"] & Bar'.
  Object literal may only specify known properties, but 'a' does not exist in type 'T["foo"] & Bar'. Did you mean to write 'a'?
```
Repository: go
Issue: go/ast: trailing func comments mishandled in CommentMap
Labels: help wanted,NeedsFix

Working example: https://play.golang.org/p/TlsDxVbGow

Prints: `g: "trailing comment in f\n"`

Seems like the correct output should either be nothing (if it is associated with `_ = x`), or `f: "trailing comment in f\n"`.

What's currently happening is that the "_ = x" in func f is the most recent "important" node when we encounter the comment. Since the comment isn't on the line immediately following "_ = x", it doesn't
get associated with it. We don't look further up the "important nodes" stack to notice that it's within the bounds of f. Instead, we just give up and associate it with g.

/cc @griesemer
Repository: vscode
Issue: Explore improving GDPR annotations
Labels: plan-item

The current GDPR annotations are comment based. Thus, if we are not careful, they can easily go out of sync with the actual code. Scope of this exploration:
- using interfaces and types
- listing rules and quick fixes
Repository: vue
Issue: Asset support for functional components
Labels: intend to implement,feature request,improvement,has PR

### What problem does this feature solve?
Functional components with templates allow users to improve performance without sacrificing readability or ease of use. However, currently these do not support the "components" option. This limits this feature a lot, to a very limited set of use cases. 

### What does the proposed API look like?
Simply support the components option just like non-functional components

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: TypeScript
Issue: Polymorphic `this` breaks when a module exports a variable and interface with the same name
Labels: Bug

Importing a variable that has a corresponding interface of the same name from a module causes unexpected behavior.

In the screenshot below, the function, doSomething, should return the type `Model<number>` due to polymorphic `this`; however, it returns `Model<T>`, which is unusable.

<img width="1270" alt="screen shot 2017-10-20 at 11 02 03 pm" src="https://user-images.githubusercontent.com/9221137/31848679-40fae1ca-b5ec-11e7-9db3-bb8b250e2c95.png">


Here is an easy way to reproduce this behavior:
1) `npm install -g @types/sequelize sequelize`
2) Replace `node_modules/@types/sequelize/index.d.ts` with the following
```ts
declare namespace sequelize {
    interface Model<T>  {
        doSomething(arg: T): this;
    }
}

declare var sequelize: { Model: sequelize.Model<any> };

export = sequelize;
```
3) create a file with the following contents:
```ts
import { Model } from 'sequelize';

let a: Model<number> = null as any;


a.doSomething(5).doSomething();

```

Workaround:
Use `import * as ...` syntax and the names will resolve correctly.

<img width="611" alt="screen shot 2017-10-20 at 11 22 28 pm" src="https://user-images.githubusercontent.com/9221137/31848782-9950104c-b5ed-11e7-8766-cbc1c95d9939.png">
Repository: vue
Issue: Alert (possibly fix) SSR Mismatch in Production
Labels: improvement

### What problem does this feature solve?
Currently there is no way to receive alerts (and possibly rerender) in production concerning SSR vs VDom mismatch.  

This is critical because different browsers will handle this in unexpected ways.  For instance, I just finished trouleshooting an issue that is specific to Windows 10 and IE11 where a rendered vdom tree does not match ssr rendered html and causes a white screen.  Chrome and other browsers were able to recover. The mismatch renders fine when navigating to this from an already rendered vue. Just not when the initial rendering happens with a specific page.

Discussion in forum.  
https://forum.vuejs.org/t/ssr-render-mismatch-error-emit-in-production/20083

### What does the proposed API look like?
I think the bulk of code currently lives here.

https://github.com/vuejs/vue/blob/adff0084e1b7bc4b8ffa2b87390c66afbc435582/src/core/vdom/patch.js#L662

I think during initial ssr render we need more granular flags to opt in to alerts on this behavior.  Currently it is only NODE_ENV 

Initial (maybe too verbose) thoughts would be.
  WARN_ON_SSR_MISMATCH
  RECOVER_ON_SSR_MISMATCH
  
Then if those are true we can change behavior.

I understand that this is performance critical so am very open to suggestions.  I would be willing to implement this myself in a PR.

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: rust
Issue: RawVec stores a capacity field even if T is zero-sized
Labels: I-slow,T-libs-api,A-specialization,C-feature-accepted,I-heavy,A-layout,A-zst

When `std::mem::size_of::<T>() == 0` `RawVec<T>` has always a capacity equal to `std::usize::MAX` elements. It currently stores a `cap: usize` that always contains this value but doing so is unnecessary in this case.

@withoutboats this would be a not so far fetched case for allowing `struct` specialization like @arielb1 proposed.
Repository: rust
Issue: likely/unlikely intrinsics fail to propagate through inline functions
Labels: A-LLVM,T-compiler,C-bug

[See it live](https://godbolt.org/g/WhPRDs):

```rust
#![feature(core_intrinsics)]
extern crate core;
use core::intrinsics::unlikely;

#[inline(always)]
fn test(x: bool) -> bool {
    unsafe {
        unlikely(x)
    }
}

pub fn foo(x: u32) -> u32 {
  if test(x == 0) { 1 } else { x * 2 } 
}

pub fn foo2(x: u32) -> u32 {
  unsafe {
  let c = unlikely(x == 0);
  if c { 1 } else { x * 2 } 
  }
}

pub fn bar(x: u32) -> u32 {
  if x == 0 { 1 } else { x * 2 } 
}
```

`foo2` generates:

```asm
        push    rbp
        mov     rbp, rsp
        test    edi, edi
        je      .LBB1_1
        add     edi, edi
.LBB1_3:
        mov     eax, edi
        pop     rbp
        ret
.LBB1_1:
        mov     edi, 1
        jmp     .LBB1_3
```

but `foo` generates the same assembly as `bar` instead of the same assembly as `foo2`:

```asm
        push    rbp
        mov     rbp, rsp
        lea     ecx, [rdi + rdi]
        test    edi, edi
        mov     eax, 1
        cmovne  eax, ecx
        pop     rbp
        ret
```
Repository: vue
Issue: Mouse button modifiers for "v-on" should have more precise aliases
Labels: feature request,has PR

### What problem does this feature solve?
Currently mouse button modifiers, introduced in #4866, are `left`, `middle`, `right` for `$event.button` values `0`, `1`, `2` correspondingly. But that is only correct for the "default" right-handed layout. In the left-handed mode (when the buttons are switched in the OS) the right button has `0` value and the left button - `2`. Besides, also some right-handed users may reverse or remap the mouse buttons. And working with code with these names for mouse buttons may lead to confusion and bugs among developers not familiar with the "default" right-handed mode being the target for these modifiers.

### What does the proposed API look like?
Keep `left` and `right` as deprecated and add `main` and `secondary` as their aliases.

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: vscode
Issue: Allow to open two distinct editors side by side in one group
Labels: feature-request,workbench-editors

VsCode has the ability to horizonatally split an editor window. When you execute `code --diff file1 file2` both files are opened side by side in a single editor window with a single header tab. A similar view is presented when you edit the VsCode settings.

This is splitting. It would be nice to be able to do this for my own files to have multiple views of the same file. What would make it actually usable would be the following three enhancements.

1. The option to split either horizontally or vertically.
1. The ability to move focus from one split pane to another.
1. The ability to unsplit (revert the editor back to a single pane).

What we currently have is a keyboard shortcut "workbench.action.splitEditor" which doesn't actually split an editor at all, instead it just opens the same file in another editor in a different editor group. This is not editor splitting which by definition should occur in the same editor tab.

Calling opening a file in another editor group 'splitting' when there is already nascent functionality to support proper splitting is a pointless ambiguity that serves only to reduce the possibility that the editor will ever support proper splitting any time in the near future.

Proposal:

1. Rename "workbench.action.splitEditor" to "workbench.action.openInNewEditorGroup"
2. Make the VsCode diff view usable by adding a keyboard shortcut to permit cycling focus from one editor pane to the other.
3. Add support to split open editor vertically or horizontally by the addition of the additional keyboard shortcuts "editor.action.splitHorizontal", "editor.action.splitVertical" and "editor.action.unsplit".
Repository: rust
Issue: Document arithmetic operations on Instant
Labels: C-enhancement,P-medium,T-libs-api,A-time

Some questions that have come up about using Instants:

1. What meaning does `Instant -= Duration` have?
2. What are the preconditions on the instant and the duration, so that it does not panic or cause arithmetic overflow assertions? One user noticed that `instant -= duration` can trip this assertion (specifically on Windows).
Repository: angular
Issue: Sorting an array displayed with ngForOf applies void animation state to some elements
Labels: type: bug/fix,area: animations,freq2: medium,P3

## I'm submitting a...
<!-- Check one of the following options with "x" -->
<pre><code>
[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  <!-- Please search GitHub for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
</code></pre>

## Current behavior
When displaying elements of an array using ngForOf and animations are defined for those elements, after sorting the array using Array.prototype.sort the void animation state is applied to some of the elements.


## Expected behavior
The void state should not be applied to elements that are being displayed.


## Minimal reproduction of the problem with instructions
~https://plnkr.co/edit/MPAQhIlOXeyHv3HX66C5
Click "Create" to display a list of items, which are configured through the animations API to be colored blue in the "1" state and red in the void state, and to transition between the two. The items correctly transition from red to blue upon creation. Click "Sort" to sort the list. After it is sorted you will see some of the items transition from blue to red, indicating the void state even though all of the items are still displayed (as they should be).~

The original reproduction above no longer exhibits the issue, but using a Material Stepper you can see what appears to be the same bug.
https://stackblitz.com/edit/angular-zzcx1r?file=src%2Fmain.ts

## What is the motivation / use case for changing the behavior?


## Environment

<pre><code>
Angular version: 4.4.6

Browser:
- [x] Chrome (desktop) version 61.0.3163.91
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [x] Firefox version 56.0
- [x] Safari (desktop) version 11.0
- [ ] Safari (iOS) version XX
- [x] IE version 11.674.15063.0
- [x] Edge version 40.15063.674.0
</code></pre>
Repository: neovim
Issue: VimL: string(): E724 with obj.func = obj.func
Labels: vimscript,compatibility

```vim
let obj = {}
function obj.func()
endfunction

let obj.func = obj.func

echom string(obj)
```

Throws, but still displays:
```
E724: unable to correctly dump variable with self-referencing container
{'func': function('31', {E724@0})}                                     
```

`let obj.func = get(obj, 'func')` seems to work around this.

Shouldn't this behave the same, and be a no-operation after all?

It works in Vim.

Related issues:
https://github.com/neovim/neovim/issues/5902#issuecomment-293622862 links to https://github.com/neovim/neovim/pull/5529#issuecomment-271541590.

Version v0.2.1-1057-ge35a66d39
Version v0.3.0-1029-g48967695c
Repository: godot
Issue: Issue with flipping 2D characters (non uniform scaling)
Labels: discussion,topic:physics

Hello, so I wanted to try out 3.0 and began porting a game prototype I had in godot 2.1.4 and got a ridiculous "bug?"
![somethingwrong2](https://user-images.githubusercontent.com/15176623/31867076-4551320a-b75f-11e7-9eac-8f8126759a9a.gif)

This was working fine in godot 2.1.4. Flipping the main node of the character (AKA KinematicBody2D). 

but why like that? so all the stuff that are child of the character will flip with the character too, like weapons scenes with its own hitbox and script, particle effects, more sprites, etc. In Godot 2.1.4 actually worked really well without any physics problem as long as you don't use weird numbers.

the way I did it was changing the node scale of the main node (KinematicBody2D) from (1, 1) facing right to (-1, 1) facing left.
 
Feature Request: this is not crazy needed but maybe a Flip H and Flip V checkbox in the physicsbodies like in the Sprite node. that way you don't have to flip every single child on the character and you don't mess with the scale numbers. at be able of doing it of code or fixing the bug I'm having

I know you guys will say you're not supposed to change the scale of a physicsbody but to me it makes
more sense to flip the main node of the character instead of the sprite node or any other node.

having all the weapons and stuff as a child of the sprite node doesn't feel right and at the same time even if thats the way of doing it, you have to tell new people that that's the way of doing it.

**Issue description:**
the characters goes crazy and flips H and V very fast when flipping the character (that didn't happen in 2.1.4)

**Steps to reproduce:**
when moving to the left flip the main node with set_scale((-1,1) in script then ingame move to the left and it happens

**Link to minimal example project:**
[platformTEST.zip](https://github.com/godotengine/godot/files/1405432/platformTEST.zip)
godot 3.0 build 2017-10-22
Repository: rust
Issue: Unnecessary compares and branches in asm output
Labels: I-slow,C-enhancement,C-optimization

https://godbolt.org/g/62GNZf
```rust
pub fn f1(v: &mut Vec<f32>) {
  v.clear();
}

pub fn f2(v: &mut Vec<f32>) {
  unsafe { v.set_len(0); }
}
```
```asm
example::f1:
  push rbp
  mov rbp, rsp
  cmp qword ptr [rdi + 16], 0
  je .LBB0_2
  mov qword ptr [rdi + 16], 0
.LBB0_2:
  pop rbp
  ret

example::f2:
  push rbp
  mov rbp, rsp
  mov qword ptr [rdi + 16], 0
  pop rbp
  ret
```

In f1, the lines `cmp qword ptr [rdi + 16], 0` and `je .LBB0_2` should be optimized away, but aren't, why?
(It sets the len to 0 if it's not 0, otherwise leaves it at 0. The len will be 0 afterwards either way, so it should eliminate the check and just set it to 0 like `set_len(0)`.)

I thought I'd open this issue because I don't think such optimization opportunities should be left on the table because it accumulatively affects a lot of code.