sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Rustdoc: condense "auto traits" section for types?
Labels: T-rustdoc,C-enhancement,A-trait-system,A-rustdoc-ui,A-auto-traits

At the moment we have 5 auto traits documented for each type, and there will likely more in the future (e.g. from @oli-obk's consteval talk: `ConstSafe`, `ConstRefSafe`).

For the majority of types where all auto traits are always either impl or !impl, I propose to condense the section, e.g. like in this mockup ([original page here](https://doc.rust-lang.org/std/thread/struct.Thread.html#synthetic-implementations)):

![image](https://user-images.githubusercontent.com/144359/65069219-85804100-d98a-11e9-9a8f-d0dcdf2a75d4.png)
Repository: godot
Issue: [Bullet] move_and_slide() causes jitter when colliding with corners between walls
Labels: bug,confirmed,topic:physics,topic:3d

**Godot version:**
3.1.1.stable.official

**OS/device including version:** 
Linux / Fedora 30

**Issue description:**
move_and_slide() can cause a lot of jitter when KinematicBody collides with corners, or anything actually. (sometimes even with simple 90° corners)

You can observe this in pretty much every single project that uses move_and_slide(), including the FPS Tutorial from Godot documentation.

**Notes:**

- Choosing GodotPhysics instead of Bullet may reduce the jitter, but it's still there and visible.
- I haven't tested other move* functions.

**Steps to reproduce:**

- Use move_and_slide().
- Collide with some corners.

**Minimal reproduction project:**
[godot-fps-master.zip](https://github.com/godotengine/godot/files/3622965/godot-fps-master.zip)

- https://www.youtube.com/watch?v=d8374DaCt30 (video of the attached project)
- https://www.youtube.com/watch?v=IINx06mYezA (another example that uses code from the FPS Tutorial) (Ignore the flashes of color)
Repository: go
Issue: x/build/cmd/coordinator: improve error message when build fails due to a module not being tidy (and causing failed requests to sum.golang.org)
Labels: Testing,Builders,NeedsInvestigation

The fix to #32528 was implemented by finding nested modules, and then invoking `go test` once for each one, in sequence.

~~This isn't compatible with `GO_DISABLE_OUTBOUND_NETWORK=1` being set and converted to a permanent outbound network restriction as soon as the first set of tests run, because the second `go test` invocation may need to talk to the module mirror and/or checksum database to fetch/verify additional modules.~~

**Edit:** More accurately, the network gets restricted early on, before any of the tests run. The network restriction only affects the default checksum database at https://sum.golang.org. The module proxy is not affected because it's [treated specially](https://github.com/golang/build/blob/da876aaec3965bc391792c76f5ccca997637a4ee/cmd/coordinator/coordinator.go#L2705-L2714). See https://github.com/golang/go/issues/34356#issuecomment-532373912 for more details.

/cc @bradfitz @bcmills
Repository: pytorch
Issue: DistAutogradContext should be cleaned up in case of node failures.
Labels: module: autograd,module: memory usage,triaged,enhancement,module: rpc

In distributed autograd, there is a single node that initializes a new distributed autograd context and passes that over to other nodes as part of the backward pass. Each node creates an autograd context locally to store relevant information. Now, if the original node fails for some reason, the autograd context on the other nodes are not cleaned up. We should have a mechanism where we cleanup autograd contexts which have been around for a while and haven't been released (for example: 2x the autograd timeout).

cc @ezyang @gchanan @zou3519 @SsnL @albanD @gqchen @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @aazzolini @rohan-varma @xush6528
Repository: go
Issue: x/build/cmd/gopherbot: opt-out changes from Gerrit `approvers` list from automatically adding reviewers
Labels: Builders,NeedsInvestigation

I'd rather gopherbot stopped automatically adding reviewers to my CLs.

I appreciate the intent, and I think it's a great idea for people who are new to contributing to Go. But I'm comfortable using Gerrit and finding reviewers, and I don't want my reviewers confused because Gopherbot asked them to look at my CLs out of order.
Repository: flutter
Issue: video_player add media lock screen
Labels: c: new feature,p: video_player,package,c: proposal,team-ecosystem,P3,triaged-ecosystem

<!-- Thank you for using Flutter!

     If you are looking for support, please check out our documentation
     or consider asking a question on Stack Overflow:
      * https://flutter.dev/
      * https://api.flutter.dev/
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     If you have found a bug or if our documentation doesn't have an answer
     to what you're looking for, then fill our the template below. Please read
     our guide to filing a bug first: https://flutter.dev/docs/resources/bug-reports
-->

## Use case

<!--
     Please tell us the problem you are running into that led to you wanting
     a new feature.

     Is your feature request related to a problem? Please give a clear and
     concise description of what the problem is.

     Describe alternative solutions you've considered. Is there a package
     on pub.dev/flutter that already solves this?
-->

## Proposal

- Add the ability to play audio files in the background when user closes app.
- Add the ability to show the media player controls on the lock screen while media plays on the background.
Repository: TypeScript
Issue: Expose inferred type for use in type annotations
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 help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ, especially the "Common Feature Requests" section: https://github.com/Microsoft/TypeScript/wiki/FAQ

-->

## Search Terms

infer inferred type annotation

## Suggestion

When annotating the type of a variable, allow the variable to have access to the type that would've been inferred for the RHS, so that the author can build a type annation derived from that inferred value. This value could be exposed as the `inferred` keyword or similar.

## Use Cases/Examples

```ts
// All properties in `deletable` are subject to being deleted, so we want
// the type to be a Partial of the would-have-been-inferred type.
// I don't think there's a great way to write this at the moment.
const deletable: Partial<inferred> = { a: true, b: false, c: "xyz" };

// The `mutable` property might be reassigned to, but all the other properties wont.
// So combined `Readonly` and `inferred`, with an exception for mutable.
type Legal = "initial" | "middle" | "final"
const partiallyMutable: Readonly<Omit<inferred, "mutable">> & { mutable: Legal } = { 
  x: "literally", 
  y: true,
  mutable: "initial",
  lotsOfOther: 47,
  literalPropsHere: "name"
}

// We want to verify assignability to the mapped type, to make sure that, as new 
// required keys are added, this object literal is updated. However, we also want the
// values at each key to be inferred narrowly as a literal type for use in the code that follows.
type RequiredKeys = "A" | "B" | "C"
const mustHaveAllKeys: inferred & { [K in RequiredKeys]: any } =  = {
  "A": true,
  "B": false,
  "C": "hi!"
}

// typeof mustHaveAllKeys.A should be true!
```

## Related issues

- https://github.com/Microsoft/TypeScript/issues/24375
- https://github.com/microsoft/TypeScript/issues/17574

## 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: opencv
Issue: VIDEOIO ERROR: V4L2: Pixel format of incoming image is unsupported by OpenCV
Labels: feature,category: videoio(camera)

![Screenshot from 2019-09-18 14-57-13](https://user-images.githubusercontent.com/29121012/65123996-0d1b8d80-da27-11e9-86a7-d688dd21f046.png)
/VIDEOIO ERROR: V4L2: Pixel format of incoming image is unsupported by OpenCV/
I am trying to use darknet with input from Intel Realsense D435 RGBD camera on ubuntu 18
Please advise!
Repository: pytorch
Issue: NNPACK condition should be changed (ARM processors)
Labels: module: convolution,triaged,enhancement,module: nnpack

## 🚀 Feature
Remove the condition for usage of NNPACK for conv2d which requires the batchsize >= 16. Otherwise THNN is used on ARM processors

## Motivation

I tested NNPACK vs. THNN and I am think that NNPACK is mostly faster than THNN for batchsize = 1 and also > 1. NNPACK is still being excluded in special cases even when the condition batchsize >= 16 is removed, for example THNN is used when stride > 1.

The condition now makes little sense because it abolishes  NNPACK for inference (where batchsize = 1) where the speedup from NNPACK is most significant. In particular the speed-up is most significant because in case batchsize = 1 NNPACK uses a specific inference forward function which gives a an additional huge advantage in speed while for batchsize > 1 NNPACK uses a training forward function which is advantagious for backprop (I think at least).

To summarize: Best case scenario for inference  (usually batchsize = 1) - condition on NNPACK is removed and if other conditions allow NNPACK usage, NNNPACK is used and goes into sped-up inference function (only for batchsize = 1) and forward pass is super fast.

## Pitch

Remove condition in
https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/Convolution.cpp#L173
input.size(0) >= 16

## Alternatives

Allow for use of Eigen Tensor Library and/or ARM Compute Library
Repository: pytorch
Issue: RuntimeError: tensor.ndimension() == static_cast<int64_t>(expected_size.size()) INTERNAL ASSERT FAILED
Labels: needs reproduction,module: multi-gpu,module: cuda,triaged

## 🐛 Bug

Hey
I am trying to train my model. I am using Multi-GPU training.
While training I get the next Runtime error:

```
RuntimeError: tensor.ndimension() == static_cast<int64_t>(expected_size.size()) INTERNAL ASSERT FAILED at /opt/conda/conda-bld/pytorch_1565272279342/work/torch/csrc/cuda/comm.cpp:220, please report a bug to PyTorch.  (gather at /opt/conda/conda-bld/pytorch_1565272279342/work/torch/csrc/cuda/comm.cpp:220)
frame #0: c10::Error::Error(c10::SourceLocation, std::string const&) + 0x47 (0x7f75fc2dfe37 in /home/nlp/avivwn/miniconda3/envs/nomlex/lib/python3.6/site-packages/torch/lib/libc10.so)
frame #1: torch::cuda::gather(c10::ArrayRef<at::Tensor>, long, c10::optional<int>) + 0x6b6 (0x7f75708af616 in /home/nlp/avivwn/miniconda3/envs/nomlex/lib/python3.6/site-packages/torch/lib/libtorch.so)
frame #2: <unknown function> + 0x5fa742 (0x7f75fd9c7742 in /home/nlp/avivwn/miniconda3/envs/nomlex/lib/python3.6/site-packages/torch/lib/libtorch_python.so)
frame #3: <unknown function> + 0x1c8316 (0x7f75fd595316 in /home/nlp/avivwn/miniconda3/envs/nomlex/lib/python3.6/site-packages/torch/lib/libtorch_python.so)
<omitting python frames>
frame #14: THPFunction_apply(_object*, _object*) + 0x98f (0x7f75fd7ba4bf in /home/nlp/avivwn/miniconda3/envs/nomlex/lib/python3.6/site-packages/torch/lib/libtorch_python.so)
frame #63: __libc_start_main + 0xf5 (0x7f760725c495 in /lib64/libc.so.6)
```

The error occurs in different time each training, sometimes at start and sometimes later, but always when calling the forward method of the model:
`outputs = model(padded_batch_indexed_tokens, padded_batch_tags, sents_lengths)`


## Environment

Collecting environment information...
PyTorch version: 1.2.0
Is debug build: No
CUDA used to build PyTorch: 10.0.130

OS: CentOS Linux 7 (Core)
GCC version: (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
CMake version: version 2.8.12.2

Python version: 3.6
Is CUDA available: Yes
CUDA runtime version: Could not collect
GPU models and configuration: 
GPU 0: GeForce GTX 1080 Ti
GPU 1: GeForce GTX 1080 Ti
GPU 2: GeForce GTX 1080 Ti
GPU 3: GeForce GTX 1080 Ti

Nvidia driver version: 418.87.00
cuDNN version: Could not collect

Versions of relevant libraries:
[pip] msgpack-numpy==0.4.3.2
[pip] numpy==1.16.4
[pip] numpydoc==0.8.0
[pip] pytorch-transformers==1.1.0
[pip] torch==1.2.0
[conda] cuda80                    1.0                  h205658b_0    pytorch
[conda] mkl                       2019.3                      199  
[conda] pytorch                   1.2.0           py3.6_cuda10.0.130_cudnn7.6.2_0    pytorch
[conda] pytorch-transformers      1.1.0                    pypi_0    pypi
[conda] torch                     1.2.0                    pypi_0    pypi

## Additional context

Currently I am using try and except over the forward call, but I want to know what this bug means and why it is reproducing only on some training points.

Thanks in advance

cc @ezyang @gchanan @zou3519
Repository: TypeScript
Issue: Missing references for Lodash named imports
Labels: Bug,Domain: Refactorings

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.6.3

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

**Code**

```ts
// a.ts
import { negate } from 'lodash';

negate(() => true);
```

```ts
// b.ts
import { negate } from 'lodash';

negate(() => true);
```

Activate "find references" on `negate` in either file.

**Expected behavior:**

References in both `a.ts` and `b.ts` + definition are found.

**Actual behavior:**

References only in the current file + definition are found

![image](https://user-images.githubusercontent.com/921609/65138848-8a350b80-da03-11e9-82c3-0fba308a8aaa.png)


**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->

**Related Issues:** https://github.com/microsoft/TypeScript/issues/33017
Repository: storybook
Issue: Addon-docs: Resize iframe to fit content
Labels: feature request,help wanted,addon: docs,block: other

**Is your feature request related to a problem? Please describe.**
Sometimes the component being displayed in Docs is only a few px tall, yet the iframe defaults to 500px. When you have a lot of these stories stacked, there is a lot of empty space.

**Describe the solution you'd like**
After iframe loads, have it resize to fit the content

**Describe alternatives you've considered**
Can set styles to manually override the iframe height per-story, but this is difficult/tedious to maintain
Repository: svelte
Issue: A lot of empty text nodes - I mean A LOT - performance issue
Labels: feature request,awaiting submitter,perf,stale-bot

**Describe the bug**
Just check this repl https://svelte.dev/repl/902d4ccfcc5745d0b927b6db6be4f441?version=3.12.1

There are 22 000 empty text nodes that are really slowing down entire component on update.

![obraz](https://user-images.githubusercontent.com/25027696/65147220-fa508b00-da1d-11e9-9838-f9fd19eea8c5.png)


**Expected behavior**
I know that those nodes are for a reason but maybe some virtual approach will be better?
Each node must be created updated and destroyed which takes a lot of time and memory when something change.

**Severity**
This behavior can lead users to leave svelte because they might not figure out what is wrong - code seems to be ok, but performance is really bad (22 000 extra nodes for 2 500 real ones :O ).
For me this is annoying because I must be careful and watch for those "extra" nodes that are appearing randomly in some circumstances.
Repository: kubernetes
Issue: Migrate kube-controller-manager to use v1beta1 Events
Labels: kind/feature,sig/apps,sig/instrumentation,do-not-merge/hold,lifecycle/frozen

Now that new Events API is ready, we can migrate the kube-controller-manager to emit events against the new API.

This is part of #76674
Repository: create-react-app
Issue: webpack library configuration
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?
We want to use monorepo project and create-react-app, but we cant to create library with help of react-create-app.

### Describe the solution you'd like

Into `.env` file we can add `LIBRARY_NAME` and `LIBRARY_TARGET` configuration parameters and after that these are used to `webpack.config.js`

Example:
```
// file: create-react-app/packages/react-scripts/config/webpack.config.js
//...
output: {
  library: env.LIBRARY_NAME,
  libraryTarget: env.LIBRARY_TARGET
//...
```
Repository: rust
Issue: Suggest adding a generic lifetime parameter
Labels: C-enhancement,A-diagnostics,T-compiler,A-suggestion-diagnostics,D-papercut

```rust
fn foo(
    mut x: &(),
    y: &(),
) {
    x = y;
}
```
gives the error:
```
error[E0623]: lifetime mismatch
 --> src/lib.rs:5:9
  |
2 |     mut x: &(),
  |            ---
3 |     y: &(),
  |        --- these two types are declared with different lifetimes...
4 | ) {
5 |     x = y;
  |         ^ ...but data from `y` flows into `x` here
```
but does not suggest the solution: adding a new lifetime parameter `'a` to `foo` and giving both variables the same lifetime.
Repository: go
Issue: cmd/link: linker should fail quickly when external link mode is not supported
Labels: NeedsFix,compiler/runtime

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
HEAD
</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>
darwin, 386
</pre></details>

### What did you do?

While investigating Issue 33808 I discovered that external linking doesn't work in 32bit darwin.



### What did you expect to see?

Linker should fail quickly when trying to do an external link.

### What did you see instead?

Linker calls external linker, external linker fails.

CC @cherrymui
Repository: pytorch
Issue: Generated file not getting cleaned up by clean
Labels: module: build,triaged

When making changes that add new torch functions, and which should result in a change to the generated file `aten/src/ATen/core/OpsAlreadyMovedToC10.cpp`, we must build with GEN_TO_SOURCE=1 to regenerate the file with updated interfaces. `python setup.py clean` followed by `python setup.py install` does not cause the file to be regenerated.

Expected behavior is that clean should be enough to correctly fully re-build.
Repository: go
Issue: go/doc: lines ending with parenthesis cannot be headings
Labels: Thinking,NeedsDecision

What did you do?
Add a package doc like:

// ...
// Create a snapshot from a source table (snapshots alpha)
//
//     cbt createsnapshot \<cluster\> \<snapshot\> \<table\> [ttl=\<d\>]
// ...

What did you expect to see?
The string "Create a snapshot..." should be a title since it is delimited by blank lines, starts with and uppercase letter and does not end with an invalid punctuation.

What did you see instead?
It shows up as a regular text paragraph.
Can be seen here: https://godoc.org/google.golang.org/cloud/bigtable/cmd/cbt#hdr-Block_until_all_the_completed_writes_have_been_replicated_to_all_the_clusters

cc: @dmitshur
Repository: go
Issue: cmd/compile: output a DW_LNE_end_sequence instruction at the end of every function's line table
Labels: NeedsInvestigation,compiler/runtime

As we move DWARF generation out of the linker and into the compiler, we've taken some short cuts when emitting the line table. Specifically, rather than outputting a DW_LNE_end_sequence at the end of every function's debug_lines table, we reset the state machine. See discussion [HERE](https://go-review.googlesource.com/c/go/+/191968/6/src/cmd/link/internal/ld/dwarf.go#1112).

We are blocked on Delve supporting multiple DW_LNE_end_sequences per compilation unit. See Delve's issue [HERE](https://github.com/go-delve/delve/issues/1694).

In addition to making the state machine mechanics simpler, we can remove the assert in the linker that PCs are monotonically increasing per functions in a compilation unit. Again, see the [discussion](https://go-review.googlesource.com/c/go/+/191968/6/src/cmd/link/internal/ld/dwarf.go#1112).
Repository: opencv
Issue: MSER keypoints should be ellipses (which should be taken by descriptors like SIFT)
Labels: category: features2d,RFC

The invariance against perspective transformations is only valid, when MSER keypoints are extracted and described as ellipses. Internally they are also extracted as ellipses.

I see, there is such a ellipse-keypoint class in xfeatures2d, that or another solution should be used by MSER-Features and SIFT-Descriptors, and should be scaled carefully (different subsampling in ellipse axis) when used as descriptors. Perhaps it would be easier to make keypoints ellipses by default.
Repository: rust
Issue: Suggest giving recommending substitution based on naming conventions with available
Labels: C-enhancement,A-diagnostics,T-compiler,A-suggestion-diagnostics

New rustacean here. In writing simple programs to get a feel for the language, I tried testing if a string slice is empty as the conditional for a if/else statement. Something like the following:

    if mystr.empty() {
        // ...
    } else {
        // ...
    }

Of course the correct method is `.is_empty()`. I would suppose that this is a common mistake for people coming from languages like C++. It would be friendly of the compiler to recognize that in this boolean context there *is* a `.is_empty()` method that is the same name but with `is_` prepended, takes the provided (no) parameters, and returns the required boolean, and suggest that alternative to the user in the error output.
Repository: rust
Issue: Match ergonomics means bindings have different types in patterns and match arm; cannot deref references in pattern
Labels: C-enhancement,T-lang,A-patterns

Consider the following:
```rust
struct S(u32);

fn foo(x: &S) {
    let _: &u32 = match x {
        S(y) => y,
        _ => &0,
    };
}
```
Here, the variable binding `y` has type `&u32` outside the pattern. However, inside the pattern it has type `u32`. The fact that these types do not align is confusing, as it means you can't dereference `y` inside the pattern like this:
```rust
fn foo(x: &S) {
    let _: u32 = match x {
        S(&y) => y,
        _ => 0,
    };
}
```
and instead have to dereference it outside the pattern:
```rust
fn foo(x: &S) {
    let _: u32 = match x {
        S(y) => *y,
        _ => 0,
    };
}
```
Is there any reason this was chosen to be the case, or is required to be the case? As it stands, this behaviour is very counter-intuitive.