sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: libtorch.so file size is very large
Labels: high priority,module: binaries,module: cpp,triaged,oncall: mobile,quansight-nack

## 🐛 Bug

The library size of torch is very large (~267MB without CUDA, 1.2 GB with CUDA).
This can be caused by using a library like Intel IPP similar to this opencv bug.
https://github.com/opencv/opencv/issues/15177
This limits the use of pytorch models in small environments (without CUDA).

## To Reproduce

Steps to reproduce the behavior:
1. Download the libtorch C++ library

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior

Library size without CUDA should be a lot less than that. or at least providing libtorch_tiny or ways to create it.

<!-- A clear and concise description of what you expected to happen. -->

## Environment
 - PyTorch Version: 1.4
 - OS: Linux


cc @ezyang @gchanan @zou3519 @bdhirsh @heitorschueroff @seemethere @malfet @walterddr @yf225 @glaringlee
Repository: godot
Issue: C# Creating arrayMesh with indices gives ERR_INVALID_PARAMETER error
Labels: discussion,topic:dotnet

**Godot version:**
3.1.1-stable-mono_win64
**OS/device including version:**
Windows 7 SP1
**Issue description:**
When trying to create an arrayMesh in C# with indices i get 

> E 0:00:02:0247 Condition ' p_arrays[ai].get_type() != Variant::POOL_INT_ARRAY ' is true. returned: ERR_INVALID_PARAMETER servers/visual_server.cpp:709 @ _surface_set_data() :0 @ void Godot.NativeCalls.godot_icall_4_141(IntPtr , IntPtr , Int32 , IntPtr , IntPtr , Int32 )() ArrayMesh.cs:245 @ void Godot.ArrayMesh.AddSurfaceFromArrays(Godot.Mesh+PrimitiveType , Godot.Collections.Array , Godot.Collections.Array , Int32 )() HexMesh.cs:37 @ void HexMesh._Ready()()

and 

> E 0:00:02:0251 Invalid array format for surface servers/visual_server.cpp:1154 @ mesh_add_surface_from_arrays() :0 @ void Godot.NativeCalls.godot_icall_4_141(IntPtr , IntPtr , Int32 , IntPtr , IntPtr , Int32 )() ArrayMesh.cs:245 @ void Godot.ArrayMesh.AddSurfaceFromArrays(Godot.Mesh+PrimitiveType , Godot.Collections.Array , Godot.Collections.Array , Int32 )() HexMesh.cs:37 @ void HexMesh._Ready()()

Even though the array in question has type int.
**Steps to reproduce:**
```cs
Vector2 center = new Vector2(30,30);
Vector2 dir = new Vector2(10, 0);
Array<Vector2> vectors = new Array<Vector2>();
Array<int> indices = new Array<int>();


for(int i = 0; i < 3; i++){
    vectors.Add(center + dir.Rotated(Mathf.Deg2Rad(60 * i)));
}

indices.Add(0);
indices.Add(1);
indices.Add(2);


hexMesh = new ArrayMesh();

Godot.Collections.Array arrays = new Godot.Collections.Array();
arrays.Resize((int)ArrayMesh.ArrayType.Max);
arrays[(int)ArrayMesh.ArrayType.Vertex] = vectors;
arrays[(int)ArrayMesh.ArrayType.Index] = indices;

hexMesh.AddSurfaceFromArrays(Mesh.PrimitiveType.Triangles, arrays);

this.Mesh = hexMesh;
```
This is inside ready() method of script and script is attached to MeshIntance2D node.

**Minimal reproduction project:**
[HexMap.zip](https://github.com/godotengine/godot/files/4274931/HexMap.zip)
Repository: TypeScript
Issue: Declaration emit should not inline type definitions
Labels: Needs Investigation

**TypeScript Version:**  3.8.3, 3.8.1, probably others

**Search Terms:**

declaration inlining, dts inlining, declaration inline, inline literal, declaration literal

**Code**

```ts
// parent.ts
import { num, obj } from "./child"
export const reExportNum = num;
export const reExportObj = obj;
```

```ts
// child.d.ts
export declare const num: number;
export declare const obj: { a: 1 };
```

`tsc index.ts --declaration`

**Expected behavior:**

Declaration emit for `parent.ts` should not inline types.

```ts
// parent.d.ts
import { num, obj } from "./child"
export declare const reExportNum: typeof num;
export declare const reExportObj: typeof obj;
```

**Actual behavior:**

Today, declaration emit for `parent.ts` inlines the types **and** eliminates the import of the `child.d.ts` type definition.

```ts
// parent.d.ts
export declare const reExportNum: number;
export declare const reExportObj: {
    a: 1;
};
```

This is a correctness issue, because consumers of `parent.d.ts` will not get the correct types if the types in `child.d.ts` change.

In practice, this is most likely to happen when `parent` and `child` are in separate packages, because they are published independently, i.e. an application uses `parent-package` which uses types from `child-package`.  This is exacerbated by the current practice on npm of `parent-package` depending on an unpinned version, using `package.json` dependency syntax `"child-package": "*"`.


> This issue was co-authored with @robpalme
Repository: vue
Issue: Swapping from functional to non-functional component using v-if does not change v-data-* attribute.
Labels: bug

### Version
2.6.11

### Reproduction link
[https://codesandbox.io/embed/heuristic-brown-u7rvw?fontsize=14&hidenavigation=1&theme=dark](https://codesandbox.io/embed/heuristic-brown-u7rvw?fontsize=14&hidenavigation=1&theme=dark)







### Steps to reproduce
Click the tick box.

### What is expected?
It should say "BLUE BOX" with a blue background colour.

### What is actually happening?
It says "BLUE BOX" with no background colour.

---
The issue stems from the data-v-* attribute not being re-set for the blue_block div when it is swapped to. It is still using the data-v-* attribute of the child div in the functional component. Thus the CSS class styling does not apply. 


https://imgur.com/a/gukDePJ


Swapping from a functional component to something else is useful. E.g. When showing a simple loading bar component before swapping to a more complex component.

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: godot
Issue: [Bullet] 3D: long (+300 m) collision shapes for static bodies resulting in strange behaviour
Labels: bug,confirmed,topic:physics,topic:3d

**Godot version:**
3.2 stable official

**OS/device including version:**
Windows 10 Home

**Issue description:**
In 3D, when making large or long collision shapes for static bodies, strange behaviour occurs, if a rigid body rolls or pass on it.
Setting the collision shape for a static body, and setting the collision shape extent (using the 3D gizmo or setting the EXTENT property in the editor) to 150 or more (resulting in a collision shape with 300 m length), rotating it to make an inclined plane, and placing a rigid body with a collision shape like a sphere on it, and letting it roll, results in the sphere bouncing or stopping abruptly at some point. 
Sometimes the sphere just doesn't move anymore, sometimes it rotates in other directions, like it was deflecting something.
Another aspect, is that if the static body is placed in another place, the rigid body movement changes.

![Capturar](https://user-images.githubusercontent.com/22160489/75684185-08663100-5c77-11ea-9be0-90d274963cdb.JPG)

The example I've attached uses a sphere, but I've noticed it with a car I'm making, using cylinders (rigid bodies) as wheels. The car stopped or deflected, like the sphere in this example does. So it is not restricted to one collision shape.

EDIT: It looks like the problem is the ratio between at least two of the axis. If extent in X is set to 150 and, Y and Z are 1, the strange behaviour occurs. If the extent in Z is set to 10, no problem occurs.

Also, it looks like the ratio is not fixed, it depends on size. Changing to 300 in one axis, and 10 in another, still resulted in problems. Changing to 300 and 30, evertything was fine.


**Steps to reproduce:**

1. Add a static body
2. Add a collision shape to it, and set shape to BOX
3. Set extents to 150, in X for example
4. Rotate it, to make it an inclined plane, so that you can drop a rigid body, like a sphere on it
5. Add a rigid body, add a collision shape to it, set shape to SPHERE
6. Place the sphere rigid body on the static body
7. Run the game
8. Change the location of the static body, to see different rigid body behaviours
9. Change extent in Z axis to 10, to see no problem occurring

**Minimal reproduction project:**
[StaticBodyBug.zip](https://github.com/godotengine/godot/files/4275728/StaticBodyBug.zip)
I have also attached 2 videos showing the behaviour
[StaticBodyBug_video.zip](https://github.com/godotengine/godot/files/4275729/StaticBodyBug_video.zip)

https://user-images.githubusercontent.com/22160489/103038813-27a7b500-454e-11eb-9230-ee9c6502d404.mp4

https://user-images.githubusercontent.com/22160489/103038815-28d8e200-454e-11eb-838c-55a58c91665b.mp4
Repository: pytorch
Issue: [docs] Unclear description of indices arg in torch.index_put_
Labels: module: docs,triaged

https://pytorch.org/docs/master/tensors.html#torch.Tensor.index_put_

`
Puts values from the tensor value into the tensor self using the indices specified in indices (which is a tuple of Tensors). The expression tensor.index_put_(indices, value) is equivalent to tensor[indices] = value
`

However if we follow the suggested link [indices](https://pytorch.org/docs/master/tensors.html#torch.Tensor.indices), it only explains something about sparse tensors: `If self is a sparse COO tensor (i.e., with torch.sparse_coo layout), this returns a view of the contained indices tensor. Otherwise, this throws an error.`

So this (the suggested indices link + phrasing "using the indices specified in indices" and the requirement to use a tuple of tensors) is a confusing reference when `index_put_` is to be used with dense tensors.

If the function is not normally expected to be used with dense tensors, a notice about that would be a great clarification.
```python
a = torch.rand(3)
a.index_put_((torch.tensor(-1), ), torch.tensor(0.0)) # notice a lot of wrapper torch.tensor calls and the required tuple
```

In the doc it mentions that the op is equivalent to `tensor[indices] = value`, so naturally I first tried the call `a.index_put_(-1, 0)` for zeroing out the last tensor element and it failed badly.
Repository: go
Issue: cmd/compile: spurious "cannot use reflect.Kind(9) … as type uint64 in assignment" on darwin-amd64-race builder
Labels: NeedsInvestigation,compiler/runtime

[2020-03-01T21:02:40-e44cda3/darwin-amd64-race](https://build.golang.org/log/60b8a176634d0f45bf048c11aab56185d0a8d3a0)

```
# encoding/xml [encoding/xml.test]
/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/encoding/xml/marshal.go:849:62: cannot use reflect.Kind(9) (type reflect.Kind) as type uint64 in assignment
FAIL	encoding/xml [build failed]
```

CC @randall77 @josharian
Repository: pytorch
Issue: pip --requirement installs incorrect CUDA version
Labels: module: dependency bug,module: binaries,oncall: releng,triaged

## Issue description

When installing PyTorch using pip with requirements file provided it installs PyTorch for CUDA 9.2 while when installed from command line it would install for CUDA 10.1.
[requirements.txt](https://github.com/pytorch/pytorch/files/4275930/requirements.txt)

INline:

```
torch==1.4.0
torchvision==0.5.0

```


## Code example
```
# Install PyTorch using attached requirements file.
python -m venv requirements
cd requirements
Scripts\activate
python -m pip install --upgrade pip
pip install -r requirements.txt -f https://download.pytorch.org/whl/torch_stable.html
pip freeze
...
torch==1.4.0+cu92
torchvision==0.5.0+cu92
```
On the other side if PyTorch is installed from command line.
```
# Install PyTorch from the command line.
python -m venv command_line
cd command_line
Scripts\activate
python -m pip install --upgrade pip
pip install torch===1.4.0 torchvision===0.5.0 -f https://download.pytorch.org/whl/torch_stable.html
pip freeze
...
torch==1.4.0
torchvision==0.5.0
```
## System Info
```
# For PyTorch installed from requirements file.
python collect_env.py
```

PyTorch version: 1.4.0+cu92
Is debug build: No
CUDA used to build PyTorch: 9.2

OS: Microsoft Windows 10 Enterprise
GCC version: Could not collect
CMake version: Could not collect

Python version: 3.6
Is CUDA available: Yes
CUDA runtime version: 10.1.243
GPU models and configuration: GPU 0: GeForce RTX 2070
Nvidia driver version: 441.87
cuDNN version: C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.1\bin\cudnn64_7.dll

Versions of relevant libraries:
[pip3] numpy==1.18.1
[pip3] torch==1.4.0+cu92
[pip3] torchvision==0.5.0+cu92
[conda] Could not collect


cc @ezyang
Repository: bitcoin
Issue: Make fee estimation mockable via RPC
Labels: Feature

Right now the only(?) test we have that exercises interesting fee estimation codepaths is `feature_estimate_fee.py`. For fee-bumping and other tests it would make sense to allow test authors to quickly construct fluctuating fee scenarios at will.

related: https://github.com/bitcoin/bitcoin/issues/18240
Repository: go
Issue: x/build/maintner/maintnerd, x/build/maintner: changes are hard to review and test
Labels: Builders,NeedsInvestigation

This issue is to note that it is currently difficult and time-intensive to review changes to the maintner server. Changes to the server are risky and can cause crashes, or worse, incorrect data to be written. Many services depend on the maintner server being stable and correct.

It has some tests, but they're not enough to provide sufficient confidence. Manual testing is not easy. There isn't a staging instance that's actively used.

This issue is to track progress on making it easier and safer to make changes to maintner. It has known bugs that need to be resolved, and Gerrit and GitHub APIs may change, so not making any changes will not be viable indefinitely.

/cc @cagedmantis @toothrot
Repository: deno
Issue: Make `Deno.readDir` actually streaming
Labels: feat,cli

probably with async iterator
Repository: TypeScript
Issue: types 'new (...args: any) => E' and wrapper types constructor for primitive types have no overlap
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 the latest published version. It may have already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly
-->
**TypeScript Version:**  3.8.3

**Code**

```ts
class TreeSet<E> {
    constructor(elementType: new(...args: any) => E) {
        if (elementType === Number) { //This condition will always return 'false' since the types 'new (...args: any) => E' and 'NumberConstructor' have no overlap.(2367)
            console.log("hello")
        }
    }
}

new TreeSet(Number)
```

**Actual behavior:**
The error is prompted at compile time "This condition will always return 'false' since the types 'new (...args: any) => E' and 'NumberConstructor' have no overlap.(2367)" but compiled code actually runs correctly.

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->
https://www.typescriptlang.org/play/?ssl=9&ssc=20&pln=1&pc=1#code/MYGwhgzhAEAqBOBTRBlRAXAPAUQHzQG8AoaU6YAewDsJ14BXYdC+ACkREQFtEr1YAngAdEALmhVEAd1YA6eWHgBzCOLBUBASmgBefNm3Eyx6AEsAZtHacefQSN06d0AHL0uAI0TxDJE-8oaCk5ZEAolVgAiAAsOMMjNP38AXyToVNSiSSk4JFQMVjdPb00gA
Repository: material-ui
Issue: [CSP] Issue with inline-style and Content Security Policy
Labels: discussion,core

According to the documentation, to support the CSP header, a nonce needs to be added to the style-src directive (https://mui.com/material-ui/guides/content-security-policy/). However, a number of Material-UI components make use of inline style attributes (e.g. Tabs - https://github.com/mui/material-ui/blob/5c96f3cad765c259d029321a8f7d2f57c9bcc36b/packages/mui-material/src/Tabs/Tabs.js#L768-L773). These require the 'unsafe-inline' source (or a hash for each style although this isn't practical). The 'unsafe-inline' source is ignored if a hash or nonce source is set, thus necessitating the removal of the nonce.

So generally for Material-UI as I see it, I think one of two things are needed:
1.  Update the CSP documentation for a setup to allow inline style attribute setting (not a great CSP, but would make Material-UIs stance clear on styling then).
2. Set a standard of no inline style attribute setting and we fix them all as bugs.

What do you think? I did an issue search and found this (https://github.com/mui-org/material-ui/issues/13364) suggesting that Material-UI as a whole allows inline style attributes and thus are happy with necessitating a non strict CSP setting. Is this still the case and we're happy with what this means for CSP?

Related:

- https://github.com/radix-ui/primitives/issues/2057
Repository: pytorch
Issue: [C++ API Parity] Incorrect documentation for optim initialization in serialization docs
Labels: module: docs,module: cpp,module: optimizer,triaged

https://pytorch.org/cppdocs/api/function_namespacetorch_1a99dc9f736064b2179cc58e6436f7a021.html#exhale-function-namespacetorch-1a99dc9f736064b2179cc58e6436f7a021

https://pytorch.org/cppdocs/api/function_namespacetorch_1a4b369494adfb10b9a005aeb0bb6207cb.html#exhale-function-namespacetorch-1a4b369494adfb10b9a005aeb0bb6207cb

see issue: https://github.com/pytorch/pytorch/issues/33862#issuecomment-593518890

cc @yf225 @vincentqb
Repository: flutter
Issue: Add flutter upgrade --hotfix
Labels: c: new feature,tool,P3,team-tool,triaged-tool

Users may want to upgrade to the most recent hotfix, but wait on upgrading to the most recent stable.
Repository: go
Issue: cmd/compile: branch elimination opportunites when comparing constants
Labels: Performance,NeedsInvestigation,compiler/runtime

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
latest

</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
linux/ppc64le but I see it in the SSA on x86
</pre></details>

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->
Inspecting code for other reasons, found cases where there are constant compares and subsequent branches against those constants, resulting in several unnecessary branches.

### What did you expect to see?
No unnecessary branches.

### What did you see instead?
Unnecessary branching due to constant compares of known values.

This example comes from the ssa output of bytes.(Buffer).WriteByte. Here are some snippets:

v18 00011 (+107) MOVD 8(R6), R7
v38 00012 (107) MOVD 16(R6), R5
v26 00013 (107) SUB R7, R5, R8
v70 00014 (107) CMP R8, $1
// This could be BLT 36. Block starting at 46 sets R3 to 0 then branches to a CMP R3, $0. 
b1 00015 (107) BLT 46  <--- Change to BLT 36

v54 00019 (108) MOVD R4, 8(R6)
// Once the block at 46 is eliminated as a predecessor of this block, then the next 3 instructions are not needed, since the CMPW has only a single predecessor and it is comparing 0 against 1 and the BEQ will never happen.
v45 00020 (108) MOVD $1, R3 <---- Remove
v52 00021 (+265) CMPW R3, $0 <---- Remove
b9 00022 (+266) BEQ 36 <---- Remove

v24 00023 (+269) PCDATA $1, $1
v24 00024 (+269) MOVD 8(R6), R4
v34 00025 (+269) PCDATA $0, $2
v34 00026 (269) MOVD (R6), R5
v88 00027 (269) CMPU R4, R7

v63 00036 (267) PCDATA $1, $0
v63 00037 (+267) MOVD R6, 32(R1)
v81 00038 (267) MOVD $1, R3
v65 00039 (267) MOVD R3, 40(R1)
v66 00040 (+267) CALL "".(*Buffer).grow(SB)
v68 00041 (267) MOVD 48(R1), R7
v36 00042 (269) PCDATA $0, $1
v36 00043 (269) PCDATA $1, $1
v36 00044 (269) MOVD "".b(R1), R6
b11 00045 (267) JMP 23

// The MOVD $0, R3 and JMP 21 could be replaced by JMP 36 since the successor is CMP $0, R3 followed by BEQ 36. Once it is decided that 36 is the successor, I think the MOVD $0, R7 could also go away since the block starting at 36 doesn't use it. That also means the predecessor of this block could branch directly to 36.
v21 00046 (267) PCDATA $1, $0 <--- Remove
v21 00047 (267) MOVD $0, R7 <--- Remove
v25 00048 (267) MOVD $0, R3 <--- Remove
b2 00049 (+265) JMP 21 <---- Remove

This scenario is common in stdlib functions. It looks like the same situation occurs in x86, so it is not specific to ppc64/ppc64le.

@josharian I think I reported this problem last fall and you commented on it, but I can't find the issue where that was done.
Repository: pytorch
Issue: RPC API Changes for TensorPipes
Labels: triaged,module: rpc

## 🚀 Feature
In order for RPC Agent to support the full functionality of TensorPipes' fast point-point communication, the following API-level changes will need to be made:

* Results Placement: Process A can send a message to Process B with instructions to send the result of the computation to Process C. We must also support the case where the result is a nested structure (list, dict, etc.), and so the results should be sent to multiple processes.

* Args Placement: Process A can send a message to Process B, indicating that the arguments must be placed on different machines prior to performing the computation. Much like the case above with nested results, we must support nested arguments.

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @rohan-varma @xush6528 @jjlilley @osalpekar
Repository: pytorch
Issue: Autograd deep copy avoidance optimization unsound in the presence of views
Labels: module: autograd,triaged

Right now, we have the following optimization in accumulate grad:

```
    // under following condition, we can avoid clone()
    if (!GradMode::is_enabled()
        && !new_grad.is_sparse()
        && new_grad.is_contiguous()
        && new_grad.use_count() <= 1 + !post_hooks().empty()) {
      // first check it is in first-order grad only mode
      // then check not sparse before is_contiguous
      // then check contiguous, otherwise later in place accumulation may fail
      // and lastly, check it is the last reference before we grab it.
      // If the function has post hooks (for example, a DDP allreduce hook),
      // call_function in Engine.cpp will temporarily bump the refcount by one, hence the
      // addition of !post_hooks().empty().
      variable.grad() = new_grad.detach();
```

We test the use count on the Tensor object to see if we can steal it into the input buffer (to be accumulated into when we make subsequent modifications). However, this is unsound if `new_grad` is a view on another tensor, because then we will save a view into `variable.grad()` and the aliasing is now observable.

There is also a minor correctness problem, where not all post hooks are safe to apply; if the post hook saves the gradient directly (without copying it) it can also observe subsequent mutations.

cc @ezyang @SsnL @albanD @zou3519 @gqchen @mcarilli
Repository: pytorch
Issue: Enable profiler tracing tests on windows
Labels: feature,triaged

## 🚀 Feature
As mentioned in https://github.com/pytorch/pytorch/pull/33987/files, the tests for `export_chrome_trace` in `test/test_autograd.py` are currently disabled on Windows due to a file permission issue.

A correct fix here would be to pass the file object directly to `export_chrome_trace`, however, this would require modifying its API. 

When this is done we should re-enable the two tests that are currently skipped for windows:
`test_profiler_aggregation_lstm` and `test_profiler_tracing`