sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: cmake for Torch unusable in archlinux
Labels: module: dependency bug,module: build,triaged

## 🐛 Bug

When running the example of using libtorch with cmake, it errors about missing `libc10_cuda` during `find_library(Torch REQUIRED)`:

```
CMake Error at /usr/lib64/cmake/Caffe2/Caffe2Targets.cmake:107 (message):
  The imported target "c10_cuda" references the file

     "/usr/lib/libc10_cuda.so"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

     "/usr/lib64/cmake/Caffe2/Caffe2Targets.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  /usr/lib64/cmake/Caffe2/Caffe2Config.cmake:116 (include)
  /usr/lib64/cmake/Torch/TorchConfig.cmake:39 (find_package)
  CMakeLists.txt:4 (find_package)


-- Configuring incomplete, errors occurred!
```

It tries to find it under `/usr/lib`, but arch's package manager installs it to `/usr/lib/pytorch`. So it's either the packager didn't install it to the correct place, or the  `Caffe2Targets.cmake` file not rigorous enough about ELF location.

What's your thought on this? Is it proper to modify `Caffe2Targets.cmake` so it can find the lib correctly under this circumstance, or at least provides a variable or something to workaround this please.


## To Reproduce
```cmake
cmake_minimum_required(VERSION 3.0 FATAL_ERROR)
project(custom_ops)


find_package(Torch REQUIRED)

add_executable(test test.cc)
# target_link_libraries(test "-L/usr/lib/pytorch -lc10 -lc10_cuda -lcaffe2 -lmklml_intel -ltorch -lshm -L/opt/cuda/targets/x86_64-linux/lib -lnvrtc -lcuda")
target_link_libraries(test "${TORCH_LIBRARIES}")
set_property(TARGET test PROPERTY CXX_STANDARD 11)

```

```
cmake ..
```

## Environment

PyTorch version: 1.0.1
Is debug build: No
CUDA used to build PyTorch: 10.1.105

OS: Arch Linux
GCC version: (GCC) 8.3.0
CMake version: version 3.14.4

Python version: 3.7
Is CUDA available: Yes
CUDA runtime version: 10.1.168
GPU models and configuration: GPU 0: GeForce GTX 1060 6GB
Nvidia driver version: 430.14
cuDNN version: /usr/lib/libcudnn.so.7.5.1

Versions of relevant libraries:
[pip3] numpy==1.16.3
[pip3] torch==1.0.1
[pip3] torchvision==0.2.2.post3
[conda] Could not collect


## Additional context
the package I install is named "python-pytorch-cuda" under arch.
Repository: electron
Issue: Feature Request: continuity camera for macOS app
Labels: enhancement :sparkles:,platform/macOS

### Preflight Checklist
<!-- Please ensure you've completed the following steps by replacing [ ] with [x]-->

* [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
* [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
* [x] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

### Problem Description
I want paste photo from my iPhone camera in my application. This feature implemented in macOS Mojave.
<img width="402" alt="Screenshot 2019-05-21 at 17 12 49" src="https://user-images.githubusercontent.com/9060043/58103681-12d5a380-7bec-11e9-80e7-da58150ad690.png">

### Proposed Solution
Add method for opening camera in my iPhone and returning image

### Alternatives Considered
None

### Additional Information
[Doc](https://developer.apple.com/documentation/appkit/supporting_continuity_camera_in_your_mac_app) for Xcode
Repository: vue-element-admin
Issue: 安装过程出现问题
Labels: enhancement :star:

<!--
    注意：为更好的解决你的问题，请参考模板提供完整信息，准确描述问题，信息不全的 issue 将被关闭。

    Note: In order to better solve your problem, please refer to the template to provide complete information, accurately describe the problem, and the incomplete information issue will be closed.
-->


## Bug report（问题描述）
npm install安装出现问题
yarn安装出现问题

#### Steps to reproduce（问题复现步骤）
先使用npm install安装失败
见图1
使用yarn安装出现一个warn警告，提示jsonlint包不再维护安装失败。
见图2
讲jsonlint从package.json删除，依旧安装失败
见图3
将yarn的registry换成淘宝源再次安装依旧失败见
图2
最后使用万恶的cnpm安装成功。。。
见图4

#### Screenshot or Gif（截图或动态图）
1.
![图片](https://user-images.githubusercontent.com/21995899/58103942-77a5f380-7c16-11e9-9943-875c22ba38eb.png)
2.
![图片](https://user-images.githubusercontent.com/21995899/58103350-67d9df80-7c15-11e9-8262-487487722adc.png)
3.
![图片](https://user-images.githubusercontent.com/21995899/58103604-d5860b80-7c15-11e9-8693-58507c45f611.png)
4.
![图片](https://user-images.githubusercontent.com/21995899/58103651-ea629f00-7c15-11e9-8869-5fe5b4a3d89a.png)


#### Link to minimal reproduction（最小可在线还原demo）

<!--
Please only use Codepen, JSFiddle, CodeSandbox or a github repo
-->

#### Other relevant information（格外信息）
- Your OS:windows朋友的mac也是一样
- Node.js version:10.13.0
- vue-element-admin version:4.2.0
Repository: TypeScript
Issue: Optional arguments in JSDoc types may be moved to TypeScript types quickfix
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. 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.4.3

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->

- `80004`
- `jsdoc quickfix optional`

**Code**

With Closure Compiler, you mark a function parameter optional by adding an `=` after its type ([reference][2]):

```ts
/**
 * @param a {string} Base string.
 * @param b {string=} Optional string to add
 * @return {string}
 */
function foo(a, b) {
  if (b) return a + b;
  return a;
}
```

TypeScript offers a quickfix to convert these jsdoc annotations to TypeScript types:

![image](https://user-images.githubusercontent.com/98301/58105685-e488a180-7bb4-11e9-8cea-61111db9921b.png)

**Expected behavior:**

The `b` parameter should be optional:

```ts
/**
 * @param a {string} Base string.
 * @param b {string=} Optional string to add
 * @return {string}
 */
function foo(a: string, b?: string): string {
  if (b) return a + b;
  return a;
}
```

**Actual behavior:**

The `b` parameter is required but has type `string | optional`:

```ts
/**
 * @param a {string} Base string.
 * @param b {string=} Optional string to add
 * @return {string}
 */
function foo(a: string, b: string | undefined): string {
  if (b) return a + b;
  return a;
}
```

This means that all calls of the function which don't specify `b` will be flagged as errors.

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior --> [link][1], though quickfixes are not available there

**Related Issues:** <!-- Did you find other bugs that looked similar? -->

[1]: http://www.typescriptlang.org/play/#src=%2F**%0D%0A%20*%20%40param%20a%20%7Bstring%7D%20Base%20string.%0D%0A%20*%20%40param%20b%20%7Bstring%3D%7D%20Optional%20string%20to%20add%0D%0A%20*%20%40return%20%7Bstring%7D%0D%0A%20*%2F%0D%0Afunction%20foo(a%2C%20b)%20%7B%0D%0A%20%20if%20(b)%20return%20a%20%2B%20b%3B%0D%0A%20%20return%20a%3B%0D%0A%7D%0D%0A
[2]: https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#optional-parameter-in-a-param-annotation
Repository: TypeScript
Issue: Move types from jsdoc quickfix (instead of copy)
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

- `jsdoc quickfix`
- 80004

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

## Suggestion

There's a great quickfix available to copy JSDoc type annotations to TypeScript annotations:

![image](https://user-images.githubusercontent.com/98301/58105685-e488a180-7bb4-11e9-8cea-61111db9921b.png)

When you do this, however, you still have type annotations in your JSDoc. This is duplicative and is likely to lead to the types getting out of sync over time. It's best to avoid putting type information in JSDoc once you're using TypeScript.

I'd like a quickfix that annotates types _and_ removes the types from the JSDoc.

<!-- A summary of what you'd like to see added or changed -->

## Use Cases

<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->

This would be helpful for any project converting from JavaScript to TypeScript. You should convert your JSDoc types to TypeScript types and you should remove types from your JSDoc once you do. This sort of quickfix would help people get to the right place.

## Examples

<!-- Show how this would be used and what the behavior would be -->

```ts
/**
 * @param a {string} Base string.
 * @param b {string=} Optional string to add
 * @return {string}
 */
function foo(a, b) {
  if (b) return a + b;
  return a;
}
```

should get converted to:

```ts
/**
 * @param a Base string.
 * @param b Optional string to add
 */
function foo(a: string, b?: string): string {
  if (b) return a + b;
  return a;
}
```

rather than:

```ts
/**
 * @param a {string} Base string.
 * @param b {string=} Optional string to add
 * @return {string}
 */
function foo(a: string, b: string | undefined): string {
  if (b) return a + b;
  return a;
}
```

## 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: flutter
Issue: CupertinoSliverNavigationBar and CupertinoNavigationBar leading and trailing are always CupertinoColors.activeBlue during transition
Labels: waiting for customer response,framework,f: cupertino,c: proposal,P2,team-design,triaged-design

## Use case
2 Widgets: 

1. One with a `CupertinoSliverNavigationBar` inside `CustomScrollView` 
2. the second with a `CupertinoNavigationBar` at the top.
3. 
4. Set the `CupertinoTheme`'s data's `brightness` to `Brightness.dark`.
5. 
6. Push Widget 2 onto the stack. 
7. Widget 2 has an **orange leading back arrow** icon.
8. Pop Widget 2 from the stack: **During the transition the back arrow is blue**.

## Proposal
Maintain the color of the leading and trailing during transition.
Repository: TypeScript
Issue: Support Closure Compiler-style @typedef 
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

- Closure Compiler typedef

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

## Suggestion

With Closure Compiler-style JSDoc, you name an `@typedef` type definition by introducing a `var` in the next statement:

```ts
/** @typedef {(string|number)} */
var NumberLike;
```

TypeScript doesn't recognize this construct. Instead, it wants you to write:

```ts
/** @typedef {(string|number)} NumberLike */
```

## Use Cases

Migrating code written for use with Google's Closure Compiler over to TypeScript.

<!--
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 -->

See above. My proposal is that, when prefixed with an `@typedef` with only a type (and no name), a variable definition would create a symbol in the type namespace in addition to the value namespace.

## Checklist

My suggestion meets these guidelines:

* [ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
    → If the variable has the same name as an existing type, this would create a break. But this would indicate an issue if the two types disagreed.
* [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).

[1]: https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#typedef-type
Repository: TypeScript
Issue: Quick fix to convert @typedef to type or interface
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

- `typedef quickfix`
- `typedef jsdoc`

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

## Suggestion

I have lots of code in an old Closure Compiler-style project that looks like this:

```ts
/**
 * @typedef {{
 *   px: number,
 *   py: number,
 *   isZooming: boolean,
 *   isPanning: boolean,
 *   is2DPan: boolean,
 *   cancelNextDblclick: boolean,
 *   initializeMouseDown: (e: !Event, dygraph:!DygraphAny, context: !DygraphInteractionContext) => void
 * }} DygraphInteractionContext
 */
```

If I declare a variable with this type, I can see that TypeScript understands the `@typedef`:

```ts
type DygraphInteractionContext = {
    px: number;
    py: number;
    isZooming: boolean;
    isPanning: boolean;
    is2DPan: boolean;
    cancelNextDblclick: boolean;
    initializeMouseDown: (e: Event, dygraph: any, context: ...) => void;
}
```

I'd like to convert this to a `type` or `interface`. I can introduce a dummy variable, copy the TS-style `type` declaration and paste it in to do the conversion.

But it'd be easier if there were a quickfix!

## Use Cases

<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->

Migrating a project that used JSDoc-based typing. A workaround is available, but a quickfix would be a big improvement.

## Examples

<!-- Show how this would be used and what the behavior would be -->

(see above)

## 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: vscode
Issue: [css] Wrong selector specificity values with :nth-child(even) and :nth-child(odd)
Labels: bug,css-less-scss

Issue Type: <b>Bug</b>

In CSS files :
It seems like `odd` and `even` keywords count as element selectors.

`div:nth-child(odd){...}`

indicates

`<div :nth-child>`
`Selector Specificity: (0, 1, 2)`

Specificity should be `Selector Specificity: (0, 1, 1)`

VS Code version: Code 1.33.1 (51b0b28134d51361cf996d2f0a1c698247aeabd8, 2019-04-11T08:27:14.102Z)
OS version: Windows_NT x64 10.0.17763

Extensions: none
<!-- generated by issue reporter -->
Repository: rust
Issue: There should be a way to unwrap MaybeUninits without moving them
Labels: T-libs-api,C-feature-request

[`MaybeUninit`](https://doc.rust-lang.org/nightly/std/mem/union.MaybeUninit.html) has an API where you construct a `MaybeUninit<T>`, can operate on it via raw pointer methods, and then can call [`assume_init()`](https://doc.rust-lang.org/nightly/std/mem/union.MaybeUninit.html#method.assume_init) to move the inner value out. It also has methods that let you assume that it is initialized and obtain safe Rust references.

This is great for temporary initialization on the stack, but this doesn't work so well for the heap. What if you need to gradually initialize `Vec<T>` or `Arc<T>` heap values? This ends up leaving a carcass of a `MaybeUninit` in the type forever, basically infecting the type with an unsafe abstraction from the time of its initialization.


One solution here is to make sure `MaybeUninit` and `ManuallyDrop` have a repr of `T` (basically, `repr(transparent)`, except we haven't defined that for unions) so that you can always transmute `&MaybeUninit<T>` to `&T`, or `Arc<MaybeUninit<T>>` into `Arc<T>`.

The fact that `MaybeUninit` has methods specifically for doing this kind of thing with slices seems to point to the need for this ability to be generalized.

Either way we should have clear documentation for using `MaybeUninit` with values not on your stack (on the heap, or passed in as a reference). Ideally we allow you to transmute it in such cases (and have examples doing this), but if we can't, we should still document that you shouldn't use it that way. (I think that this choice would preclude a lot of legitimate and necessary use cases, especially in FFI)

cc @eddyb @RalfJung
Repository: TypeScript
Issue: ServiceWorkerRegistration.Update() should return Promise<ServiceWorkerRegistration>
Labels: Bug,Domain: lib.d.ts

**TypeScript Version:**  3.4.3

**Search Terms:**
ServiceWorkerRegistration Update

**Code**

```ts
// A *self-contained* demonstration of the problem follows...
// Test this by running `tsc` on the command-line, rather than through another build tool such as Gulp, Webpack, etc.
let isUpdating: boolean;
navigator.serviceWorker.getRegistration().then(sw => {
    sw.update().then(result => {
        if (result.installing || result.waiting) {
            isUpdating = true;
        }
    });
});
```

**Expected behavior:**
`result` is of type `ServiceWorkerRegistration` and `result.installing` and `result.waiting` are valid.
https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerRegistration/update

**Actual behavior:**
`result` is of type void and tsc gives errors
`error TS2339: Property 'installing' does not exist on type 'void'.`
`error TS2339: Property 'waiting' does not exist on type 'void'.`

[**Playground Link**](https://www.typescriptlang.org/play/#src=let%20isUpdating%3A%20boolean%3B%0D%0Anavigator.serviceWorker.getRegistration().then(sw%20%3D%3E%20%7B%0D%0A%20%20%20%20sw.update().then(result%20%3D%3E%20%7B%0D%0A%20%20%20%20%20%20%20%20if%20(result.installing%20%7C%7C%20result.waiting)%20%7B%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20isUpdating%20%3D%20true%3B%0D%0A%20%20%20%20%20%20%20%20%7D%0D%0A%20%20%20%20%7D)%3B%0D%0A%7D)%3B%0D%0A)

**Related Issues:**
https://github.com/microsoft/TypeScript/issues/17590
Repository: youtube-dl
Issue: Add an option to change the extension of description file
Labels: request

<!--

######################################################################
  WARNING!
  IGNORING THE FOLLOWING TEMPLATE WILL RESULT IN ISSUE CLOSED AS INCOMPLETE
######################################################################

-->


## Checklist

<!--
Carefully read and work through this check list in order to prevent the most common mistakes and misuse of youtube-dl:
- First of, make sure you are using the latest version of youtube-dl. Run `youtube-dl --version` and ensure your version is 2019.05.20. If it's not, see https://yt-dl.org/update on how to update. Issues with outdated version will be REJECTED.
- Search the bugtracker for similar feature requests: http://yt-dl.org/search-issues. DO NOT post duplicates.
- Finally, put x into all relevant boxes (like this [x])
-->

- [X] I'm reporting a feature request
- [X] I've verified that I'm running youtube-dl version **2019.05.20**
- [X] I've searched the bugtracker for similar feature requests including closed ones


## Description

<!--
Provide an explanation of your issue in an arbitrary form. Please make sure the description is worded well enough to be understood, see https://github.com/ytdl-org/youtube-dl#is-the-description-of-the-issue-itself-sufficient. Provide any additional information, suggested solution and as much context and examples as possible.
-->

By default `.description` is used, but since this isn't a standard extension, many file managers will not know how to open it. I'd prefer to change it to use `.txt`.
Repository: TypeScript
Issue: Quick Fix: Infer parameter types from usage … for one function
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

- 7043
- 7044
- `better type may be inferred from usage`

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

## Suggestion

There's a quickfix to infer types from usage for variables that are implicitly `any`:

![image](https://user-images.githubusercontent.com/98301/58115842-f3794f00-7bc8-11e9-9d61-60f832501229.png)

The two options are both useful, but for a large file the "Infer all types from usage" option feels a bit extreme. But inferring symbol-by-symbol can get tedious.

I'm proposing a middle ground option, something like "Infer all types in this block."

<!-- A summary of what you'd like to see added or changed -->

## Use Cases

Adding type annotations to variables in large files based on usage piecemeal.

<!--
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).