sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Wrong use closure help for const generics
Labels: C-enhancement,A-diagnostics,T-compiler

This is wrong code:
```rust
#![feature(const_generics)]
#![allow(incomplete_features)]
fn main() {
    let x = 2;
    fn foo<const Y: u32>() -> u32 {
        x + Y
    }
    let _ = foo();
}
```
I think it gives a wrong suggestion because closure generics aren't allowed yet:
```
error[E0434]: can't capture dynamic environment in a fn item
 --> ...\test.rs:6:9
  |
6 |         x + Y
  |         ^
  |
  = help: use the `|| { ... }` closure form instead

error: aborting due to previous error
```
Using: `rustc 1.45.0-nightly (5239f5c57 2020-05-26)`
Repository: pytorch
Issue: Failure when loading quantized pre-trained weights partially
Labels: oncall: quantization,low priority,triaged

Hi, 

I have the weights of a model that was pre-trained with Quantization-Aware Training. What I want to do is to load them in another model that contains an additional layer with respect to the pre-trained one. Usually I would call `load_state_dict()` with `strict=False` as argument and it would try to load only the parameters that are present in the given checkpoint (leaving the other ones as default), but in the case of a quantized pre-trained model this doesn't work because the two lines below try to pull the zero_point and scale factors from the given checkpoint even when `strict=False` and the given checkpoint doesn't contain the weights for all layers of the new model. 

https://github.com/pytorch/pytorch/blob/9b95f757afd34857ffd83d55060328f5f35a7daf/torch/nn/quantized/modules/functional_modules.py#L126-L127

I think that the `_load_from_state_dict()` function in the `QFunctional` class should try to pop those two values only if the `strict` argument is `True` and the given `state_dict` contains those parameters

cc @jerryzh168 @jianyuh @raghuramank100 @jamesr66a @vkuzo @jgong5 @Xia-Weiwen @leslie-fang-intel @dzhulgakov
Repository: TypeScript
Issue: Narrow typeof x === 'object' to Record<string | number | symbol, unknown> | null | unknown[]
Labels: Suggestion,Awaiting More Feedback

## Search Terms
typeof object narrow record

## Suggestion
When narrowing a variable with `typeof x === 'object'`, narrow to `Record<string | number | symbol, unknown> | null | unknown[]` instead of `object | null`.

## Use Cases
When testing to see if something is an object, you almost always are starting out with `unknown` or similarly near-top level type and trying to narrow down to a lower "useful" type.  When you use the `typeof x === 'object'` narrowing operation, currently TypeScript *over* narrows to the extremely constrained `{} | null` type.  This suggestion would change that behavior to narrow down to the much wider `Record<string | number | symbol, unknown> | null | unknown[]`, which the user can then choose to narrow more if they like, or they can choose to work with it as-is.

## Examples
```ts
declare const apple: unknown
if (typeof apple !== 'object') throw new Error() // actual: object | null; desired: Record<string|number|symbol, unknown> | null | unknown[]

// uncomment this line and comment out the lines above to see desired behavior
// declare const apple: Record<string|number|symbol, unknown> | null | unknown[]

if (apple === null) throw new Error() // actual: object; desired: Record<string|number|symbol, unknown> | unknown[]
if (Array.isArray(apple)) throw new Error() // actual: object; desired: Record<string|number|symbol, unknown>
for (const key in apple) {
    // Element implicitly has an 'any' type because expression of type 'string' can't be used to index type '{}'.
    //   No index signature with a parameter of type 'string' was found on type '{}'.
    apple[key] // actual: error; desired: unknown
}
```

## 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: image_picker has noticable shutter delay in capturing Image from camera
Labels: e: device-specific,platform-android,p: image_picker,package,has reproducible steps,P2,found in release: 3.10,found in release: 3.11,team-android,triaged-android


I am working on image_picker 0.6.6+4 

While using Image source as camera and capturing the image using stock camera, there is a noticable shutter delay of about 2-3 sec. There is no delay using the Stock camera directly.

Device used - Redmi K20 Pro
OS version - MIUI 12 Android 10

Tried it on other devices as well.

```[√] Flutter (Channel stable, v1.17.1, on Microsoft Windows [Version 10.0.18363.836], locale en-IN)
    • Flutter version 1.17.1 at C:\Flutter\flutter
    • Framework revision f7a6a7906b (2 weeks ago), 2020-05-12 18:39:00 -0700
    • Engine revision 6bc433c6b6
    • Dart version 2.8.2


[√] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
    • Android SDK at C:\Users\Prasad\AppData\Local\Android\sdk
    • Platform android-29, build-tools 29.0.3
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 1.8.0_212-release-1586-b04)
    • All Android licenses accepted.

[√] Android Studio (version 3.6)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin version 45.1.1
    • Dart plugin version 192.8052
    • Java version OpenJDK Runtime Environment (build 1.8.0_212-release-1586-b04)

[√] Connected device (2 available)
    • Redmi Note 7 Pro • bd96c4d3           • android-arm64 • Android 10 (API 29)
    • Redmi K20 Pro    • 192.168.1.110:5555 • android-arm64 • Android 10 (API 29)

• No issues found!
```
Repository: pytorch
Issue: Some @slowtests are never run in CI
Labels: high priority,module: tests,triaged,quansight-nack

https://github.com/pytorch/pytorch/issues/39060, for example, which is broken.

See output of of our one slow test build (master only) here: https://circleci.com/api/v1.1/project/github/pytorch/pytorch/5584582/output/106/0?file=true&allocation-id=5ece29ff9a720f435538c71f-0-build%2F1426355C. 

cc @ezyang @gchanan @zou3519 @bdhirsh @heitorschueroff @mruberry @VitalyFedyunin
Repository: TypeScript
Issue: Suggestion: treat readonly static members of class as namespace members
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

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

static member; namespace; type

Maybe related issues: https://github.com/microsoft/TypeScript/issues/38207

## Suggestion
Readonly static members of class should act like namespace members. Especially, when that member is assigned as an alias of enumeration or other class.

## Use Cases

With the suggestion,
```ts
enum Color { red, }
class Image {
    public static readonly Color = Color; // Marked as readonly, so tsc can ensure it's an alias
}
```

The `Image.Color` should be an alias of enumeration `Color`. So we can use it when an enumeration may be used:
```ts
console.log(Image.Color.red); // OK
function f(color: Image.Color) { // OK: used as type #1
    if (color === Image.Color.red){ /* ... */ }
}
```
`#1` is invalid for now because tsc does not treat `Image.Color` as a type.
To use `Image.Color` as a type, we may supply a verbose declaration according to the declaration merging rule of TypeScript:
```ts
namespace Image {
    export type Color = (typeof Color)[keyof typeof Color]; // :(
}
```
It's verbose...
<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->

## Examples

Sometimes we want to embed enumerations, classes into other classes. Because we don't want directly expose that enumueration/class into module scope.

## 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: Obfuscation : Support excluding certain classes and types from obfuscation
Labels: c: new feature,tool,dependency: dart,c: proposal,a: build,P3,team-tool,triaged-tool

There are many times where me might have used `toString` method on `enums` and many places where we might wanna keep the Type information after obfuscation.

There is a need to support excluding certain Types or classes from obfuscation.

When we build the apk through : 

```flutter build apk --obfuscate --split-debug-info```
Repository: go
Issue: proposal: crypto/tls: RFC 7685 support (ClientHello "padding(21)")
Labels: Proposal,NeedsInvestigation,Proposal-Crypto

Unfortunately, there are TLS servers that refuse (and hang upon) ClientHello messages of sizes in the range 256-512 bytes, causing TLS handshake timeouts. RFC 7685 lets clients mitigate this by adding padding bytes to the ClientHello messages, so clients can adjust the ClientHello sizes at will as a workaround. 

https://tools.ietf.org/html/rfc7685#section-1 reads:

>    Successive TLS [RFC5246] versions have added support for more cipher
   suites and, over time, more TLS extensions have been defined.  This
   has caused the size of the TLS ClientHello to grow, and the
   additional size has caused some implementation bugs to come to light.
   At least one of these implementation bugs can be ameliorated by
   making the ClientHello even larger.  This is desirable given that
   fully comprehensive patching of affected implementations is difficult
   to achieve.
   This memo describes a TLS extension that can be used to pad a
   ClientHello to a desired size in order to avoid implementation bugs
   caused by certain ClientHello sizes.

And here's a description of a buggy server implementation:
https://mailarchive.ietf.org/arch/msg/tls/8wXwhM1d5WSmROHFSgrTyFmWN2o/

Adding support for this extension would let users workaround these buggy server implementations.
Repository: opencv
Issue: GPU implementation of SGBM
Labels: category: calib3d,category: features2d,category: gpu/cuda (contrib)

##### System information (version)
<!-- Example
- OpenCV => 4.2
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2017
-->

- OpenCV => :grey_question:
- Operating System / Platform => :grey_question:
- Compiler => :grey_question:

##### Detailed description

<!-- your description -->

##### 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
-->

##### Issue submission checklist

 - [ ] I report the issue, it's not a question
   <!--
   OpenCV team works with answers.opencv.org, Stack Overflow and other communities
   to discuss problems. Tickets with question without real issue statement will be
   closed.
   -->
 - [ ] I checked the problem with documentation, FAQ, open issues,
       answers.opencv.org, Stack Overflow, etc and have not found solution
   <!--
   Places to check:
   * OpenCV documentation: https://docs.opencv.org
   * FAQ page: https://github.com/opencv/opencv/wiki/FAQ
   * OpenCV forum: https://answers.opencv.org
   * OpenCV issue tracker: https://github.com/opencv/opencv/issues?q=is%3Aissue
   * Stack Overflow branch: https://stackoverflow.com/questions/tagged/opencv
   -->
 - [ ] I updated to latest OpenCV version and the issue is still there
   <!--
   master branch for OpenCV 4.x and 3.4 branch for OpenCV 3.x releases.
   OpenCV team supports only latest release for each branch.
   The ticket is closed, if the problem is not reproduced with modern version.
   -->
 - [ ] There is reproducer code and related data files: videos, images, onnx, etc
   <!--
   The best reproducer -- test case for OpenCV that we can add to the library.
   Recommendations for media files and binary files:
   * Try to reproduce the issue with images and videos in opencv_extra repository
     to reduce attachment size
   * Use PNG for images, if you report some CV related bug, but not image reader
     issue
   * Attach the image as archite to the ticket, if you report some reader issue.
     Image hosting services compress images and it breaks the repro code.
   * Provide ONNX file for some public model or ONNX file with with random weights,
     if you report ONNX parsing or handling issue. Architecture details diagram
     from netron tool can be very useful too. See https://lutzroeder.github.io/netron/
   -->
I wanted to know if there is any specific reason behind not implementing a gpu accelerated version of sgbm.
Thank you in advance
Repository: rust
Issue: Creating a macro of generating closure, description of arguments to closure in || with a star only works as an exclamation point.
Labels: A-grammar,A-parser,A-macros,T-lang,T-compiler,C-feature-request

It was expected that I could repeat the syntax of the closure in the macro, I repeated but the rule is not working out correctly.

**Code:** 
```rust
macro_rules! test {
    [ | $($args:ident),* | $($block:tt)* ] => {
        | $($args),* | $($block)*
    };
}

fn main() {
    let enc = &test! {
        |a| {
            println!("1");
        }
    } as &'static dyn FnMut(usize);
    
    let enc2 = &test! {
        || {
            println!("2");
        }
    } as &'static dyn FnMut();
}
```

**Output:**
```rust
error: no rules expected the token `||`
  --> src/main.rs:16:9
   |
2  | macro_rules! test {
   | ----------------- when calling this macro
...
16 |         || {
   |         ^^ no rules expected this token in macro call
```

Macro code using one or more elements works, but macro code without elements does not work. Although this is precisely the rule with the star.

**Play:** https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=bd27f49b9feeb021af76615321013784

**Rust Version:** stable 1.43.1 or rustc 1.45.0-nightly (a74d1862d 2020-05-14)
Repository: pytorch
Issue: Add cpack support to CMakeLists.txt
Labels: module: build,module: cpp,triaged

## 🚀 Feature
Add cpack support for creating prepackaged builds of libtorch

## Motivation
Due to https://github.com/pytorch/pytorch/issues/14573 I need to compile libtorch from source and link against system protobuf.  libtorch is installed as part of a CI pipeline and rather than build it from source each time, I would like to be able to point to a prebuilt `.deb` package to install.

## Pitch
Add [the few lines](https://gitlab.kitware.com/cmake/community/-/wikis/doc/cpack/Packaging-With-CPack) it would it take to support cpack



cc @malfet @yf225 @glaringlee
Repository: godot
Issue: trouble reproducing colors of the imported albedo texture correctly
Labels: topic:import

**Godot version:**
3.2.1
**OS/device including version:**
Windows 10 64bit

**Issue description:**

Hello,

I'm having trouble reproducing the colors of the imported texture correctly.
Godot is probably acting illogical in this case.

The file is PNG, 8 bits.

My problem on pictures:

http://beetbeet.eu/images/godot/colors/texture-colors-problem.jpg
![image](https://user-images.githubusercontent.com/8281454/83030010-4e604480-a06e-11ea-87c4-26a1cf448069.png)

Oryginal texture file:

http://beetbeet.eu/images/godot/colors/texture.png
<img src="https://user-images.githubusercontent.com/8281454/83030063-5c15ca00-a06e-11ea-8e74-a71083a7cf8b.png" width="300" />

**Steps to reproduce:**
STEP 1: After starting the scene, the texture on the 3d object has lighter colors than it should have.
The colors are faded.

On the left side you can see in browser what texture has original colors.

STEP 2: With the scene still running, if I click Albedo Tex Force Srgb, then the colors in the running game window are correct.

This would seem to mean that I should have this option enabled on this material.

STEP 3: So I give a stop playing and with this option checked Albedo Tex Force Srgb I restart the game.

Unfortunately now the texture colors look completely different than in the two previous cases.
Now the colors are too dark.

What am I doing wrong that I cannot achieve the original colors of this texture permanently?
Repository: node
Issue: doc: <integer> is misleading
Labels: doc,meta

# 📗 API Reference Docs Problem

<!------------------------------------------------------------------------------
Thank you for wanting to make nodejs.org better!

This template is for issues with the Node.js API reference docs.

For more general support, please open an issue in
our help repo at “https://github.com/nodejs/help”.

For the issue title, enter a one-line summary after “doc: ”.
The “✍️” signifies a request for input. If unsure, do the best you can.

If you found a problem with nodejs.org beyond the API reference docs, please
open an issue in our website repo at “https://github.com/nodejs/nodejs.org”.
------------------------------------------------------------------------------->

<!--
Version: output of “node -v”
Platform: output of “uname -a” (UNIX), or version and 32 or 64-bit (Windows)
Subsystem: if known, please specify affected core module name
-->

- **Version**: master

## Location

Affected URL(s):
- https://nodejs.org/api/buffer
- https://nodejs.org/api/events
...among others

## Problem description

<!-- If applicable, include any screenshots that may help solve the problem. -->

Many methods are documented to take `<integer>` or `<integer[]>`. Examples:
[Buffer.from(array)](https://nodejs.org/api/buffer.html#buffer_class_method_buffer_from_array)
[emitter.setMaxListeners(n)](https://nodejs.org/api/events.html#events_emitter_setmaxlisteners_n)
It seems to always mean "an integer Number". However, clicking the type link leads to an [MDN section](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data_structures#Number_type) that starts with "ECMAScript has two built-in numeric types: Number and BigInt (see below).". One might erroneously think that BigInt, which is also an "integer", works too.

---

<!-- Use “[x]” to check the box below if interested in contributing. -->

- [ ] I would like to work on this issue and submit a pull request.
Repository: node
Issue: Use stream._construct
Labels: stream,meta

Since we have landed[ `construct`](https://github.com/nodejs/node/pull/29656) in streams we should try and update relevant parts of core where it makes sense to use this feature:

- [x] `fs` (was fixed as part of the `construct` PR)
- [ ] `net`
- [ ] `http`
- [ ] `http2`
- [ ] ...
Repository: TypeScript
Issue: Type of reverse mappings of numeric enums is a `string` instead of `keyof typeof Enum`
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 the latest published version. It may have already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly
-->
**TypeScript Version:**  4.0.0-dev.20200526

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
enum
numeric enum
reverse enum

**Code**

```ts
enum Enum {
  one = 1,
  two = 2,
}

const a: keyof typeof Enum = Enum[Enum.one]; // (1)
const b = Enum[0]; // (2)
console.log(a, b);
```

**Expected behavior:**
When a numeric enum is indexed by itself the value should be of type `keyof typeof Enum`:
No error on line (1).
Error `Property '0' does not exist on type 'typeof Enum'` on line (2).


**Actual behavior:**
When a numeric enum is indexed by a number (including itself) the value is of type `string`:
Error `Type 'string' is not assignable to type '"one" | "two"'` on line (1).
No error on line (2).

**Playground Link:** [Provided](https://www.typescriptlang.org/play?ts=4.0.0-dev.20200526&ssl=7&ssc=19&pln=7&pc=1#code/KYOwrgtgBAou0G8CwAoKUD2JhQLxQEYAaVdAFwHcM8oAmElAX1VQGMsBnMqAQwC4oAa2ABPDADMoZEQAdgE2PBpxIAbRUQAdFmABdANxtO3AEbL4qgAwGjIDhgA2wTQ4wBzABQ8iUEwEpDFCA)

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: flutter
Issue: Remove iOS version name normalization to 3 parts
Labels: c: new feature,platform-ios,tool,c: proposal,P3,team-ios,triaged-ios

## Use case

We specify app version and build numbers in `pubspec.yaml`. Some app releases we want to have a two part version number, like 2.7, for other app releases we want a three part version number, like 2.7.3.

In `pubspec.yaml` we write `version: 2.7+25` in the first case and `version: 2.7.3+25` in the second case.

For both Android and iOS we want the app version number to match the number we have in `pubspec.yaml`.

## Observed Behaviour

When Flutter generates the files for Android, the version number from `pubspec.yaml` is used verbatim, when it generates for iOS it is "normalized" to three parts. That is, 2.7 becomes 2.7.0.

The offending code is here:
https://github.com/flutter/flutter/blob/415401102ca165c2c727288e542eabd049ad4b62/packages/flutter_tools/lib/src/build_info.dart#L332-L334

## Proposal

Remove the iOS special case that normalizes to three parts.

## Solution

It is not, and never have been, a requirement to have three part version numbers on iOS. We have released apps on the Apple App Store for the past 10 years and used two part version numbers since the beginning.

The above referenced piece of code in `build_info.dart` references som Apple documentation that describes version numbers as three part. The author that created the offending piece of code must have read the documentation much to literally and mistaken it for official Apple policy.

The piece of code was introduced in merge request #27743.