sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: `<Default>::default()` makes the compiler very mad at me
Labels: A-frontend,A-diagnostics,A-trait-system,T-compiler,C-feature-request,WG-diagnostics,D-verbose

Suppose I learned
- That `[f32; 2]::deserialize(deserializer)` doesn't work, and I need to do `<[f32; 2]>::deserialize(deserializer)` instead (thank you https://github.com/rust-lang/rust/pull/46788), and
- That I can do `Default::default()`, instead of `ConcreteType::default()`

If I combine those two things together and [try](https://play.rust-lang.org/?gist=0e860a077545909836dd4d0de6324ed4&version=nightly&mode=debug)

```rust
let x: u32 = <Default>::default();
```

Then I get this spew of errors:

```rust
error[E0277]: the trait bound `std::default::Default: std::default::Default` is not satisfied
 --> src/main.rs:2:18
  |
2 |     let x: u32 = <Default>::default();
  |                  ^^^^^^^^^^^^^^^^^^ the trait `std::default::Default` is not implemented for `std::default::Default`
  |
  = note: required by `std::default::Default::default`

error[E0038]: the trait `std::default::Default` cannot be made into an object
 --> src/main.rs:2:19
  |
2 |     let x: u32 = <Default>::default();
  |                   ^^^^^^^ the trait `std::default::Default` cannot be made into an object
  |
  = note: the trait cannot require that `Self : Sized`

error[E0308]: mismatched types
 --> src/main.rs:2:18
  |
2 |     let x: u32 = <Default>::default();
  |                  ^^^^^^^^^^^^^^^^^^^^ expected u32, found trait std::default::Default
  |
  = note: expected type `u32`
             found type `std::default::Default`

error[E0038]: the trait `std::default::Default` cannot be made into an object
 --> src/main.rs:2:18
  |
2 |     let x: u32 = <Default>::default();
  |                  ^^^^^^^^^^^^^^^^^^^^ the trait `std::default::Default` cannot be made into an object
  |
  = note: the trait cannot require that `Self : Sized`

error: aborting due to 4 previous errors

Some errors occurred: E0038, E0277, E0308.
For more information about an error, try `rustc --explain E0038`.
```

I don't know what I'm concretely asking for here (please retitle better), so here are some thoughts:

- The second error is the valuable one here
- "found trait std::default::Default" should perhaps be "found trait *object* std::default::Default"?
- Maybe this all will just work in Rust 2021 when `<Default>` can mean `Default`, not `dyn Default>`...
Repository: rust
Issue: Tracking issue for RFC 1872: `exhaustive_patterns` feature
Labels: T-lang,B-unstable,C-tracking-issue,A-patterns,A-exhaustiveness-checking,S-tracking-needs-summary,F-exhaustive_patterns

This tracks the `exhaustive_patterns` feature which allows uninhabited variant to be omitted 
(bug report: #12609; relevant RFC: rust-lang/rfcs#1872).

```rust
fn safe_unwrap<T>(x: Result<T, !>) -> T {
    match x {
        Ok(y) => y,
    }
}
```

- [x] Implementation (separated out from `never_type` in #47630)
- [x] blocking issue: https://github.com/rust-lang/rust/issues/117119
- [ ] Stabilization
Repository: opencv
Issue: Android OpenCV 3.4.1 - Cannot call stitching methods in JNI C++ methods
Labels: feature,category: java bindings,category: stitching

<!--
If you have a question rather than reporting a bug please go to http://answers.opencv.org where you get much faster responses.
If you need further assistance please read [How To Contribute](https://github.com/opencv/opencv/wiki/How_to_contribute).

This is a template helping you to create an issue which can be processed as quickly as possible. This is the bug reporting section for the OpenCV library.
-->

##### System information (version)

- OpenCV => 3.4.1
- Operating System / Platform => Android 

##### Detailed description

Android OpenCV 3.4.1 libopencv_java3.so doesn't have `stitching/stitcher` support/symbols compiled in.

More specifically, calling the Stitcher class makes the project not to compile as references to `cv::Stitcher` cannot be found.

##### Steps to reproduce

<!-- to add code example fence it with triple backticks and optional file extension
    ```.cpp
    // C++ code example
    ```
 or attach as .txt or .zip file
-->
This is my JNI 
```.cpp
JNIEXPORT void JNICALL Java_za_co_palota_opencvtest_MainActivity_incrementalStitch(JNIEnv *env, jobject instance, jlong stitchingFrameAddr, jlong additionalFrameAddr) {

        Mat &srcM = *(Mat *) stitchingFrameAddr;
        Mat &dstM = *(Mat *) additionalFrameAddr;

        vector<Mat> frames;

        frames.push_back(srcM);
        frames.push_back(dstM);

        Mat panorama;

        Ptr<Stitcher> stitcher = Stitcher::create(mode, try_use_gpu);
        Stitcher::Status status = stitcher->stitch(frames, panorama);
        
        if (status != Stitcher::OK)
        {
            LOGD("CV: STITCHING FAILED");
        } else {
            LOGD("CV: STITCHING SUCCESSFUL");
        }

    }
```

When building my android app I get these errors

```
/Users/.../app/src/main/cpp/native-lib.cpp:61: error: undefined reference to 'cv::Stitcher::create(cv::Stitcher::Mode, bool)'
/Users/.../app/src/main/cpp/native-lib.cpp:62: error: undefined reference to 'cv::Stitcher::stitch(cv::_InputArray const&, cv::_OutputArray const&)'
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
```

Upon further I looked at the symbols inside `libopencv_java3.so` (libopencv_java3.so comes straight from the latest package served from SourceForge - https://sourceforge.net/projects/opencvlibrary/files/opencv-android/3.4.1/) by running the following command:
```bash
nm -D libopencv_java3.so
```
When looking at the output I couldn't see references to any of the stitching methods.
Repository: rust
Issue: wasm32-unknown-unknown does not export $start.
Labels: O-wasm,C-bug

When compiling a binary crate to wasm using the `wasm32-unknown-unknown` target, a `$start` function is not inserted into the resulting wasm binary,

This is a continuation of https://github.com/rust-lang-nursery/rust-wasm/issues/108
Repository: electron
Issue: Extend DataTransfer object to support custom / native drag & drop formats
Labels: enhancement :sparkles:

**Is your feature request related to a problem? Please describe.**
My app needs the ability to send custom data formats via drag and drop to a legacy win32 application. Using the [datatransfer](https://developer.mozilla.org/en-US/docs/Web/API/DataTransfer/DataTransfer) object does not allow adding native custom formats. The [setData](https://developer.mozilla.org/en-US/docs/Web/API/DataTransfer/setData) function updates the "Chromium Web Custom MIME Data Format". 

**Describe the solution you'd like**
I would like the ability to add native data formats to the DataTransfer object with a new function such as setNativeData that accepts the format and a Buffer for the format payload. The new function would not interfere with the existing setData implemenation.

**Describe alternatives you've considered**
I've written a nodejs addon to support my needs when running in Win32. My addon is called during the HTML dragstart event and completely hijacks the chromium / electron drag / drop functionality. I really don't like this approach and would prefer a way to set the data formats and let chromium / electron do the drag & drop work. 

**Additional context**
N/A
Repository: youtube-dl
Issue: Add Site Support for addatimes
Labels: site-support-request

## Please follow the guide below

- You will be asked some questions and requested to provide some information, please read them **carefully** and answer honestly
- Put an `x` into all the boxes [ ] relevant to your *issue* (like this: `[x]`)
- Use the *Preview* tab to see what your issue will actually look like

---

### Make sure you are using the *latest* version: run `youtube-dl --version` and ensure your version is *2018.05.26*. If it's not, read [this FAQ entry](https://github.com/rg3/youtube-dl/blob/master/README.md#how-do-i-update-youtube-dl) and update. Issues with outdated version will be rejected.
- [x] I've **verified** and **I assure** that I'm running youtube-dl **2018.05.26**

### Before submitting an *issue* make sure you have:
- [x] At least skimmed through the [README](https://github.com/rg3/youtube-dl/blob/master/README.md), **most notably** the [FAQ](https://github.com/rg3/youtube-dl#faq) and [BUGS](https://github.com/rg3/youtube-dl#bugs) sections
- [x] [Searched](https://github.com/rg3/youtube-dl/search?type=Issues) the bugtracker for similar issues including closed ones
- [x] Checked that provided video/audio/playlist URLs (if any) are alive and playable in a browser

### What is the purpose of your *issue*?
- [ ] Bug report (encountered problems with youtube-dl)
- [x] Site support request (request for adding support for a new site)
- [ ] Feature request (request for a new functionality)
- [ ] Question
- [ ] Other

---

### The following sections concretize particular purposed issues, you can erase any section (the contents between triple ---) not applicable to your *issue*

---

### If the purpose of this *issue* is a *bug report*, *site support request* or you are not completely sure provide the full verbose output as follows:

Add the `-v` flag to **your command line** you run youtube-dl with (`youtube-dl -v <your command line>`), copy the **whole** output and insert it here. It should look similar to one below (replace it with **your** log inserted between triple ```):

```
```

---

### If the purpose of this *issue* is a *site support request* please provide all kinds of example URLs support for which should be included (replace following example URLs by **yours**):
Please add support for https://www.addatimes.com/
-example video: https://www.addatimes.com/show/virgin-mohito/episode-1

---

### Description of your *issue*, suggested solution and other information

Just simply login with google plus or facebook and u ll be able to see them 

My experiments: To get the details of the programme u need to use this type of URL
: https://www.addatimes.com/api/getVideo?video=episode-2&category=virgin-mohito&token="Token_Generated_By_Angular’s_XSRF"
It will be a great help if you can add this site support in youtube-dl.
Repository: neovim
Issue: build/cmake: consider Hunter (vcpkg, ?) for bundled dependencies
Labels: enhancement,build

[This thread](https://news.ycombinator.com/item?id=17163194) discusses CMake state-of-the-art. 

Currently we use `ExternalProject_Add` combined with our own recipes for building external projects. This obviously is painful to maintain because if an upstream project changes it may break our bundled-deps build when we bump our dependency version of that project.

Some recommend [hunter](https://github.com/cpp-pm/hunter) for pulling in external projects with CMake.

>  Hunter aims to be a full package manager, so it strives to build a project and all of its depedendencies recursively. This is fundamentally different than just adding one external project and ignoring the depedencies (what ExternalProject_Add does). The downside is this forces Hunter to maintain many forks of original repos just to keep track of the dependency information. 

[Quick introduction to Hunter](https://geokon-gh.github.io/hunterintro.html):

> * **Dependencies are built at configuration time:** Hunter will download the source and build all your dependencies during configuration time.
> * **Dependencies are built independently:** Each dependency is configured/built/installed independently and the only thing they inherit from the parent project is the toolchain file you passed in at the command line.
> * **Dependencies share their own dependencies:** If two dependencies need zlib then Hunter will install just one zlib and link both dependencies to it

# Evaluation

### conan

- conan is missing many of our deps (libtermkey, libuv at least)
- fast to install on Arch Linux (Python package)

### vcpkg 

- vcpkg appears to provide more deps, but still also misses libtermkey, libvterm at least.
- slow to install (only vcpkg-git in Arch, requires to be built)

### hunter

- hunter does not need to be installed really (via CMake)
- [min cmake version](https://hunter.readthedocs.io/en/latest/quick-start/cmake.html)
- also misses a lot of our deps, including LuaJIT: https://hunter.readthedocs.io/en/latest/packages.html

### nix

- ?
Repository: tensorflow
Issue: Prebuilt binaries do not work with CPUs that do not have AVX instruction sets.
Labels: stat:community support,type:feature

As announced in release notes, TensorFlow release binaries version 1.6 and higher are prebuilt with AVX instruction sets. This means on any CPU that do not have these instruction sets either CPU or GPU version of TF will fail to load with any of the following errors:

- `ImportError: DLL load failed:`
-  A crash with return code 132

Our recommendation is to build TF from sources on these systems.


### System information
- **Have I written custom code (as opposed to using a stock example script provided in TensorFlow)**: No
- **OS Platform and Distribution (e.g., Linux Ubuntu 16.04)**: ubuntu/windows/macos
- **TensorFlow installed from (source or binary)**: binary
- **TensorFlow version (use command below)**: 1.6 and up
- **Python version**:  2.7, 3.3, 3.4, 3.5, 3.6 and any newer
- **Bazel version (if compiling from source)**: n/a
- **GCC/Compiler version (if compiling from source)**: n/a
- **CUDA/cuDNN version**: any
- **GPU model and memory**: any
- **Exact command to reproduce**: python -c "import tensorflow as tf"
Repository: rust
Issue: Tracking issue for RFC 2294, "if let guard"
Labels: T-lang,B-unstable,B-RFC-implemented,C-tracking-issue,F-if_let_guard,S-tracking-impl-incomplete

This is a tracking issue for the RFC "if let guard" (rust-lang/rfcs#2294).

**Steps:**

- [x] Implement the RFC (implemented in #79051)
- [ ] Adjust documentation ([see instructions on forge][doc-guide])
- [ ] Stabilization PR ([see instructions on forge][stabilization-guide])

[stabilization-guide]: https://forge.rust-lang.org/stabilization-guide.html
[doc-guide]: https://forge.rust-lang.org/stabilization-guide.html#updating-documentation

**Unresolved questions:**

- [ ]  Work out the exact semantics / borrowck (cc @nikomatsakis, @pnkfelix)
  * [ ] Add unit tests analogous to the existing `if` guard ones that test `if let` guard instead
   * [ ] Ensure that the documentation of these details, if any, give equal footing to `if` and `if let` guards.
   * [ ] (If there is no documentation of `if` guards behavior w.r.t. move semantics, I do not think that should hold up stabilizing this feature. We can just file an issue that those things need to be documented.)
- [ ] pnkfelix: The fact that both this feature and `let else` were implemented but had problems discovered relatively late with their handling of certain details w.r.t. locals and temporary r-values is a hint that we may need to revisit our approach to testing features like this more broadly, in terms of how we advise implementors of such features on how to probe for such cases (and maybe also in the form of some kind of language-oriented test-generation tooling?)
Repository: pytorch
Issue: [feature request] batch_first of RNN hidden weight for Multi GPU training
Labels: module: nn,triaged,enhancement,module: data parallel

As we know, the input and output tensor support ```batch_first``` for RNN training, but as for hidden state, the tensor shape is forced to be ```(num_layers * num_directions, batch, hidden_size)```, even we set ```batch_first = True```. So there is a problem when we do multi GPU training by using ```torch.nn.DataParallel```. 

For example, if we initialize a hidden state with shape ```(num_layers * num_directions, batch, hidden_size)``` and set ```hidden = init_hidden(batch_size)``` like [word_language_model](https://github.com/pytorch/examples/blob/f9820471d615d848c14661b2d582417ca3aee8a3/word_language_model/main.py#L150)，then if we set ```hidden = init_hidden(batch_size)``` and use parallel training, the hidden size will be ```(num_layers * num_directions / num_gpu, batch, hidden_size)```  while the correct shape is ```(num_layers * num_directions, batch / num_gpu, hidden_size)```. So I was wondering if PyTorch Teams prepare to support ```batch_first``` for RNN hidden state.

Another possible way to avoid this problem is to use the following codes:
```
def init_hidden(self, batch_size):
    weight = next(self.parameters())
    # The hidden weight format is not consisten with PyTorch's LSTM
    # impelementation, so we will transpose it
    hidden = weight.new_zeros(batch_size, self.num_layers * 2,
                              self.hidden_size, requires_grad=False)
    hidden = [hidden, hidden]
    return hidden

def forward(self, inputs, hidden, length):
    hidden[0] = hidden[0].permute(1, 0, 2).contiguous()
    hidden[1] = hidden[1].permute(1, 0, 2).contiguous()
    inputs_pack = pack_padded_sequence(inputs, length, batch_first=True)
    # self.blstm.flatten_parameters()
    output, hidden = self.blstm(inputs_pack, hidden)
    ......
    hidden = list(hidden)
    hidden[0] = hidden[0].permute(1, 0, 2).contiguous()
    hidden[1] = hidden[1].permute(1, 0, 2).contiguous()
    return output, hidden
```

But this implementation is very ugly. Also, this implementation faces another problem like the following warning log:
```
/mnt/workspace/pytorch/deep_clustering/model/blstm_upit.py:65: UserWarning: RNN module weights are not part of single contiguous chunk of memory. This means they need to be compacted at every call, possibly greatly increasing memory usage. To compact weights again call flatten_parameters().
```
If we add ```self.blstm.flatten_parameters()``` before ```output, hidden = self.blstm(inputs_pack, hidden)```, we will face another problem like #7092 


cc @albanD @mruberry
Repository: rust
Issue: Defaulted unit types no longer error out (regression?)
Labels: T-compiler,regression-from-stable-to-stable,A-inference,C-bug

This currently compiles (on stable and nightly). Till 1.25, it would trigger a [lint](https://github.com/rust-lang/rust/issues/39216) because it has inference default to `()` instead of throwing an error.

```rust
fn main() {}

struct Err;
fn load<T: Default>() -> Result<T, Err> {
    Ok(T::default())
}
fn foo() -> Result<(), Err> {
    let val = load()?; // defaults to ()
    Ok(())
}
```

([playpen](https://play.rust-lang.org/?gist=6f7cf9dafb9d1651b659c1f029413fc5&version=nightly&mode=debug))


That lint indicates that it would become a hard error in the future, but it's not erroring. It seems like a bunch of this was changed when we [stabilized `!`](https://github.com/rust-lang/rust/issues/48950).

That issue says

> Type inference will now default unconstrained type variables to `!` instead of `()`. The [`resolve_trait_on_defaulted_unit`](https://github.com/rust-lang/rust/issues/39216) lint has been retired. An example of where this comes up is if you have something like:


Though this doesn't really _make sense_, this looks like a safe way to produce nevers, which should, in short, never happen. It seems like this is related to https://github.com/rust-lang/rust/issues/40801 -- but that was closed as it seems to be a more drastic change.

Also, if you print `val`, it's clear that the compiler thought it was a unit type. This seems like one of those cases where attempting to observe the situation changes it.




We _should_ have a hard error here, this looks like a footgun, and as @SimonSapin mentioned has broken some unsafe code already. We had an upgrade lint for the hard error and we'll need to reintroduce it for a cycle or two since we've had a release without it. AFAICT this is a less drastic change than #40801, and we seem to have _intended_ for this to be a hard error before so it probably is minor enough that it's fine.


cc @nikomatsakis @eddyb 

h/t @spacekookie for finding this
Repository: three.js
Issue: Add shadow map support for RectAreaLights (brainstorming, R&D)
Labels: Enhancement

##### Description of the problem

It would be very useful for realism to support shadows on RectAreaLights.

I am unsure of the best technique to use here as I have not researched it yet beyond some quick Google searches.  I am not yet sure what is the accepted best practice in the industry?

Two simple techniques I can think of:
- one could place a PointLightShadowMap at the center of a rect area light and it would sort of work.
- less accurate, one could place a SpotLightShadowMap with a fairly high FOV (upwards of 120 deg, but less than 180 deg as that would cause it to fail) at the center of the rect area light and point it in the light direction. 

(I believe with the spot light shadow map you may be able to get better results for large area lights if you moved the shadow map behind the area light surface so that the front near clip plane in the shadow map frustum was roughly the side of the area light as it passed through the area light plane.  I believe I read this in some paper once, but I can remember the source of it.)
Repository: rust
Issue: [rustdoc] Implementors section of Sync (and other similar traits) should separate implementors and !implementors
Labels: T-rustdoc,C-enhancement,E-mentor

![image](https://user-images.githubusercontent.com/772/40619532-6af752b4-6263-11e8-8627-2ae03dfe621d.png)

The `!Sync` implementations and the `Sync` implementations really ought to be separated apart, otherwise it makes it harder to skim.

https://doc.rust-lang.org/stable/std/marker/trait.Sync.html#implementors
Repository: rust
Issue: Borrowing an immutable reference of a mutable reference through a function call in a loop is not accepted
Labels: C-enhancement,T-lang,A-NLL,NLL-polonius

This code appears to be sound because `event` should either leave the loop or be thrown away before the next iteration:

```rust
#![feature(nll)]

fn next<'buf>(buffer: &'buf mut String) -> &'buf str {
    loop {
        let event = parse(buffer);

        if true {
            return event;
        }
    }
}

fn parse<'buf>(_buffer: &'buf mut String) -> &'buf str {
    unimplemented!()
}

fn main() {}
```

The current (1.28.0-nightly 2018-05-25 990d8aa743b1dda3cc0f) implementation still marks this as an error:

```
error[E0499]: cannot borrow `*buffer` as mutable more than once at a time
 --> src/main.rs:5:27
  |
5 |         let event = parse(buffer);
  |                           ^^^^^^ mutable borrow starts here in previous iteration of loop
  |
note: borrowed value must be valid for the lifetime 'buf as defined on the function body at 3:1...
 --> src/main.rs:3:1
  |
3 | fn next<'buf>(buffer: &'buf mut String) -> &'buf str {
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```

@nikomatsakis said:

>  this should throw an error (for now) but this error should eventually go away. This is precisely a case where "Location sensitivity" is needed, but we removed that feature in the name of performance — once polonius support lands, though, this code would be accepted. That may or may not be before the edition.
Repository: pytorch
Issue: Deprecate torch.Tensor
Labels: triaged,module: deprecation,module: tensor creation

This:
```python
>>> torch.Tensor(torch.tensor(0.5))
RuntimeError: slice() cannot be applied to a 0-dim tensor.
```
should work and be a no-op I guess?

I'm running pytorch CPU, built from source at fece8787d98c99177505c9357850171457397b61.