sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: opencv
Issue: dnn: assertion failure with multiple images
Labels: bug,affected: 3.4,category: dnn

- OpenCV => 4.0.1-dev
- Operating System / Platform => Windows 64 Bit
- Compiler => mingw64 7.2.0
##### Detailed description
using the[ face_detector_uint8.pb](https://github.com/opencv/opencv_3rdparty/raw/8033c2bc31b3256f0d461c919ecc01c2428ca03b/opencv_face_detector_uint8.pb) model with multiple images (using dnn::blobFromImages), i get :
```
OpenCV(4.0.1-dev) Error: Assertion failed (start <= (int)shape.size() && end <= (int)shape.size() && start <= end) in total, file C:/p/opencv/modules/dnn/include/opencv
2/dnn/shape_utils.hpp, line 161
```

debugging it, i found, that in the 2nd ScaleLayer, the `endAxis` exceeds the size of the `inpShape`:

```
Thread 1 hit Breakpoint 9, cv::dnn::ScaleLayerImpl::forward (this=0xa5c1090, inputs_arr=..., outputs_arr=..., internals_arr=...)
    at C:\p\opencv\modules\dnn\src\layers\scale_layer.cpp:94
94              CV_Assert(total(inpShape, axis, endAxis) == numWeights);
(gdb) p inpShape
$16 = std::vector of length 4, capacity 4 = {3, 32, 24, 32}
(gdb) p axis
$17 = 0
(gdb) p endAxis
$18 = 5 // this is 2 with one image, and 5 with 3 of them !
```
thus the assert fails here: 

https://github.com/opencv/opencv/blob/7e2ebecd52232d02e2d53f3e073c076be73e3470/modules/dnn/include/opencv2/dnn/shape_utils.hpp#L160-L161


##### Steps to reproduce
    ```
    dnn::Net net = dnn::readNetFromTensorflow("opencv_face_detector_uint8.pb","opencv_face_detector.pbtxt");
    Mat f1=imread("../img/h1.png");
    Mat f2=imread("../img/h2.png");
    Mat f3=imread("../img/h3.png");
    vector<Mat> vf {f1, f2, f3};
    Mat blob = dnn::blobFromImages(vf, 1, Size(128,96), Scalar(104, 177, 123, 0), false, false);
    net.setInput(blob);
    Mat res = net.forward("detection_out");
    ```
Repository: create-react-app
Issue: Consider adding a lint rule to check for using `this.state` after calling `setState()`
Labels: issue: proposal

One of the most frequent errors we see asked about in Reactiflux is when a user writes code like this:

```js
this.setState({data : 123});
console.log(this.state.data);
// Why isn't it "123" right now?
```

The issue is that new users haven't yet internalized that `setState()` is usually async, and so `this.state` is still the previous value when the log statement executes synchronously.

Would it be worth adding a lint rule that specifically checks for accesses of `this.state` after a call to `this.setState()`, and warns about it?

The lint rule might need to be scoped some to avoid false positives, such as only looking for uses of `console.log()` instead of any state access in general, or only looking for attempts to use specific fields that were referenced in `setState` or the entire state object.

The [`eslint-plugin-react/no-access-state-in-setstate` rule](https://github.com/yannickcr/eslint-plugin-react/blob/84652b6527161f651a671754fb5f619296c3654e/lib/rules/no-access-state-in-setstate.js) might be a starting point for trying to write such a rule.
Repository: go
Issue: x/mobile/gl: ctx.BufferData and ctx.BufferSubData with unsafe.Pointer
Labels: Proposal,Proposal-Accepted,mobile


### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.11.4 windows/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes.


### What did you do?

When working with OpenGL, meshes consist out of vertices and indices that need to be pushed into GPU buffers.

The vertex array is usually of type `[]float32`, the index array is usually of type `[]uint16` or `[]uint32`.

The Context-object in `golang.org/x/mobile/gl` (`gl.go` and `gldebug.go`) offers the following methods for pushing such buffer data:

```
func (ctx *context) BufferData(target Enum, src []byte, usage Enum)
func (ctx *context) BufferSubData(target Enum, offset int, data []byte)
```
The problem here is that both functions require byte slices. In order to use them, the vertex/index arrays need to be converted first. If done in a safe way (without relying on go implementation details), the data effectively needs to be copied every time before it can be rendered.

When rendering large amounts of data this is a significant (and unnecessary) performance impact.

The implementation of Buffer(Sub)Data converts the incoming byte slice into an `unsafe.Pointer` - which is the format needed by the underlying OpenGL device. So this whole conversion is only needed to satisfy the function arguments.

Using only `[]byte` within the application is rarely an option because vertex/index data needs to be manipulated to create dynamic scenes. This would only move the conversion to a different location.



### What did you expect to see?

I suggest adding more generic functions for setting buffer data:

```
func (ctx *context) BufferData(target Enum, src unsafe.Pointer, size int, usage Enum)
func (ctx *context) BufferSubData(target Enum, offset int, data unsafe.Pointer, size int)
```
This would allow users to write any type of slice into buffers without expensive conversion or unsafe/fragile casting.

Alternatively (if the unsafe package should not face to the user) I suggest adding the following functions:
```
func (ctx *context) BufferData(target Enum, src []float32, usage Enum)
func (ctx *context) BufferData(target Enum, src []uint16, usage Enum)
func (ctx *context) BufferSubData(target Enum, offset int, data []float32)
func (ctx *context) BufferSubData(target Enum, offset int, data []uint16)
```
Repository: flutter
Issue: Feature: allow BottomNavigation to float above keyboard
Labels: c: new feature,framework,f: material design,P2,team-design,triaged-design

As per this PR #14406 the `BottomNavigation` has been explicitly set to not float above the keyboard when it is open as per the Material Design spec, however there could be instances where this could actually be desirable.

For instance, if you wanted to use the `BottomAppBar` as a chat text input field, this currently wouldn't be possible as the `BottomAppBar` cannot float above the keyboard.

You may think "why would you want to do that in the first place", but the simple answer is that the `bottomNavigation` option in the `Scaffold` is actually nothing more than a footer component that all ready has the correct behaviour with `SnackBar`s, `BottomSheet`s and `FloatingActionButton`s.

Having an option to allow this behaviour would make it much more simple for the developer to implement this kind of use case, which actually doesn't require much change to the `Scaffold` code.
Repository: TypeScript
Issue: Replace --preserveWatchOutput with --clearWatchOutput
Labels: Suggestion,Awaiting More Feedback

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Please read the FAQ first, especially the "Common Feature Requests" section.

-->

## Search Terms

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

## Suggestion

A compiler should never default to erase information and should never assume that it is the only program outputting to a terminal.

Instead of developers having to search for which program is clearing the console and fixing it, it should be an explicit setting.

`tsc --preserveWatchOutput` should be removed and replaced with an explicit clear instruction, such as `tsc --clearWatchOutput`

## Use Cases

<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->

## Examples



<!-- Show how this would be used and what the behavior would be -->

## 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: go
Issue: net: TestLookupGmailTXT failing on Plan 9
Labels: OS-Plan9,NeedsInvestigation

Since CL [157638](https://golang.org/cl/157638), TestLookupGmailTXT is failing on Plan 9.

```
--- FAIL: TestLookupGmailTXT (0.01s)
    lookup_test.go:248: got [globalsign-smime-dv=CDYX+XFHUw2wml6/Gb8+59BsH31KzUr6c1l2BPvqKX8=]; want a record containing spf, google.com
    lookup_test.go:248: got [globalsign-smime-dv=CDYX+XFHUw2wml6/Gb8+59BsH31KzUr6c1l2BPvqKX8=]; want a record containing spf, google.com
FAIL
FAIL	net	28.014s
```

See https://build.golang.org/log/10777f5ddff9d26836ac135c8c451166efa529ca
Repository: TypeScript
Issue: It is not allowed to push a number to the array foo in {foo: []}
Labels: Bug,Domain: Control Flow

**TypeScript Version:**  Playground

**Search Terms:** never[] 

**Code**

```ts
const foo = { foo: [] };
foo.foo.push(1);

const bar = [];
bar.push(1);
```

**Expected behavior:**
TypeScript should infer foo to be of type `{ foo: any[] }` and therefore `foo.foo.push(1);` should be allowed like `bar.push(1);` is allowed

**Actual behavior:**
Line 2: Argument of type '1' is not assignable to parameter of type 'never'.

**Playground Link:** https://www.typescriptlang.org/play/index.html#src=const%20foo%20%3D%20%7B%20foo%3A%20%5B%5D%20%7D%3B%0D%0Afoo.foo.push(1)%3B%0D%0A%0D%0Aconst%20bar%20%3D%20%5B%5D%3B%0D%0Abar.push(1)%3B%0D%0A

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: flutter
Issue: Reassemble method called too late when `hot reload`ing
Labels: c: new feature,tool,framework,t: hot reload,P3,team-framework,triaged-framework

Consider a widget that rebuilds very often (typically because of an animation). 
Then consider editing the sources of that widgets through hot-reload. 

It seems that when doing so, there's a chance for `build` method to be called _before_ `reassemble` was, but with the updated content. 

This is a big issue for the following open source library: https://github.com/rrousselGit/flutter_hooks
As it needs to override the `reassemble` behavior to handle potential changes within `build` method.

But if `build` method is called before `reassemble`, then the library won't be ready for it and the app will enter into an invalid state.
Repository: TypeScript
Issue: generic function parameter infers boolean as true
Labels: Suggestion,Needs Proposal,Domain: Type Inference

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.3.0-dev.201xxxxx

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** true boolean generic function extends default

**Code**

```ts
const fn = <T extends boolean>(flag: T | false = false) => flag
fn({} as boolean)

// The only workaround?
fn<boolean>({} as boolean)
```

**Expected behavior:**
Expected `fn<boolean>(flag?: boolean)` to be inferred

**Actual behavior:**
Instead got `fn<true>(flag?: boolean)` as the inferred type.

The issue stems from `T | false`, which is required for `= false` to work.

**Playground Link:** [Click here](http://www.typescriptlang.org/play/#src=const%20fn%20%3D%20%3CT%20extends%20boolean%3E(flag%3A%20T%20%7C%20false%20%3D%20false)%20%3D%3E%20flag%0D%0Afn(%7B%7D%20as%20boolean)%20%2F%2F%20call%20inferred%20as%20fn%3Ctrue%3E()%20when%20it%20should%20be%20fn%3Cboolean%3E()%0D%0A)

**Related Issues:** Possibly https://github.com/Microsoft/TypeScript/issues/28154
Repository: godot
Issue: Texture mapping emission with GIProbe produces incorrect reflection
Labels: bug,topic:rendering

**Godot version:** v3.0.6.stable.official.8314054

**OS/device including version:** macOS Mojave 10.14.1

**Issue description:**

When using a texture map in the emissive channel, reflections generated within a GIProbe display incorrectly.

**Steps to reproduce:**

1. Download and Import the following test project
2. Select the GIProbe
3. Click "Bake GI Probe"
4. Pan the camera to see the incorrect reflection

**Minimal reproduction project:**
[map_emission_test.tar.gz](https://github.com/godotengine/godot/files/1240608/map_emission_test.tar.gz)

I noticed this in my own project and, interestingly, was able to reproduce it with the same test project enclosed in #10534

![image](https://user-images.githubusercontent.com/1456302/51096055-0ee9ce80-177f-11e9-842a-d7de51e7fdbd.png)

![image](https://user-images.githubusercontent.com/1456302/51096050-0396a300-177f-11e9-8e94-176e42754c7f.png)

**Texture Map Used**
![image](https://user-images.githubusercontent.com/1456302/51096067-2c1e9d00-177f-11e9-8797-41d1033148cd.png)
Repository: vscode
Issue: Shrink empty lines
Labels: feature-request,editor-rendering

Visual Studio has a nice extension called "**Shrink Empty Lines**" which enables the user to have empty lines and/or lines without alphanumeric characters shrunk in the editor to a specific extent. This way users can have more vertical space for their actual code.

https://marketplace.visualstudio.com/items?itemName=VisualStudioPlatformTeam.SyntacticLineCompression

![image](https://user-images.githubusercontent.com/5047891/67569604-98c3c080-f72f-11e9-9712-4554ffc54ddd.png)


It would be very nice to have this feature on VS Code, maybe with an extra setting to specify shrinking percentage (or just an enumeration). I would have made an extension but this is clearly something not achievable through the current Extension API.
Repository: neovim
Issue: Can't undojoin an append or setline in <C-R> mappings
Labels: bug-vim,editor

- `nvim --version`: NVIM v0.3.2-996-g55c518588
- Vim 8.0 behaves the same way
- Operating system/version: 4.15.0-38-lowlatency #41-Ubuntu SMP PREEMPT Wed Oct 10 12:26:00 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

### Steps to reproduce using `nvim -u NORC`

    function CrMapping()
        undojoin | call append(line('.'), '')
        return ''
    endfunction
    imap <A-o> :<C-R>=CrMapping()<CR>

### Behaviour

**append** and **setline** calls in \<C-R>=mappings() register individual intermediate changes regardless of undojoin.

`undojoin | x,x delete`, however, does join the changes.
Repository: rust
Issue: librustc_codegen_ssa: exported entry function symbol is hardcoded as "main"
Labels: A-codegen,C-bug,requires-nightly

Seems suspicious as observed by @Zoxc [here](https://github.com/rust-lang/rust/pull/57573/files/57886cf92a063f2ba1f51a44d4ecc85e2ba0256f#r247388333).

Could we have in theory something like (or anything else):
```rust
#[no_mangle]
#[main]
fn awesome_main() { ... }
```

which would make this logic wrong?
Repository: flutter
Issue: Listview with shrinkwrap on the cross axis - impossible?
Labels: c: new feature,framework,P2,team-framework,triaged-framework

I have a column and I want to add an horizontal listview inside of it, but I can't seem to find a way to make the height of that listview fit. Shrinkwrap seems to apply only to the listview main axis (width/horizontal, in this case). I tried googling, asking on gitter, and even found some unanswered question on stackoverflow.

Is it really impossible? is it a feature one could implement and send a PR? is anyone working on it? or perhaps I'm just going about this the wrong way completely? what am I missing?
Repository: pytorch
Issue: [docs] Missing argument description (value) in scatter_   function documentation
Labels: todo,module: docs,triaged,module: scatter & gather ops

Documentation for ### scatter_ method lists the following arguments: **scatter_(dim, index, src)** 
It also, incorrectly, states that **src** can be a tensor or a float.
But it looks like, that in release 1.0.0, **src** cannot be a single float number. When you want to write the single float value to the tensor, you need to use undocumented **value** parameter, not **src** parameter. E.g. my_tensor.scatter_(dim=1, index=index_tensor, value=0.0)


cc @brianjo @mruberry
Repository: rust
Issue: Consider whether repeated macro matchers need separator disambiguation for futureproofing
Labels: A-macros

The following macro is valid, and can be used:

```rust
macro_rules! ex {
    ($($i:expr),* , $($j:ty),*) => { };
}

fn main() {
    ex!(a, dyn Copy);
}
```

However, if it's invoked in an ambiguous way, such as with `ex!(a, b)`, then it gives an error (no lookahead is performed to `)` to determine an unambiguous parse; examples can be constructed that avoid this unambiguity anyway).

Thus, while the original example compiles now, were `dyn Copy` to become a legal expression at some point in the future, it would become ambiguous. The issue here is that the separator `,` is re-used. In line with other futureproofing efforts like rust-lang/rfcs#550 and #56575, this should possibly be forbidden. The follow-set rule is insufficient to detect these cases as it only exists to allow us to promise in advance where a match is guaranteed to end; it's not sufficient to disambiguate between two potential parses starting from the same point.

My first attempt at rules to forbid this are for the situation where we have `... $(tt ...) SEP? OP uu ...`, with `uu ...` possibly empty. In these, `FIRST*` is a variant on `FIRST` from RFC 550: it represents all terminal tokens that could appear in a valid match. Thus, `FIRST*($t:ty)` would be any `can_begin_type` token, plus any token we worry might be legally allowed to begin a type someday, and so on.

1. If `SEP` is present, we must have we must have `SEP \not\in FIRST*(uu ...)`, insisting that the seperator token in repetition will never be ambiguous.
2. When `OP` is not `+`, we must have`FIRST*(tt ...)` and `FIRST*(uu ...)` be disjoint, insisting that the question of whether we're repeating at all will not be ambiguous.

For unseparated Kleene repeats, the second rule above, combined with the follow-set rule, are sufficient to disambiguate.

I have no idea how frequently these potential ambiguities arise in practice. It might be a lot, it might be a little. I expect that the first rule, for separators, might be safe to add because most macros that would risk running into them cannot be invoked except with an empty repetition due to existing ambiguity (the first macro can be invoked as `ex!(,a)`, for instance, with an empty repetition for `$i` eliminating the ambiguity) and therefore could likely mostly be removed. The second rule, however, might be more commonly violated.

cc @estebank @alexreg
Repository: go
Issue: cmd/go: 'go get' with semantic-version prefix doesn't fall back to matching tag or branch
Labels: NeedsFix,modules

<!-- 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.4 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><br><pre>
$ go env
GOARCH="amd64"
GOBIN="/Users/d.lopez/go/bin"
GOCACHE="/Users/d.lopez/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/d.lopez/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.11.4/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.11.4/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/d.lopez/go/src/gitlab.mycompany.com/my-user/my-project/go.mod"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/6n/q8wt03m13_x3w6v5__mzkwgc0000gn/T/go-build342969942=/tmp/go-build -gno-record-gcc-switches -fno-common"
</pre></details>

### What did you do?

```
go get github.com/sideshow/apns2@v0.14
```

### What did you expect to see?

The package `apns2` added sucessfully to the `go.mod` file and downloaded to `pkg/mod` using pseudo-version or whatever although it doesn't have a valid semver tag (patch number missing).

### What did you see instead?

This cryptic error (it took me several minutes to realize that a patch version was missing)

```
go get github.com/sideshow/apns2@v0.14: no matching versions for query "v0.14"
```

### Workaround

The only workaround I found is to pin to the latest commit SHA inside the `v0.14` tag on the required repository.

CC\ @bcmills
Repository: go
Issue: encoding/json: Map key marshals with MarshalText but unmarshals with UnmarshalJSON
Labels: 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.4 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes

### What did you do?

playgound: https://play.golang.org/p/4g3sHaRjh7z

1. Declare a struct type that implements all of `MarshalJSON`, `UnmarshalJSON`, `MarshalText`, `UnmarshalText`, where the JSON form is an object, not string.
2. Use that type as a map key in a map.
3. `json.Marshal` the map. Notice the MarshalText behavior is used to convert the map keys to strings in the resulting JSON object.
4. `json.Unmarshal` the JSON bytes from (3) into a new map.

### What did you expect to see?

`json.Unmarshal` should use the map key's `UnmarshalText` method, because it is forced to be a JSON string.

### What did you see instead?

`json.Unmarshal` used the type's `UnmarshalJSON` method on the map key data.

### Debugging

TextMarshaler map keys were introduced in ffbd31e9f79ad8b6aaeceac1397678e237581064. The core issue is that `literalStore` always prefers `UnmarshalJSON` ([decode.go#L855](https://github.com/golang/go/blob/4b36e12/src/encoding/json/decode.go#L855)) before attempting `UnmarshalText` because `indirect` only returns one of the interfaces and prefers JSON to Text. This is correct in most cases, but for map keys we're calling literalStore explicitly because the value implements UnmarshalText ([decode.go#L776](https://github.com/golang/go/blob/4b36e12/src/encoding/json/decode.go#L776-L778)).
Repository: TypeScript
Issue: Include parameter information in quickInfo on function arguments
Labels: Suggestion,Domain: JSDoc,Domain: Quick Info,Experience Enhancement

From https://github.com/Microsoft/vscode/issues/57341

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.3.0-dev.201xxxxx

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

**Code**
- Quick info
- quickinfo
- hover

**Repo**
For the js:

```js
/**
 * @param {number} x Bla
 */
function foo(x) { }

foo(123)
```

Hover over `123`

**Current behavior**
No quick info returned

**Feature Request**
Show the parameter name (`x`) and potentially other information about it when hovering over function arguments like `123`