sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Field ordering still causes extra memcpy
Labels: A-LLVM,I-slow,C-enhancement,E-needs-test,T-compiler,A-mir-opt,A-mir-opt-nrvo

This is similar to #56356 except this time with more fields:

```rust
use std::mem;

struct SV {
    capacity: usize,
    disc: usize,
    data: [usize; 40],
}

impl SV {
    fn new() -> SV {
        SV { data: unsafe { mem::uninitialized() },
            disc: 0,
            capacity: 0 }
    }
}

pub struct L {
    a: SV,
    b: SV
}

pub struct Allocation<T> {
    f: *mut T,
}

impl<T> Allocation<T> {
    pub fn init(self, value: T) {
        use std::ptr;
        unsafe {
        ptr::write(self.f, value);
        }
    }
}

#[inline(never)]
pub fn foo(a: Allocation<L>) {
    a.init(L {
        a: SV::new(),
        b: SV::new()
    });
}
```

gives:
```asm
example::foo:
        sub     rsp, 680
        xorps   xmm0, xmm0
        movaps  xmmword ptr [rsp], xmm0
        movaps  xmmword ptr [rsp + 336], xmm0
        mov     rsi, rsp
        mov     edx, 672
        call    qword ptr [rip + memcpy@GOTPCREL]
        add     rsp, 680
        ret
```
vs  moving capacity to the end of the struct:
```asm
example::foo:
        mov     qword ptr [rdi], 0
        xorps   xmm0, xmm0
        movups  xmmword ptr [rdi + 328], xmm0
        mov     qword ptr [rdi + 664], 0
        ret
```

The problem is reproducible with C++ so I'll file a new llvm bug too.
Repository: pytorch
Issue: Check whether _cudnn_rnn_flatten_weight can avoid changing the TensorImpl or Storage pointer of tensors in `weight_arr`
Labels: module: cudnn,triaged,module: assert failure

https://github.com/pytorch/pytorch/pull/16305 adds checks for TensorImpl and Storage pointer equality when a function modifies its input tensors (via inplace or out-variants) in VariableType functions. However, `_cudnn_rnn_flatten_weight` doesn't currently pass this check because it does in-place update into `weight_arr` that changes its internal tensors' TensorImpl or Storage pointer. We should investigate whether it's possible to fix this and make it also pass the pointer equality check.

cc @csarofeen @ptrblck @xwang233
Repository: godot
Issue: Improve nonexistent input action message when using a Shortcut resource in a Button's Shortcut property
Labels: enhancement,usability,topic:input,topic:gui

x11
https://github.com/godotengine/godot/commit/869887641f3d31f19837a34da116039a26618cb0

Is there a way to make the error more specific? (point to the Button/ShortCut)

![image](https://user-images.githubusercontent.com/4741886/52169392-d3b43d00-2737-11e9-911a-8c4aeae59967.png)

Steps:
1. Create a Button
2. Add "ShortCut"
3. Add "InputEventAction"
3. Run and press any key
Repository: opencv
Issue: Regression: TiffDecoder fails to read 32F tiled tiffs
Labels: priority: low,category: imgcodecs

##### System information (version)

- OpenCV => 3.4.1 or greater

##### Detailed description

As of the 3.4.1 release the TiffDecoder no longer reads single channel tiled 32 bit floating point tiffs. It fails with the error message `Can not read scanlines from a tiled image` this looks to be the result of #10493 where all 32 bit float tiffs are forced to be read with the scanline interface where before they were read using either the strip or tile interface.
Repository: TypeScript
Issue: Feature Request: LanguageServiceHost plugin
Labels: Suggestion,In Discussion

## Search Terms

language service host compiler plugin

Refs #16607

## Suggestion

Currently, TypeScript only supports proxying the [language service](https://github.com/Microsoft/TypeScript/wiki/Writing-a-Language-Service-Plugin).  It would be good to have an officially supported way of being able to proxy the `LanguageServiceHost` as well.

## Use Cases

Being able to provide a plugin that changes how the language service host behaves is often a requirement for use cases where the default behaviour of TypeScript in Visual Studio Code does not mirror the compile time behaviour when using tools that implement a language service host with TypeScript.

For example in [Deno](https://denoland.github.io/deno), we utilise full path names for modules, including TypeScript ones.  The standard language service host disallows this (because it assumes that the module name won't end in `.ts` at runtime).

There are likely to be other use cases where the behaviour of the language service host differs when using other forms of TypeScript other than `tsc` and Visual Studio Code, where it would be useful to allow plugins to mimic that behaviour, in particular in Visual Studio Code, so that the editing experience can be more rich.

## Examples

I currently have a [plugin](https://github.com/kitsonk/deno_ls_plugin/blob/c5ed4d532a7154e1c40d991b0aef3f03f89add06/index.ts#L7-L12) which just monkey patches the LanguageServiceHost to inject similar logic for module resolution to what is done in Deno.  This is because I cannot return a proxy, like I could with the `LanaguageService`.

## 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: Some problem caused by the Android multitasking window
Labels: team,platform-android,engine,customer: alibaba,P2,found in release: 1.22,team-android,triaged-android

1.When you return to the app from the multitasking window interface, the screen will blink
screen capture：https://drive.google.com/open?id=1cNeIJFWwFLDMY7QDli8REf1myiHb2nRo

2.When you open the multitasking window interface, if you accidentally touch the bottom navigation bar, after returning, the effect will not disappear.
screen capture：https://drive.google.com/open?id=1kPNqtLjMHEmXjWCsdfJpll1-fvIWIaOQ
Repository: TypeScript
Issue: TS is overly picky when declaring a class constructor type
Labels: Bug,Help Wanted,Good First Issue

**TypeScript Version:**  3.4.0-dev.20190202

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** class, extend, constructor, any[]

**Code**

```ts
type ClassConstructor = new(...args: any[]) => {}

function mixin<C extends ClassConstructor>(Class: C) {
  return class extends Class {}
}
```

**Expected behavior:**

I should be able to replace `...args: any[]` with `...args: unknown[]`, or any other signature.

**Actual behavior:**

```
Error: Type 'C' is not a constructor function type. [2507]
```

**Playground Link:** https://www.typescriptlang.org/play/index.html#src=type%20ClassConstructor%20%3D%20new(...args%3A%20unknown%5B%5D)%20%3D%3E%20%7B%7D%0D%0A%0D%0Afunction%20mixin%3CC%20extends%20ClassConstructor%3E(Class%3A%20C)%20%7B%0D%0A%20%20return%20class%20extends%20Class%20%7B%7D%0D%0A%7D
Repository: pytorch
Issue: [feature request] Store accumulated gradients in separate GPU or on CPU memory
Labels: triaged,module: data parallel

When using the DataParallel, accumulated gradients seem to be gathered and stored on the primary GPU.  Since the primary GPU is also used to compute forward passes and store optimizer states, it uses disproportionately more memory than other GPUs.  Due to the large size of my model, I am unable to store accumulated gradients in a single GPU while using the same GPU to compute future losses and gradients.

I am wondering if it is possible to gather gradients computed in a DataParallel model to a separate, dedicated GPU, or to even store them in CPU memory along with the optimizer.

More details can be found on this [pytorch topic](https://discuss.pytorch.org/t/uneven-gpu-utilization-during-training-backpropagation/36117).
Repository: pytorch
Issue: split_with_sizes should accept a LongTensor as the split_sizes parameter
Labels: feature,triaged,module: numpy

## 🚀 Feature
The function `torch.split` partitions a tensor into chunks of equal size (except last) if called with an `int` parameter:
```python
torch.split(torch.arange(10), split_size_or_sections=3)
(
    tensor([0, 1, 2]), 
    tensor([3, 4, 5]), 
    tensor([6, 7, 8]), 
    tensor([9])
)
```
or chucks of specific sizes if called with a list of ints:
```python
torch.split(torch.arange(10), split_size_or_sections=[7, 3])                                                                                           
(
    tensor([0, 1, 2, 3, 4, 5, 6]), 
    tensor([7, 8, 9])
)
```
This second behavior is delegated to the (undocumented) function `torch.split_with_sizes` which only accepts a list of integers as parameter. I would like to be able to call `torch.split` and `torch.split_with_sizes` using a `LongTensor` instead of a list of ints.

## Motivation
In the project I am working on, the sizes of the split are part of the data itself, and it makes sense to me to store them as tensors rather than simple lists. With the current behavior I find myself writing this quite often:
```python
features: torch.Tensor
splits: torch.LongTensor
torch.split(features, splits.tolist())
```
I am afraid that the conversion to a native list might be inefficient and, in general, error-prone.

## Changes
- The signature of `torch.split` should become:
  `torch.split(tensor: torch.Tensor, split_size_or_sections: Union[int, Sequence[int], torch.LongTensor], dim: int=0)`
- The signature of `torch.split_with_sizes` should become:
  `torch.split(tensor: torch.Tensor, split_sizes: Union[Sequence[int], torch.LongTensor], dim: int=0)`
- (Optionally) I think `split_with_sizes` should have a docstring so that one can easily call it instead of calling `torch.split` which in turn delegates to `torch.split_with_sizes`

cc @mruberry @rgommers @heitorschueroff
Repository: rust
Issue: "--emit mir" does not emit drop shim
Labels: C-enhancement,A-destructors,T-compiler,A-MIR

When compiling code that generates drop shims, such as
```rust
struct Bar(u16); // ZSTs are tested separately

static mut DROP_COUNT: usize = 0;

impl Drop for Bar {
    fn drop(&mut self) {
        assert_eq!(self.0 as usize, unsafe { DROP_COUNT }); // tests whether we are called at a valid address
        unsafe { DROP_COUNT += 1; }
    }
}

fn main() {
    let b = [Bar(0), Bar(1), Bar(2), Bar(3)];
    assert_eq!(unsafe { DROP_COUNT }, 0);
    drop(b);
    assert_eq!(unsafe { DROP_COUNT }, 4);

    // check empty case
    let b : [Bar; 0] = [];
    drop(b);
    assert_eq!(unsafe { DROP_COUNT }, 4);
}
```
I would expect the file created by `rustc --emit mir` to also contain the drop shim.  However, that is not the case.

This is related to https://github.com/rust-lang/rust/issues/53532 but not identical: the code for selecting what gets dumped with `-Zdump-mir` and `--emit=mir` is, from all I can see, entirely independent.  Just the actual printing is shared.
Repository: godot
Issue: Light2d shadows do not seem to affect polygons
Labels: bug,topic:rendering,confirmed,topic:2d

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
3.1 beta 3


**OS/device including version:**
windows 10, nvidia gtx 1070


**Issue description:**
light2d does not affect polygons


**Steps to reproduce:**
create light and place polygon near it


![image](https://user-images.githubusercontent.com/2881755/52178404-670d7100-2811-11e9-92d6-f841fdf5ee54.png)
Repository: godot
Issue: The theme editor preview is tiny on hiDPI displays
Labels: enhancement,topic:editor,confirmed,usability



**Godot version:**
<!-- Specify commit hash if non-official. -->
v3.1.beta3.official


**OS/device including version:**
<!-- Specify GPU model and drivers if graphics-related. -->
 Model Name:	MacBook Pro
  Model Identifier:	MacBookPro14,3
  Processor Name:	Intel Core i7
  Processor Speed:	3.1 GHz
10.14.3

**Issue description:**
<!-- What happened, and what was expected. -->
Was going to create a new theme.
Went to the control node, chose theme, created new theme, clicked "open editor"
The edit theme editor opened in the middle bottom.

Expected:
Editor should open with fonts the same size as the rest of the UI of the Godot engine.

Actual:
The UI fonts are tiny. See screenshot.


<img width="1416" alt="screen shot 2019-02-03 at 8 24 33 am" src="https://user-images.githubusercontent.com/8691/52179338-10ab1e80-278e-11e9-9487-842ef4b9b0af.png">
Repository: godot
Issue: Path2D and RayCast2D line width doesn´t adapt to canvas editor zoom
Labels: enhancement,discussion,topic:editor,usability

<!-- 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. -->
869887641f3d31f19837a34da116039a26618cb0


**OS/device including version:**
<!-- Specify GPU model and drivers if graphics-related. -->
Win7

**Issue description:**
<!-- What happened, and what was expected. -->

Path2D and RayCast2D line doesn´t follow editor zoom like particles2d rect does... lines 98 to 102 in path2d.cpp are:

```
#if TOOLS_ENABLED
		const float line_width = 2 * EDSCALE;
#else
		const float line_width = 2;
#endif
```

I think that editor_scale is not the property that should be used in that code, but i´m unable to find what property and file should be used to maintain the size no mathers the zoom.

The problem:

![path2dtinyline](https://user-images.githubusercontent.com/11712737/52181383-8399b100-27f1-11e9-9e7f-43b15d92df50.gif)
Repository: TypeScript
Issue: `symbol` does not match interface
Labels: Bug,Domain: lib.d.ts

**TypeScript Version:**  playground and 3.3

**Search Terms:** symbol interface

**Code**

```ts
const sym: symbol = Symbol();

function f(arg: { constructor?: unknown }): void {
}

f(sym);
```

**Expected behavior:**
`symbol` is a non-nullish primitive, as such, it should be able to potentially match any interface.

**Actual behavior:**
Type error.

**Playground Link:** https://www.typescriptlang.org/play/#src=const%20sym%3A%20symbol%20%3D%20Symbol()%3B%0D%0A%0D%0Afunction%20f(arg%3A%20%7B%20constructor%3F%3A%20unknown%20%7D)%3A%20void%20%7B%0D%0A%7D%0D%0A%0D%0Af(sym)%3B

**Related Issues:** #29536 (discovered in relation to #28900), #1863, #24587
Repository: pytorch
Issue: Very poor Uniform() sampling near floating 0.0
Labels: triaged,module: random

## 🐛 Bug

When using uniformly-distributed random number generation, especially using `float32`, over a range including 0, the sampling code ignores the extra precision of floating-point around 0, leading to very bad sampling.

The generated floats also have at most 24 (`float32`) or 53 (`float64`) bits of entropy.

**Consequence 1:** Multiplying any PyTorch float32 `uniform_(0,1)` by a large integer like `2**33` is guaranteed to give an integer.
**Consequence 2:** It is actually possible to generate an exact `0.0` using the `float32` **`uniform_(0,1)`,** with probability 2**-24, whereas that should actually have been 2**-149.
**Consequence 3:** It is not possible to generate a `float32` strictly between `0.0` and `2**-24` with `uniform_(0,1)`, whereas it should have been possible with probability 2**-24.

## To Reproduce

*Test 1:* If the following is `!= 0`, the RNG sucks: `torch.FloatTensor(int(1e8)).uniform_().eq(0).sum()`
*Test 2:* If the following is `== -inf`, the RNG sucks: `torch.FloatTensor(int(1e8)).uniform_().log().sum()`

## Expected behavior

*Test 1:* A return of `0`.
*Test 2:* A finite, negative value.

## Environment

_Not relevant._

 - PyTorch Version 1.1.0a0+c865d46, but the same problem dates back to the beginning of the history of this code, which is over a year.

## Additional context

This has serious knock-on effects on many other distributions that use `uniform_()` as a basis. In particular, `log(uniform_())` has a 2**-24 chance of producing `-inf`, and `log2(uniform_())` cannot produce a number `< -24` (except `-inf`).

cc @pbelevich
Repository: pytorch
Issue: Better include path when compiling mkldnn
Labels: module: build,triaged

Today I got hit by a similar issue as https://github.com/pytorch/pytorch/issues/14995, due to that I have `conda` `mkldnn` installed. Since we only compile mkldnn from source now, we should be able to do some cmake stuff to make sure it includes the correct headers.

cc @malfet @seemethere @walterddr
Repository: pytorch
Issue: culibos linker errors on binary_linux_conda_3.6_cu90_build
Labels: module: build,triaged

binary_linux_conda_3.6_cu90_build is failing on master

```
/opt/conda/conda-bld/pytorch-nightly_1549230224750/work/build/lib/libcaffe2_gpu.so: undefined reference to `culibosInitializeCriticalSection'
/opt/conda/conda-bld/pytorch-nightly_1549230224750/work/build/lib/libcaffe2_gpu.so: undefined reference to `culibosOnce'
/opt/conda/conda-bld/pytorch-nightly_1549230224750/work/build/lib/libcaffe2_gpu.so: undefined reference to `culibosLoadLibrary'
/opt/conda/conda-bld/pytorch-nightly_1549230224750/work/build/lib/libcaffe2_gpu.so: undefined reference to `culibosInit'
/opt/conda/conda-bld/pytorch-nightly_1549230224750/work/build/lib/libcaffe2_gpu.so: undefined reference to `culibosFreeLibrary'
/opt/conda/conda-bld/pytorch-nightly_1549230224750/work/build/lib/libcaffe2_gpu.so: undefined reference to `culibosEnterCriticalSection'
/opt/conda/conda-bld/pytorch-nightly_1549230224750/work/build/lib/libcaffe2_gpu.so: undefined reference to `culibosLeaveCriticalSection'
/opt/conda/conda-bld/pytorch-nightly_1549230224750/work/build/lib/libcaffe2_gpu.so: undefined reference to `culibosProcessId'
/opt/conda/conda-bld/pytorch-nightly_15492302247\]
```

sample log https://circleci.com/gh/pytorch/pytorch/707045?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link/console

cc @pjh5
Repository: TypeScript
Issue: Object non-literal keys breaks parameter type guard in callback value
Labels: Bug

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.4.0-dev.20190202

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
object dynamic keys callback implicit any
duplicate dynamic object key typing
**Code**


```ts
// PLEASE ENABLE => noImplicitAny 

type Keys = 'a' | 'b' | 'c';
type Shape = { [K in Keys]?: K extends string ? (key: K) => K : never };

const getC = () => 'c' as 'c';

export const obj: Shape = {
  ['a']: key => key, // OK => inferred correctly
  ['b' as 'b']: key => key, // Error => inference broken "any" type
  [getC()]: key => key, // Error => inference broken "any" type
  [getC()]: key => key, // Error => inference broken "any" type instead of Duplicate identifier
  ['a']: key => key, // OK => Duplicate identifier as expected
};
```

**Expected behavior:**
 * No implicit any error, but correct type assignation
 * Detect duplicate identifier in case of non-explicit literal string key

**Actual behavior:**
 * When not using an explicit literal string as an object-key, TypeScript cannot infer correctly the value.
 * In a same way, TypeScript cannot detect duplicate identifier

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->
(http://www.typescriptlang.org/play/#src=%2F%2F%20PLEASE%20ENABLE%20%3D%3E%20noImplicitAny%20%0D%0A%0D%0Atype%20Keys%20%3D%20'a'%20%7C%20'b'%20%7C%20'c'%3B%0D%0Atype%20Shape%20%3D%20%7B%20%5BK%20in%20Keys%5D%3F%3A%20K%20extends%20string%20%3F%20(key%3A%20K)%20%3D%3E%20K%20%3A%20never%20%7D%3B%0D%0A%0D%0Aconst%20getC%20%3D%20()%20%3D%3E%20'c'%20as%20'c'%3B%0D%0A%0D%0Aexport%20const%20obj%3A%20Shape%20%3D%20%7B%0D%0A%20%20%5B'a'%5D%3A%20key%20%3D%3E%20key%2C%20%2F%2F%20OK%20%3D%3E%20inferred%20correctly%0D%0A%20%20%5B'b'%20as%20'b'%5D%3A%20key%20%3D%3E%20key%2C%20%2F%2F%20Error%20%3D%3E%20inference%20broken%20%22any%22%20type%0D%0A%20%20%5BgetC()%5D%3A%20key%20%3D%3E%20key%2C%20%2F%2F%20Error%20%3D%3E%20inference%20broken%20%22any%22%20type%0D%0A%20%20%5BgetC()%5D%3A%20key%20%3D%3E%20key%2C%20%2F%2F%20Error%20%3D%3E%20inference%20broken%20%22any%22%20type%20instead%20of%20Duplicate%20identifier%0D%0A%20%20%5B'a'%5D%3A%20key%20%3D%3E%20key%2C%20%2F%2F%20OK%20%3D%3E%20Duplicate%20identifier%20as%20expected%0D%0A%7D%3B%0D%0A)

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: go
Issue: cmd/compile: add a README section on developing the compiler
Labels: Documentation,NeedsInvestigation,compiler/runtime

For example, such a section could mention:

* https://godoc.org/golang.org/x/tools/cmd/toolstash, to make backups of a working/previous Go compiler
* General recommendations like `toolstash restore && go install cmd/compile` to rebuild the compiler in a fast and stable way
* Tips to ensure that the compiler hasn't been obviously broken, such as `go build -toolexec "toolstash -cmp" -a -v std cmd`
* Tips on how to use https://godoc.org/golang.org/x/tools/cmd/compilebench along with `toolstash` and `benchstat` to measure performance optimizations

Anything else that comes to mind, please add it to this issue. I plan on sending a CL to add a markdown section sometime during the 1.13 cycle.

I realise the SSA package has lots of extra checks and debugging flags one can enable, but I think those should be covered by `cmd/compile/internal/ssa/README`. I am also not nearly as familiar with those as I'm with this list here, so I'm leaving ssa's tips for another issue/CL.

/cc @josharian @mdempsky @aclements @randall77
Repository: TypeScript
Issue: tsc counts errors twice
Labels: Bug

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.2.4

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** error double, error twice
![unbenannt](https://user-images.githubusercontent.com/17641229/52211486-4e8d6d00-288a-11e9-9c29-925dc8738e34.PNG)

**Expected behavior:**
tsc reports 4 errors.

**Actual behavior:**
it reports 8 errors.
Repository: rust
Issue: [rustdoc] Tracking issue for `--show-coverage`
Labels: T-rustdoc,B-unstable,C-tracking-issue,A-doc-coverage

cc @QuietMisdreavus