sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: encoding/json: omitempty for arrays is confusing
Labels: Documentation,NeedsInvestigation

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.11.2 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes.

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary></details>

```bash
$ go env
GOARCH="amd64"
GOOS="darwin"
```

### What did you do?
https://play.golang.org/p/NlRBFTZHFYd
```go
func main() {
	type Foo struct {
		ID [16]byte `json:",omitempty"`
	}

	var f Foo
	j, _ := json.Marshal(f)
	fmt.Println(string(j))
}
```

### What did you expect to see?
```json
{}
```

### What did you see instead?
```json
{"ID":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]}
```

This is caused by `isEmptyValue` inside `encoding/json` checking to see if the length of the array is 0. For people actually using an array (and not a slice), it is unlikely that they would ever use an array of zero length. It is likely, however, that they might want to omit the result if all of the values in the array are empty. For example, if a user is using `[16]byte` to represent a UUID, they might want to omit encoding it if it is all zeroes. This was brought up in #11939, specifically [this comment](https://github.com/golang/go/issues/11939#issuecomment-429184373). It would be nice if we could do this generically for arrays with values we can determine are empty.
Repository: pytorch
Issue: AttributeError: module 'caffe2.python._import_c_extension' has no attribute 'get_cudnn_version' when Caffe2 is not built with CuDNN
Labels: caffe2

Steps to reproduce:

1. Build caffe2 without CuDNN (e.g., have CUDA but don't install CuDNN)
2. Run `python caffe2/python/data_parallel_model_test.py DataParallelModelTest.test_equiv`

Expected: It should work, or maybe it gives me an error/skip saying I can't run this test without CuDNN

Actual:

```
python caffe2/python/data_parallel_model_test.py DataParallelModelTest.test_equiv
Traceback (most recent call last):
  File "caffe2/python/data_parallel_model_test.py", line 18, in <module>                                                  
    from caffe2.python import brew, core, cnn, data_parallel_model, dyndep, \                                             
  File "/data/users/ezyang/pytorch-tmp/caffe2/python/brew.py", line 12, in <module>                                       
    from caffe2.python.model_helper import ModelHelper
  File "/data/users/ezyang/pytorch-tmp/caffe2/python/model_helper.py", line 8, in <module>                                
    from caffe2.python import core, scope, workspace, helpers                                                             
  File "/data/users/ezyang/pytorch-tmp/caffe2/python/core.py", line 15, in <module>                                       
    from caffe2.python import scope, utils, workspace
  File "/data/users/ezyang/pytorch-tmp/caffe2/python/workspace.py", line 53, in <module>                                  
    GetCuDNNVersion = C.get_cudnn_version
AttributeError: module 'caffe2.python._import_c_extension' has no attribute 'get_cudnn_version'  
```

Note to people with this problem: You can fix the problem by making sure Caffe2 is built with CuDNN.
Repository: flutter
Issue: iOS should provide a way to enable the semantic tree for testing frameworks 
Labels: a: tests,platform-ios,engine,a: accessibility,a: existing-apps,P2,team-ios,triaged-ios

Currently, on a physical iOS device, the engine only builds the semantics tree if:

```
  bool enabled = UIAccessibilityIsVoiceOverRunning() || UIAccessibilityIsSwitchControlRunning();
```

This is a problem for testing frameworks that want to find elements by semantic label, e.g. the following EarlGrey code works on a Simulator but not on a physical device:

```
[[EarlGrey selectElementWithMatcher:grey_accessibilityLabel(@"POP")] performAction:grey_tap()];
```

in the ios_add2app tests.

One (bad) solution for this would be to check if the `EarlGreyImpl` class is defined and enable semantics in that case - but what about other test frameworks, etc.

We should provide some way for test users to force the semantics to be enabled, perhaps by one of the following.

/cc @cbracken @chinmaygarde @xster @jamesderlin
Repository: godot
Issue: Moving anchors together with the object
Labels: enhancement,discussion,topic:editor,usability

**Godot version:**
11d7738

**Issue description:**
The only way to have an object resize proportionally with the screen (same behaviour as % in CSS) is to move the anchors around and have always margin 0.
The current workflow for this kind of task is clunky as there is no way to move the anchors together with the object in the 2D view.
Related to #1276


**Proposal**
I don't have a clear idea yet on how this feature should look like, as i foresee many problems for when people just want to move only the margins.
I'd like to discuss here and see if there is a nice solution to this problem
@groud @JFonS  I'd like your opinion on this :)
Repository: go
Issue: x/build/cmd/buildlet: remaining processes not killed
Labels: Builders

When `buildlet` times out,  some processes remain in background and they need to be killed manually. 
It seems that `buildlet` only kills its first children and not all its offsprings. 

It occurs on aix/ppc64 builder. But I think it's a more general issue. 

Here are some processes remaining after builds had failed on aix/ppc64. 
`cmd/buildlet` seems to only kill "go tool dist test ... "
```
    root 15008262        1   0 14:43:03      -  0:00 /ramdisk8GB/workdir-host-aix-ppc64-osuosl/go/pkg/tool/aix_ppc64/dist test --no-rebuild --banner=XXXBANNERXXX: test:1_10
    root  7930506 15008262   0 14:43:06      -  0:01 /ramdisk8GB/workdir-host-aix-ppc64-osuosl/go/test/runtest.exe --shard=1 --shards=10
    root 15860332  7930506   0 14:43:15      -  0:00 /ramdisk8GB/workdir-host-aix-ppc64-osuosl/go/bin/go run -gcflags= fixedbugs/issue4667.go
    root 16449854 15860332 117 14:43:16      - 244:33 /ramdisk8GB/workdir-host-aix-ppc64-osuosl/go/pkg/tool/aix_ppc64/link -o /ramdisk8GB/workdir-host-aix-ppc64-osuosl/tmp/go-build817241358/b001/exe/issue4667 -importcfg /ramdisk8GB/workdir-host-aix-ppc64-osuosl/tmp/go-build817241358/b001/importcfg.link -s -w -buildmode=exe -buildid=0SI_pU16NxBjYDL8rkvo/L9t_iML1T1ahnSRDhIh8/1p0X_Ta401ybIH1jFEpb/0SI_pU16NxBjYDL8rkvo -extld=gcc /ramdisk8GB/workdir-host-aix-ppc64-osuosl/tmp/go-build817241358/b001/_pkg_.a

    root  4391522        1   0 03:47:21      -  0:00 /ramdisk8GB/workdir-host-aix-ppc64-osuosl/go/pkg/tool/aix_ppc64/dist test --no-rebuild --banner=XXXBANNERXXX: test:3_10
    root 10158466  4391522   0 03:47:24      -  0:01 /ramdisk8GB/workdir-host-aix-ppc64-osuosl/go/test/runtest.exe --shard=3 --shards=10
    root 10748370 10158466 356 03:47:34      - 1877:52 /ramdisk8GB/workdir-host-aix-ppc64-osuosl/go/bin/go build -gcflags -S=2 /ramdisk8GB/workdir-host-aix-ppc64-osuosl/go/test/codegen/memcombine.go


    root 12583384        1   0 14:07:27      -  0:00 /ramdisk8GB/workdir-host-aix-ppc64-osuosl/go/pkg/tool/aix_ppc64/dist test --no-rebuild --banner=XXXBANNERXXX: test:2_10
    root 20709728 12583384   0 14:07:29      -  0:01 /ramdisk8GB/workdir-host-aix-ppc64-osuosl/go/test/runtest.exe --shard=2 --shards=10
    root 14418236 20709728   0 14:07:35      -  0:00 /ramdisk8GB/workdir-host-aix-ppc64-osuosl/go/bin/go tool compile -e /ramdisk8GB/workdir-host-aix-ppc64-osuosl/go/test/fixedbugs/bug151.go
    root 17760658 14418236 469 14:07:35      - 1051:28 /ramdisk8GB/workdir-host-aix-ppc64-osuosl/go/pkg/tool/aix_ppc64/compile -e /ramdisk8GB/workdir-host-aix-ppc64-osuosl/go/test/fixedbugs/bug151.go
```

Looking at the code, `killProcessTree` is called when the builder is killed by the coordinator (right?). 
However, in my understanding, it only kills one process and not the whole process tree (cf https://github.com/golang/build/blob/master/cmd/buildlet/buildlet.go#L1590). 
I think it should call syscall.Kill with -p.Pid in order to kill the whole process group. 

Maybe it's a duplicate of #15778.
Repository: godot
Issue: Project settings hold editor infos
Labels: discussion,topic:editor

**Godot version:**
11d7738


**Issue description:**
Seems like Godot is storing editor specific data inside the project settings.
I believe this is a leftover of some sort before the editor had its own settings?
![image](https://user-images.githubusercontent.com/7917475/50152927-4458e480-02c5-11e9-8220-7842b7949b49.png)

**Bonus:**
Why is there a "Active" toggle that has as a tooltip "Internal Editor Setting,don't touch"?
Should it be directly renamed to "DONT TOUCH THIS PLS" ?
Repository: vue
Issue: Add an option to throw global errors, making it possible for debuggers to automatically break on error.
Labels: feature request

### What problem does this feature solve?
Currently, the [globalHandleError](https://github.com/nialna/vue/blob/dev/src/core/util/error.js#L27) function will intercept all errors thrown in components and log them. It can also pass them to an external error handler, but that external error handler won't be able to throw it because the call to `config.errorHandler` is wrapped in a try catch.

In vanilla JS, when an unhandled error happens in your code, the debugger can break immediately, giving you access to the stack and context. When using VueJS, we have no way of doing this because the errors are always handled by Vue.

### What does the proposed API look like?
The simplest way I can think of is to add a new `config` option, for example:

```js
Vue.config.throwUnhandledErrors = true;
```

Then in `globalHandleError`, we could check for that flag and throw errors:

```js
function globalHandleError (err, vm, info) {
  if (config.throwUnhandledErrors) {
    throw(err);
  } else if (config.errorHandler) {
    try {
      return config.errorHandler.call(null, err, vm, info)
    } catch (e) {
      logError(e, null, 'config.errorHandler')
    }
  }
  logError(err, vm, info)
}
```

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: rust
Issue: A type inference problem with struct fields and collect method
Labels: A-inference

Hi, I found a type inference problem like below. You can check it in Rust Playground from link.
If it's possible, i would like to write code with less type annotation.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=da38ac68e6aba30ab33c0ddc42ecdd3b

```
#![allow(unused)]
struct Foo {
    vector: Vec<i32>,
}

fn main() {
    let v1 = vec![1, 2, 3, 4];
    
    let v2 = v1.into_iter().map(|num| num + 1).collect();
    
    // enabling below code will require type annotation of v2 in above line.
    // println!("v2 len: {}", v2.len());
    
    let _foo = Foo {
        vector: v2, // I thick compiler can determine type of v2 here.
    };
}
```
Repository: opencv
Issue: LUT for 32-bit int
Labels: feature,priority: low

Table translation (LUT) is a frequently function while image processing and analysis. But it is usually necessary not for byte (CV_8U), but for 32-bit integer matrices. For example, we have a map of 100000 objects, recognized on the image (like connected components or results of superpixel), and we join them to some 1000 clusters according different rules (on the base of color, borders between objects, gradients, etc.) - after this, we need to remap the matrix by table int[100000].

Of course, we always can write the loop manually. But, on the one hand, OpenCV could provide maximally quick implementation, optimized for GPU, multithreading and other cases. On the other hand, many algorithms are written not in C++, but in Python, Java (like in my case), etc. Simple loop in Java works essentially slower, than your current LUT implementation, and it is especially important when all data are stored in GPU memory (UMat).

I think it could be a good idea to add LUT version for CV_32S input type in next OpenCV version. What do you think?
Repository: go
Issue: runtime: externally linked programs don't detect deadlocks
Labels: help wanted,NeedsFix,compiler/runtime


### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.11.4 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes (also master as of last week)

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/a/.cache/go-build"
GOEXE=""
GOFLAGS="-mod=vendor"
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/a/n/go/"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build536260035=/tmp/go-build -gno-record-gcc-switches"

</pre></details>

### What did you do?

Did `go run -buildmode=pie` with this:

```
package main

func main() {
	ch1 := make(chan string)
	ch2 := make(chan string)
	go func() {
		<-ch1
		ch2 <- "done"
	}()
	<-ch2
	ch1 <- "done"
}
```

### What did you expect to see?

Process dies with the "all goroutines are asleep" message.

### What did you see instead?

Not dead but forever sleeping.
Repository: opencv
Issue: Unstable result of useOpenCL in multithreading Java environment
Labels: incomplete

I detected, that `useOpenCL` returns different values when I intensively call OpenCV functions in Java from different threads. (My test sequentially calls several simple OpenCV UMat functions, each function in a separate thread, and repeats all this 150 times in a simple loop.) Sometimes useOpenCL returns `true`, sometimes `false`. In single-thread mode it always returns `true`. Other function `haveOpenCL` always returns `true`.

The details are here: https://github.com/bytedeco/javacpp-presets/issues/659 

Can you comment the issue? In JavaCPP they say that it looks as a bug in OpenCV. Is it really so? Or, maybe, `useOpenCL` returns only "recommendation" to use GPU (the device is available and ready-to-use), and sometimes the device is "busy" and this function returns `false` - though we can use UMat functions? Should I use `haveOpenCL` (instead of `useOpenCL`) , at the very beginning of my app, to decide, does make sense usage UMat in all algorithms or Mat will be better choice?
Repository: godot
Issue: Calling `set()` and `get()` with invalid property name should raise an error
Labels: enhancement,topic:core,topic:gdscript,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. -->
Godot 3.1-dev (3c999ae1a)

**OS/device including version:**
<!-- Specify GPU model and drivers if graphics-related. -->
Linux Mint 19

**Issue description:**
<!-- What happened, and what was expected. -->
When you call `set()` or `get()` with an invalid property name (or value), there's no error message. It makes hard to find typos in the code.

**Steps to reproduce:**
* Call `set()` (or `get()`) with a property name that does not exist.
* Notice how no errors are logged.

**Minimal reproduction project:**
[set-get-no-error.zip](https://github.com/godotengine/godot/files/2692285/set-get-no-error.zip)
Repository: flutter
Issue: Benchmark TextField performance
Labels: a: text input,team,framework,engine,c: performance,P2,team-engine,triaged-engine

The text field makes many repeated calls to `GetRectsForRange/GetBoxesForRange` which is not a trivial task.

With the introduction of even more calls to it in https://github.com/flutter/flutter/commit/f8964ae250354e655ac81e1be3201ffadd8ce3b2, as well as the discovery and fixing of https://github.com/flutter/flutter/issues/24796, we should benchmark the text field to prevent regressions and ensure it is performant.
Repository: rust
Issue: Docs: std::alloc::set_alloc_error_hook clarifications
Labels: C-enhancement,T-libs-api,A-docs

In using this function I am wondering a few things:

- What happens if I oom while handling an oom? Is the oom handler called again? Does the process immediately abort (ala panic)?

- Does triggering oom remove the custom oom handler? The presence of `take_alloc_error_hook` makes it seem like that may the case, but it is not. It looks like the custom handler stays in place through its invocation. Docs would be better to mention that it's possible to oom recursively and invoke your oom handler recursively.

- Is OOM the only time that memory allocation fails? The document doesn't mention "out of memory", but the situation this handles is commonly called "OOM". The docs would better mention "out of memory" and whether there is a distinction between allocation failure types.

- Does `take_alloc_error_hook` restore the default error hook?

Are the answers to these questions known and intended? Please add them to the docs.

Here are some harder questions:

Can I and should I try to recover from an oom? The oom handling mechanism calls abort after calling the oom handler, but what if I panic in the handler?

I could empty my caches or otherwise mess with the allocator, panic, catch the panic, and try to continue. Is that a valid and intended use case?
Repository: scrcpy
Issue: Notifications won't swipe off lock screen.
Labels: input events

I can slide them to the right at whatever speed with the mouse, but they don't slide off the screen and go away as what happens when you do it with your finger. 

Moto g5 plus, android 8.1.
Repository: pytorch
Issue: Projective Transformation grid generator
Labels: todo,triaged,enhancement

## 🚀 Feature
<!-- A clear and concise description of the feature proposal -->
An analogous function to `torch.nn.functional.affine_grid` that takes a full 3x3 projective transformation matrix of the form
```
[[a, b, c],
 [d, e, f],
 [g, h, 1]]
```
would be really nice. 
## Motivation
Reproducing the projective transformation results from Spatial Transformer Networks.
<!-- Please outline the motivation for the proposal. Is your feature request related to a problem? e.g., I'm always frustrated when [...]. If this is related to another GitHub issue, please link here too -->

## Pitch

<!-- A clear and concise description of what you want to happen. -->
A new projective_transform function added with a special case that checks if the bottom row of the input matrix is `[0, 0, 1]` and performs the more optimized affine transform. The old affine transform function should be deprecated (as affine transforms are just a subset of projective transforms). 

## Alternatives

<!-- A clear and concise description of any alternative solutions or features you've considered, if any. -->
Maybe a generalized function that takes a lambda mapping original coordinates to image coordinates.
Repository: pytorch
Issue: F.grid_sample doesn't respect padding_mode when height of inputs is 1
Labels: module: docs,triaged,module: interpolation

## 🐛 Bug

The function `F.grid_sample` takes two args: `inputs`and `coords`. For the sake of simplicity I'm going to describe this issue for the case when `inputs` represents a grayscale image and has a shape `[1, 1, IH, IW]`. 

The `coords` argument has shape `[1, OH, OW, 2]`, where the final dimension of size 2 is an x and y coordinate in normalized input space, where `-1,-1` is the top left of the image and `+1,+1` is the bottom right. 

The `[1, C, OH, OW]` output is constructed by sampling values from the input at the xy-coordinate specified in the `coords` argument. Bilinear interpolation is used when the xy-coordinate (after de-normalization) doesn't fall cleanly within a single pixel in `inputs`.

The bug has to do with the behavior when a value in `coords` falls outside of the range `[-1,1]`. The docs state that the value should be bilinearly based on the border mode (the default behaves as if the entire input image was surrounded with zeros). This works in most cases. However, this fails in the case where `IH=1`.


## To Reproduce

First consider the working case. Lets just make a 2x2 image and sample "under it" at the normalized position `(0, 30)` (which is very far under the sample image).

```
        # Make a 2x2 image
        inputs = torch.Tensor([
            [1, 2],
            [1, 2]
        ])[None, None]

        # Sample at a position way outside of the image
        coords = torch.Tensor([0, 30])[None, None, None]
        print(F.grid_sample(inputs, coords))
```

This code correctly returns that the sampled value is `tensor([[[[0.]]]])` (because, again, we are way off the image). 

However, if we remove a row from the image (making it have shape (1, 2)) and we sample way underneath the image again, we get a non-zero result.

```
        inputs = torch.Tensor([
            [1, 2],
        ])[None, None]
        coords = torch.Tensor([0, 30])[None, None, None]
        print(F.grid_sample(inputs, coords))
```

This outputs `tensor([[[[1.5000]]]])`, which seems to indicate that torch is treating the image as if it is infinitely tiled in the Y direction. 

## Environment

PyTorch version: 1.0.0 (also tested on 0.4.1)
Is debug build: No
CUDA used to build PyTorch: 9.0.176

OS: Ubuntu 16.04.5 LTS
GCC version: (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609
CMake version: version 3.13.1

Python version: 3.6
Is CUDA available: Yes
CUDA runtime version: 8.0.61
GPU models and configuration: GPU 0: GeForce GTX 1050
Nvidia driver version: 384.130
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.6.0.21
/usr/lib/x86_64-linux-gnu/libcudnn_static_v6.a


<!-- Add any other context about the problem here. -->


cc @brianjo @mruberry
Repository: vscode
Issue: Prevent Find/Replace bar from returning after Next Match (F3)
Labels: feature-request,editor-find

In regular Visual Studio, when you press Ctrl+F to find, you type your search text and press Enter.  Because the Find/Replace "dialog" does not automatically go away, I've learned to immediately press Esc to get rid of it.  At that point, I can press F3 to repeat search (next match) or Shift+F3 for previous match and the dialog remains hidden.

This is not true in Visual Studio Code -- even after pressing Esc to make the Find/Replace bar go away, it reappears after every F3, which is maddening.  I've already given the dialog everything it needs.  Please make it possible for it to remain hidden until summoned again with Ctrl+F.
Repository: go
Issue: cmd/compile: make argument size of -S output more accurate
Labels: NeedsFix,compiler/runtime

I would like to seek clarification about the correct argument size for assembly functions. Specifically, `asmdecl` requires different sizes from those reported by `go tool compile -S`. See the following gist for an example:

https://gist.github.com/mmcloughlin/598774c255f40605e613ffb3361e240c

I'll copy the main points here. The function implemented is:

```go
package argsize

func Index3(a [7]byte) byte

func Expect(a [7]byte) byte { return a[3] }
```

with assembly

```asm
TEXT ·Index3(SB),0,$0-16
	MOVB	a_3+3(FP), AL
	MOVB	AL, ret+8(FP)
	RET
```

`go tool compile -S` reports argument size 16

```
"".Expect STEXT nosplit size=10 args=0x10 locals=0x0
	0x0000 00000 (argsize.go:6)	TEXT	"".Expect(SB), NOSPLIT|ABIInternal, $0-16
```

while `asmdecl` requires size 9

```
./argsize.s:1:1: [amd64] Index3: wrong argument size 16; expected $...-9
```

Is this behaving as intended?

cc @alandonovan @josharian