sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Don't evaluate promoteds for each monomorphization if it does not depend on generic parameters
Labels: C-enhancement,I-compiletime,T-compiler,A-const-eval

In the following code snippet

```rust
fn foo<T>() -> &'static i32 {
    &(5 + 6)
}
```

we evaluate the `&(5 + 6)` for every monomorphization of `foo`, even though we could just do this once. We should find a way to get rid of this duplicate evaluation. Maybe we can already do this at the time promoteds are created (const qualif + `promote.rs`) by checking `promoted_mir.needs_substs()` and if it's false, make the `ty::Const` that refers to it not have any substs itself. `const_eval` will then automatically memoize all the evaluations of this promoted.

Alternatively const prop could attempt to evaluate the promoted and if it fails, assume it has generics and leave it to monomorphization. This would require more CPU time than the const qualif version, since we'd do a lot of prospetive evaluations that may not succeed.
Repository: kubernetes
Issue: Test coverage of volume relabeling is lacking
Labels: kind/bug,area/test,priority/backlog,sig/storage,sig/node,help wanted,lifecycle/frozen,needs-triage

**What happened**:
SELinux volume relabeling regressed in 1.16/1.17 with no test failures. See https://github.com/kubernetes/kubernetes/issues/83679

**What you expected to happen**:
Test failures would have prevented the regression. Currently, we apparently only have manual test guarantees that this functions correctly.

/sig node storage
/priority critical-urgent
Repository: pytorch
Issue: Categorical.sample too slow
Labels: module: distributions,triaged

## 🐛 Bug

Categorical.sample(shape) calls _shape_ times ```torch.multinomial(probas, 1, True)```.
This is slow when we want to get many samples from a large number of classes.

## To Reproduce

Steps to reproduce the behavior:

```py
import torch
sampling = torch.distributions.categorical.Categorical(probs=torch.rand((10_000_000)))
%timeit sampling.sample((100,))
```
Outputs : ```3.16 s ± 117 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)```

## Expected behavior
Shouldn't be slower than a single call to torch.multinomial
```py
probas = torch.rand(10_000_000)
%timeit torch.multinomial(probas, 100, True)
```
which outputs : ```51.7 ms ± 1.31 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)```

## Environment
PyTorch version: 1.3.1
Is debug build: No
CUDA used to build PyTorch: 10.0.130

OS: Ubuntu 18.04.1 LTS
GCC version: (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
CMake version: version 3.10.2

Python version: 3.7
Is CUDA available: Yes
CUDA runtime version: 10.0.130
GPU models and configuration:
GPU 0: Quadro GP100
GPU 1: Quadro GP100

Nvidia driver version: 410.79
cuDNN version: Could not collect

Versions of relevant libraries:
[pip] numpy==1.16.4
[pip] numpysane==0.17
[pip] torch==1.3.1
[conda] blas                      1.0                         mkl
[conda] faiss-gpu                 1.6.0            py37h1a5d453_0    pytorch
[conda] mkl                       2019.4                intel_243    intel
[conda] mkl_fft                   1.0.12           py37ha843d7b_0
[conda] mkl_random                1.0.2            py37hd81dba3_0
[conda] pytorch                   1.3.1           py3.7_cuda10.0.130_cudnn7.6.3_0    pytorch

cc @vincentqb @fritzo @neerajprad @alicanb @vishwakftw
Repository: go
Issue: doc: filename conventions
Labels: Documentation,NeedsDecision

> If I have simply missed where this is documented, please let me know where I should have looked, and close this out.

Many places describe how custom filename suffixes interact with the toolchain: `_test`, `_linux`, `_arm`. However I cannot find anywhere that says you should use snake case for multi-word file names, as is suggested by the standard library: e.g. `time/zoneinfo_read.go`/`os/removeall_at.go` not `time/zoneinfoRead.go`/`os/removeallAt.go` or `time/zoneinfo-read.go`/`os/removeall-at.go`.

This may seem self evident to experienced users, but I have seen many people get confused by the fact that variables use `CamelCase := ""`, while files use `snake_case.go`.
Repository: pytorch
Issue: Remove `.data`
Labels: module: autograd,triaged,enhancement,better-engineering,actionable

Even though it is not documented, many users still use it. And it leads to many bugs in user code.
So we should remove it completely to prevent this.
The expected steps are:
- [ ] Add a new api to make a shallow copy that does not share version? Or a cat + unbind function that does not share version counter if that is enough.
- [ ] Remove the use of .data in all our internal code
  - [ ] `benchmarks/`
  - [ ] `docs/source/scripts/build_activation_images.py` and `docs/source/notes/extending.rst`
  - [ ] `test/`
  - [ ] `torch/autograd/` Blocky by https://github.com/pytorch/pytorch/pull/30258#issuecomment-558344600 (not blocked ones were done in #31479)
  - [ ] `torch/cuda/` Use that requires the new api mentioned above.
  - [x] `torch/jit` #31480 
  - [ ] `torch/nn` Simple ones done in #31481 and #31482
  - [ ] `torch/optim`
  - [ ] `torch/utils/tensorboard/`
  - [ ] `torch/tensor.py`
  - [x] *ignored* `caffe2/`
- [ ] Add warning to every call to `.data`
- [ ] Actually remove `.data` ?


cc @ezyang @SsnL @albanD @zou3519 @gqchen
Repository: rust
Issue: Missing TryInto from usize to float
Labels: T-libs-api,C-feature-request

Currently there is no trait bound that will satisfy this very simple algorithm:

```
fn average<T>(list: &Vec<T>) -> T 
    where T: Div<Output=T> + Add<Output=T> + Default + TryFrom<usize>
{
    let mut total = Default::default();
    if list.len() == 0 {
        total
    }
    else {
        for val in list.iter() {
            total = total + *val;
        }
        total / TryFrom::try_from(list.len()).unwrap()
    }
} 
```



<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":null}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: flutter
Issue: libEGL.so & libGLESv2.so missing in Linux exe.unstripped directory
Labels: team,engine,platform-linux,P2,team-engine,triaged-engine

On Linux , we should copy `libEGL.so` and `libGLESv2.so` from `out/xxx/` to `out/xxx/exe.unstripped` in order to properly debug the binaries inside `exe.unstripped` directrory (e.g., using gdb). Otherwise, Linux will load the system library instead of our SwiftShader GL implementation.
Repository: rust
Issue: rustc requires 7GB of memory for clean build
Labels: C-enhancement,A-borrow-checker,T-compiler,I-compilemem

(This is a followup to https://users.rust-lang.org/t/why-does-rustc-require-7gb-of-memory-for-a-medium-size-crate/35506.)

I have a rust project (https://github.com/samuela/rustybox as of 37c0a1d) that requires ~7GB of memory to build. Why does rustc require so much memory? Are there any particular rust features that lead to this kind of outsized memory usage? Using so much memory seems buggy/unusual to me, and it was suggested on the forum that I open a bug report.

```
$ cargo clean
$ /usr/bin/time -v cargo build --jobs 1
...
Finished dev [unoptimized + debuginfo] target(s) in 3m 17s
	Command being timed: "cargo build --jobs 1"
	User time (seconds): 156.60
	System time (seconds): 17.12
	Percent of CPU this job got: 87%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 3:17.98
	Average shared text size (kbytes): 0
	Average unshared data size (kbytes): 0
	Average stack size (kbytes): 0
	Average total size (kbytes): 0
	Maximum resident set size (kbytes): 7053216
	Average resident set size (kbytes): 0
	Major (requiring I/O) page faults: 27
	Minor (reclaiming a frame) page faults: 768571
	Voluntary context switches: 38426
	Involuntary context switches: 304785
	Swaps: 0
	File system inputs: 334648
	File system outputs: 632816
	Socket messages sent: 0
	Socket messages received: 0
	Signals delivered: 0
	Page size (bytes): 4096
	Exit status: 0
```
Repository: pytorch
Issue: The inference speed of the torch compiled manually is slower than the torch build from official binaries?
Labels: needs reproduction,module: binaries,module: performance,triaged

I compile the torch(v1.4.0 cudatoolkit=10.2 cudnn=7.6.5) from source with the command "python setup install". And then load the model of shufflenet v2 0.5 with the compiled library(batchsize=8), the speed is 0.0083. But when I load the same model with the torch(v1.3.1 cudatoolkit=10.0 cudnn=7.6.4) build by official binaries through conda, the speed is 0.0075. Why is this fast?
My GPU is 2080TI. 
Relevant config:
```
No OpenMP library needs to be linked against
-- Found CUDA: /usr/local/cuda-10.2 (found version "10.2") 
-- Caffe2: CUDA detected: 10.2
-- Caffe2: CUDA nvcc is: /usr/local/cuda-10.2/bin/nvcc
-- Caffe2: CUDA toolkit directory: /usr/local/cuda-10.2
-- Caffe2: Header version is: 10.2
-- Found cuDNN: v7.6.5  (include: /usr/local/cuda-10.2/include, library: /usr/local/cuda-10.2/lib64/libcudnn.so)
-- Autodetected CUDA architecture(s):  7.5 7.5 7.5
-- Added CUDA NVCC flags for: -gencode;arch=compute_75,code=sm_75
-- Autodetected CUDA architecture(s):  7.5 7.5 7.5
-- Could NOT find CUB (missing: CUB_INCLUDE_DIR) 
-- Found CUDA: /usr/local/cuda-10.2 (found suitable version "10.2", minimum required is "7.0") 
-- CUDA detected: 10.2
-- Could NOT find NCCL (missing: NCCL_INCLUDE_DIR NCCL_LIBRARY) 
```
[cmakelog.log](https://github.com/pytorch/pytorch/files/3942238/cmakelog.log)


cc @ezyang @VitalyFedyunin @ngimel @mruberry
Repository: godot
Issue: [empty] instead of default value in properties inspector for exported Resource
Labels: discussion,topic:editor

**Godot version:** 3.0

**OS/device including version:** Any

**Issue description:** Value is "[empy]" for exported resource with default value

**Steps to reproduce:**
Create some custom resource class. For example MyResource
Use it in exported variables. Example:
```
export var int_value : int = 12
export var my_resource_value : Resource = MyResource.new()
```
Check inspector:
Actual result:
int_value = 12
my_resource_value = [empty]
Expected result:
int_value = 12
my_resource_value = MyResource with exported values of this resource

**Minimal reproduction project:**
[ExportResource.zip](https://github.com/godotengine/godot/files/3942038/ExportResource.zip)
Repository: go
Issue: proposal: crypto/subtle: constant time comparison (eq/neq) for int64
Labels: Proposal,Proposal-Crypto

Several well-used programs in Golang use int64 as an identifier, but do not use constant time comparison when authenticating. This could be used to leak information to an adversary (potentially). Unfortunately, `crypto/subtle` does not have a constant-time comparison algorithm for int64, which would clearly be useful to have.

I do not have a clear understanding of how things work "under the hood" in Golang, so I do not trust myself to write a proper constant time int64 comparison algorithm for `crypto/subtle`. However, I think one could be easily implemented/adapted.

@FiloSottile @rsc @agl It looks like you guys know what you're doing on `crypto/subtle`. Could you help out here?
Repository: opencv
Issue: python: Relink `/usr/lib/x86_64-linux-gnu/libsystemd.so.0' with `/usr/lib/x86_64-linux-gnu/librt.so.1' for IFUNC symbol `clock_gettime'
Labels: incomplete


##### System information (version)
- OpenCV => 4.1.2 (Build from source)
- Operating System / Platform => Ubuntu 19.04
- Compiler => 
```console
longervision-GT72-6QE% gcc --version
gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```

I failed to **import cv2** using **python**.

```
longervision-GT72-6QE% python
Python 3.7.3 (default, Oct  7 2019, 12:56:13) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cv2
python: Relink `/usr/lib/x86_64-linux-gnu/libsystemd.so.0' with `/usr/lib/x86_64-linux-gnu/librt.so.1' for IFUNC symbol `clock_gettime'
python: Relink `/usr/lib/x86_64-linux-gnu/libudev.so.1' with `/usr/lib/x86_64-linux-gnu/librt.so.1' for IFUNC symbol `clock_gettime'
[1]    25419 segmentation fault (core dumped)  python
```


Any suggestions?

Cheers
Pei
Repository: TypeScript
Issue: Add full type hover popup to VS Code commands
Labels: Suggestion,Needs Proposal

Several issues have been opened for this problem, but they have been closed as a duplicate of an issue which barely mentions the problem, let alone addresses it: https://github.com/microsoft/vscode/issues/64566

The closed issues are:

- https://github.com/microsoft/vscode/issues/66405
- https://github.com/microsoft/vscode/issues/76480
- https://github.com/microsoft/vscode/issues/66405

The problem is simple. The three dots means you can't copy and paste definitions like you used to be able to. This is an absolutely essential feature because TypeScript isn't even close to being used everywhere, and the intellisense of Javascript files inside TypeScript files is way worse than inside Javascript files. This basically means the easiest way to create a d.ts file is to copy the type definition in the hover inside Javascript and then paste it into a d.ts file so TypeScript files can use it. It also helps me debug overloads and unions when things are going awry. 

Even just a command that would popup the hover with the full definition instead of the abbreviated definition would be incredibly useful. Currently the shortcut is `Ctrl+k, Ctrl+i` for the abbreviated definition, so I take it there is a command behind it that can be typed into the command list (`ctrl+shift+p`). So even just adding the command for people to manually add a shortcut for would be really useful. 

I can work around it, but I spend hours more time per week because of it.
Repository: pytorch
Issue: Pytorch 1.3.0 on RTX cards: CUDA error: an illegal memory access was encountered
Labels: module: cuda,module: memory usage,triaged

Hi, after upgrade from torch==1.2.0 to torch==1.3.0 (or 1.3.1) I'm seeing these errors in my application running on RTX cards:

**CUDA error: an illegal memory access was encountered**

Error happens randomly in different parts of code, when accessing cuda functions.
For example: image_tensor = self.tensors[image_size].cuda(non_blocking=True)
System runs fine for a while, and then starts producing errors like this one.

## To Reproduce

It's a production system with a large code base so it's hard for me to provide you with a reproduction sample.

## Environment

I have noticed this error only with pytorch==1.3.0 or pytorch.1.3.1 running on RTX 1660Ti and RTX 2080. I have instances of same application running on older hardware (GTX 1070, GTX 1080) with out any problems. Also, using older version of pytorch (1.2.0) on RTX cards no problem as well.


 - PyTorch Version: 1.3.0, 1.3.1
 - OS: CentOS docker environment
 - How you installed PyTorch: pip
 - Python version: 3.6
 - CUDA/cuDNN version: 10.1, 10.2
 - GPU models and configuration: RTX 1660Ti, RTX 2080


cc @ngimel
Repository: PowerToys
Issue: Transform (lowercase, Titlecase, UPPERCASE) Feature
Labels: Idea-New PowerToy

# Summary of the new feature/enhancement

As there is a PowerRenamer feature, there should be a PowerTransform feature as well. PowerTransform should help quickly rename *any text* throughout the W10 ecosystem, and especially files, from **`lowercase`** to **`Titlecase`** or **`UPPERCASE`**.

It should be available as a Right click context menu. This is an absolutely missing feature in any Windows OS, and the third party solutions are not great. 

Please leave a like if you would want to have this feature implemented.
Repository: opencv
Issue: Robust variant of solvePnPRefineLM
Labels: feature,category: calib3d

Currently the LM part of the solvePnPRefineLM function minimizes the L2 loss. However in the refinement setting - where we can assume a well-behaved initial estimate - it is desirable to use a robust loss.
This would allow dealing with outliers (points with non-gaussian noise). In this context the Tukey loss, seems appropriate. See: https://github.com/albanie/mcnRobustLoss

interacts with
- #15650

some more robust functions to choose from: https://core.ac.uk/download/pdf/55191204.pdf

requires extension of [LMSolver](https://github.com/opencv/opencv/blob/a0041125c67dcbbd7483dee0d364d5f5e65e1366/modules/calib3d/include/opencv2/calib3d.hpp#L604) for IRLS
- weighted iteration (HZ A6)
- the actual robust weight function to use (flag)
Repository: opencv
Issue: OpenEXR loading not making use of multi-threaded IO
Labels: feature,priority: low,category: imgcodecs,category: 3rdparty

OpenEXR library supports multi-threaded file IO by setting Imf::setGlobalThreadCount(), this currently has no effect though on loading since loader code loops over image and reads data line by line (forcing it to be single threaded)
Repository: vscode
Issue: Cannot input with Chrome Extension Google Input Tool
Labels: feature-request,editor-input,web,chromium

**monaco-editor version:** 0.18.1
**Browser:** Chrome / Edge β
**OS:** Windows

**Steps or JS usage snippet reproducing the issue:**

<!-- Do you have a question? Please ask it on https://stackoverflow.com/questions/tagged/monaco-editor -->
Cannot input with [Chrome Extension Google Input Tool](https://chrome.google.com/webstore/detail/google-input-tools/mclkkofklkfljcocdinagocijmpgbhab).
Alphabet can be entered.
Japanese and Chinese etc are impossible

Install the extension and enter in Japanese or Chinese

![image](https://user-images.githubusercontent.com/38714187/70307294-3260b080-184c-11ea-9f85-8dc969c326ae.png)
Repository: go
Issue: cmd/compile: minimize stack occupation before function calls
Labels: NeedsInvestigation,compiler/runtime

In go 1.13 variables on the stack are kept ~alive~ allocated until the function returns. This is normally harmless, but can lead to surprising results: e.g. in the following example with a buf size of 1<<15 the process crashes because we reach the maximum stack size, but with a size of 1<<16 or more the process does not crash (as the slice is not allocated on the stack).

```go
package main 

func main() {
    rec(0)
}

func rec(n int) (m int) {
	buf := make([]byte, 1<<15)
	foo(buf)
	// buf is dead now
	if n >= 1<<16 {
		return n
	}
    return rec(n+1)
}

//go:noinline
func foo([]byte) {}
```

This is obviously a contrived example, but it would help if the set of ~live~ allocated variables were pruned as stack variables die, or if that is too expensive, at least immediately before performing a function call (especially if recursive).

Such an optimization would not only help in case of recursive functions that allocate a lot on the stack, but would rather help minimize time spent in morestack (https://github.com/golang/go/issues/18138) by reducing stack growth on any call tree that does not contain only live variables (as a further example, in API servers it is somewhat common to have handlers wrapped in middleware, each middleware being often used to execute some logic before and/or after the wrapped handler is executed. In the case of logic executed only or mostly before the wrapped handler, it is likely that most variables in the stack frame of the middleware are dead during the call to the wrapped handler)

A more compact stack, besides requiring less time to be spent in morestack, would also help dcache efficiency.
Repository: create-react-app
Issue: Provide a way to configure the `mainFields` for webpack
Labels: issue: proposal

The application build relies on the default webpack resolution of entry points for imported libraries, which are `["browser", "module", "main"]` for a web application.

Per spec (I believe) the `module` entry contains the ESM5 version of the library, i.e. tree shaken but transpiled to ES5.
Some libraries, in particular those built with `ng-packagr` offer additional entry points, such as `ESM2015` that contains a tree shaken version compiled to ES2015. 

I suggest that the react scripts allow to override the desired priority order in which entry points are resolved, such that the application author can decide to consume a smaller version of a library (because it has been compiled to ES2015 instead to ES5).

In webpack this is accessible via the https://webpack.js.org/configuration/resolve/#resolvemainfields field, but this configuration is not exposed by react scripts.
Repository: flutter
Issue: Allow custom handling of Notch tap on iOS
Labels: c: new feature,platform-ios,framework,f: scrolling,P3,team-ios,triaged-ios

This issue is about the handling of the tap on the Notch and how it's currently not customizable from the outside.

## Use case

For normal apps, the current behavior works excellent in a matter that you don't have to do anything to get this working out of the box.

As soon as you want to have a bit more control over your `ScrollController` or have more complicated scroll setups, there is no way of intercepting the click and making it work for the advanced structure.

## Proposal

The `Scaffold` could receive an argument called `onStatusBarTap`, which when provided would override the default behavior found in [scaffold.dart](https://github.com/flutter/flutter/blob/f30b7f4db93ee747cd727df747941a28ead25ff5/packages/flutter/lib/src/material/scaffold.dart#L2133)

This would allow the developer to customize the behavior to his liking and needs.



I would be willing to implement this if there is no blocker.
Repository: rust
Issue: rust-gdb fails at passing command line arguments to the executable
Labels: T-dev-tools,C-bug

This in particular happens when using servo's mach run utility.
I'm on `rustc 1.41.0-nightly (1bd30ce2a 2019-11-15)`

Output when using plain gdb:
```
$ ./mach -v run --debug --debugger gdb -d "http://nolp.dhl.de/nextt-online-public/set_identcodes.do?lang=de"
Reading symbols from /home/marc/Dokumente/02_GIT/servo/target/debug/servo...fertig.
(gdb) r
Starting program: /home/marc/Dokumente/02_GIT/servo/target/debug/servo http://nolp.dhl.de/nextt-online-public/set_identcodes.do\?lang=de
```

Output when using rust-gdb:
```
$ ./mach -v run --debug --debugger rust-gdb -d "http://nolp.dhl.de/nextt-online-public/set_identcodes.do?lang=de"
GNU gdb (Ubuntu 8.1-0ubuntu3.2) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/marc/Dokumente/02_GIT/servo/target/debug/servo...fertig.
/home/marc/Dokumente/02_GIT/servo/http://nolp.dhl.de/nextt-online-public/set_identcodes.do?lang=de: Datei oder Verzeichnis nicht gefunden.
(gdb) q
```

For some reason gdb tries to see this as an additional executable or shared library

Edit: https://github.com/rust-lang/rust/blob/master/src/etc/rust-gdb#L16 would adding --args be enough there?