sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Conditionally Mapped Type Leads to Confusing ts(2345) Error Message
Labels: Suggestion,Needs Proposal

**TypeScript Version:**
3.9.6
4.1.0-dev.20200914

**Search Terms:**
2345
conditional

**Code**

```ts
declare type GetPropertyNamesOfType<T, RestrictToType> = {
	[K in keyof T]: T[K] extends RestrictToType ? K : never;
}[keyof T];
```
You can find this gnarly type here:
https://github.com/microsoft/TypeScript/blob/94d4023043dd032a8c96a59677eb63526b6b24b6/tests/cases/conformance/types/conditional/conditionalTypes2.ts#L227

The following consuming/using code _correctly_ generates `ts(2345)` errors for the last two lines:
```ts
interface A {
	req: string;
	num: number;
	str: string;
}
interface B {
	req: string;
	num?: number;
	str?: string;
}

declare function callA(name: GetPropertyNamesOfType<A, string>): void;
declare function callB(name: GetPropertyNamesOfType<Required<B>, string>): void;

const prop = "someKey";
callA(prop); // ts(2345)
callB(prop); // ts(2345)
```

**Expected behavior:**
In `typescript@3.9.5` & `typescript@3.8` (and a few earlier versions I tried) the error message for both lines is:
```
Argument of type '"someKey"' is not assignable to parameter of type '"req" | "str"'.
```

**Actual behavior:**
In `typescript@^3.9.6` this is reported for both lines:
```
Argument of type '"someKey"' is not assignable to parameter of type 'GetPropertyNamesOfType<A, string>'.
```

That's correct (nice even!) for the `callA()` line, but it's confusing for the `callB()` line.

(This reproduction is a single file that can run into this problem... it's not how I ran into it. I had a `ts.Program` with many 10s of `*.ts` files in the same compilation and the message was referring to some type that made no sense in the source file that was giving me the error.)

**Playground Link:**
https://www.typescriptlang.org/play?#code/CYUwxgNghgTiAEAXAngBwQcRIgCjA9ujCgHJQC2IAzgPIBmAKmiADwMA08AStYjAJZhEDfE3QA+eAF54AbwCwAKACQAbQDS8fgDt4AaxDJ8deAwC6ALlMaz8EAA9EIbcCrdeAoSLEIA-PE0rbRAANxAYAG4lAF9VAyMTcyjFJR0nGDooMAQAQTklZTgARysqPh0Ac2TlbQBXciD6gCNw6rKYUvLtKpjU7XTM7PgAIXyVYs6Bbuq68l9G8hbIgvb5+HbK5OilJVBIWAQ6Wu0hfnxdMCgICByACm0KECssXAIiUkfaRmYWHM4N7riACUVhC+H4wGSe2gcHgRxOiDOFyuEGG90ez2weEI4Q+lC+PhYPCKtX4cGALGG4n+XQqwNB4MhO0UYHOZXgqDe0ngACIqPhKOpDDzkpdrndOYQgRF4AB6WVIKi3ABMAGYACwAViBSjFqNuktQ0rlCsQSrVWp1iiAA

**Related Issues:**
I found reference to the gnarly type above in #32608 & #33568.
It looks to be the same "monster" as you see in #29505 too.
Repository: flutter
Issue: Integrate Navigator 2.0 and state restoration for the web
Labels: c: new feature,framework,engine,f: routes,platform-web,P3,team-web,triaged-web

We would like to integrate state restoration to web application.

This includes:

1. Web engine listens to restorable state reported from the framework and save the restorable state into the browser history entry. (blocked on https://github.com/flutter/flutter/issues/33615)
2. Web engine starts sending the restorable state to the framework as part of onPopstate event(when user click forward or backward buttons)
3. Provides an opinionated route information parser and router delegate that will restore the app automatically when it receives the restorable state
Repository: flutter
Issue: Replace multiple hero tag exception by grabbing first hero
Labels: framework,f: material design,c: proposal,team-design,triaged-design

## 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 the alternative solutions you've considered. Is there a package
     on pub.dev/flutter that already solves this?
-->

Attaching hero tags for image objects for shared animation transitions, there can be many cases in the data structure where same image is displayed more than once on the page. Example could be images in the article.
At the moment, having multiple Hero widgets with the same tag results in a crash.

## Proposal

<!--
     Briefly but precisely describe what you would like Flutter to be able to do.

     Consider attaching images showing what you are imagining.

     Does this have to be provided by Flutter directly, or can it be provided
     by a package on pub.dev/flutter? If so, maybe consider implementing and
     publishing such a package rather than filing a bug.
-->
To support the usecase and remove the need to check data structure sanity from the user, I propose to remove critical exception and rather just use the first available Hero widget with the tag.
Repository: flutter
Issue: [web][unit-tests] methods in recording_canvas_golden_test fails on ios-safari
Labels: a: tests,platform-web,P2,team-web,triaged-web

[recording_canvas_golden_test](https://github.com/flutter/engine/blob/master/lib/web_ui/test/golden_tests/engine/recording_canvas_golden_test.dart#L318) methods are mostly passing for ios-safari, however the `expect` condition for the following method fails:

```  
test('Computes paint bounds for multi-line draw paragraph', () async {
    final RecordingCanvas rc = RecordingCanvas(screenRect);
    final Paragraph paragraph = createTestParagraph();
    const double textLeft = 5.0;
    const double textTop = 7.0;
    // Do not go lower than the shortest word.
    const double widthConstraint = 130.0;
    paragraph.layout(const ParagraphConstraints(width: widthConstraint));
    rc.drawParagraph(paragraph, const Offset(textLeft, textTop));
    rc.endRecording();
    expect(
      rc.pictureBounds,
      const Rect.fromLTRB(textLeft, textTop, textLeft + widthConstraint, 35.0),
    );
    await _checkScreenshot(rc, 'draw_paragraph_multi_line');
  },
```

Exception:

```
00:14 +20 -2: Computes paint bounds for multi-line draw paragraph [E]                                                                                                                                                                        
  Expected: Rect:<Rect.fromLTRB(5.0, 7.0, 135.0, 35.0)>
    Actual: Rect:<Rect.fromLTRB(5.0, 7.0, 135.0, 37.0)>
```
Repository: flutter
Issue: [flutter_tools] Migrate hostonly_devicelab tests to flutter_tools
Labels: team,tool,P3,c: flake,team-tool,triaged-tool

Most of the [hostonly_devicelab tests](https://github.com/flutter/flutter/blob/master/dev/bots/test.dart#L1239) can and should be migrated to `//flutter/packages/flutter_tools/test/integration.shard`.

## Can be migrated

* [ ] plugin_test
* [ ] plugin_lint_mac
* [ ] build_ios_framework_module_test
* [ ] plugin_dependencies_test
* [ ] module_test
  * Improve hard-coded pubspecs
  * Move analytics verification to a smaller test
* [ ] module_custom_host_app_name_test
  * Possibly merge with module_test?
* [ ] module_host_with_custom_build_test
  * Maybe? See module_test et al
* [x] ~gradle_r8_test~ removed with #68110
* [ ] gradle_plugin_light_apk_test
* [ ] gradle_plugin_fat_apk_test
  * Possible merge/dedupe with light version?
* [x] gradle_deprecated_settings_test (#65806)
* [x] gradle_non_android_plugin_test (#80161)
* [x] ~gradle_jetifier_test~ removed with #68110
  * Has hard-coded pubspec
* [x] ~gradle_fast_start_test~ removed with #67765 
* [ ] build_aar_module_test

## Cannot be migrated

* web_benchmarks
* module_test_ios
  * because it uses simulator
  * Probably should improve hard-coded pubspecs

## Retire

* [x] flutter_create_offline_test_mac and windows and linux (#65791)
  * These tests are not strictly correct, and provide minimal value.
Repository: pytorch
Issue: Use macro to define `DispatchKey::toString` method
Labels: triaged,module: dispatch

As @bhosmer suggested in https://github.com/pytorch/pytorch/pull/44354/, 
use macro to define `toString` method in https://github.com/pytorch/pytorch/blob/master/c10/core/DispatchKey.cpp#L5-L108
example: https://github.com/pytorch/pytorch/blob/master/c10/core/ScalarType.h#L25-L41
Repository: vscode
Issue: editor.renderWhitespace should have option for selection+trailing
Labels: feature-request,editor-render-whitespace

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
Right now you're limited to picking between `selection` (old) or `trailing` (new), but if you want both behaviours you're out of luck.

There should be an option allowing both to be true.
Repository: TypeScript
Issue: Non‑`void` returning assertion functions
Labels: Suggestion,Awaiting More Feedback

## Search Terms

- assertion function non-void return type
- assertion function non-void return
- assertion function generic return
- assertion function custom return

## Suggestion

A way to type a function that is both an assertion function and returning a value that is not void.

## Use Cases

This is necessary to correctly type **Jest**’s `expect(…)` matchers, which have a generic return type of `R`.

## Examples

```ts
declare const expect: <T>(actual: T): JestMatchers<T>;

type JestMatchers<T> = JestMatchersShape<
	Matchers<void, T>,
	Matchers<
		Promise<void>,
		T extends PromiseLike<infer U>
			? U
			: Exclude<T, PromiseLike<any>>
	>
>;

type JestMatchersShape<TNonPromise extends {} = {}, TPromise extends {} = {}> = {
	resolves: AndNot<TPromise>;
	rejects: AndNot<TPromise>;
} & AndNot<TNonPromise>

type AndNot<T> = T & { not: T };

interface Matchers<R, T = {}> {
	toBe<E>(expected: E): R & (asserts T is E);
}

declare const foo: unknown;
expect(foo).toBe("foo");
foo; // $ExpectType "foo"
```

```ts
// Some typings for engine262's Completion Record handling:
type UnwrapNormalCompletion<T>
	= unknown extends T ? Value | undefined
	: T extends NormalCompletion<infer V>
		? (unknown extends V ? Value | undefined : V)
	: T extends Completion ? never
	: T;

/** @see https://tc39.es/ecma262/#sec-returnifabrupt */
export declare function ReturnIfAbrupt<T>(completion: T):
	(UnwrapNormalCompletion<T>)
	& (asserts completion is UnwrapNormalCompletion<T>);

/** @see https://tc39.es/ecma262/#sec-returnifabrupt-shorthands */
export { ReturnIfAbrupt as Q };

/**
 * The type signature is the same, but `AssertNormalCompletion` causes an error to be thrown at runtime
 * if `argument` is an AbruptCompletion, whereas `ReturnIfAbrupt` gets replaced with code that causes
 * the caller to return the AbruptCompletion by engine262's build system:
 *
 * @see https://tc39.es/ecma262/#sec-returnifabrupt
 * @see https://tc39.es/ecma262/#sec-returnifabrupt-shorthands
 */
declare function AssertNormalCompletion<T>(completion: T):
	(UnwrapNormalCompletion<T>)
	& (asserts completion is UnwrapNormalCompletion<T>);
export { AssertNormalCompletion as X };
```

## 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: pytorch
Issue: Make quantized::prepack_fp16 op just do prepacking
Labels: oncall: quantization,low priority,triaged

Minor comment: It looks like the prepack_fp16 does both dtype conversion and packing, which is not true of the int8 case. Is there any way to make this uniform? i.e convert to fp16 and then call pack?

_Originally posted by @raghuramank100 in https://github.com/pytorch/pytorch/pull/44582#discussion_r488162800_

cc @jianyuh @raghuramank100 @jamesr66a @vkuzo @jgong5 @Xia-Weiwen @leslie-fang-intel @jerryzh168 @dzhulgakov
Repository: TypeScript
Issue: Lazier typeof operator to enable limited "circular" references
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

- typeof referenced indirectly
- lazy typeof
- lazier typeof
- circular typeof

#25214 is very closely related but not exactly the same.

## Suggestion

If `typeof` operators were resolved _slightly_ lazier, certain "circular" type definitions could be typed more automatically. Then the following could be made to compile:

```ts
type Place = keyof typeof building;
function room(doors: Place[]): {doors: Place[]} {
  return { doors };
}
const building = {
  foyer: room(["dining", "kitchen"]),
  dining: room(["foyer", "bedroom"]),
  kitchen: room(["foyer", "bedroom"]),
  bedroom: room(["dining", "kitchen"]),
};
```

Currently, you get

```
Type alias 'Place' circularly references itself.ts(2456)
```

However, `Place` doesn't actually reference _itself_ since you don't need to know what `Place` is to evaluate `keyof typeof building`, only to evaluate `typeof building` in its entirety. If `typeof building` were resolved lazily (as it was needed) then its keys could be found without needing `Place`, breaking the reference cycle.

Specifically, we can resolve `type Place = "foyer" | "dining" | "kitchen" | "bedroom"` without needing to know what `building`'s properties are specifically typed. Then, we can proceed with any inferences as needed for the `building`, getting the complete inferred type

```
type Place = "foyer" | "dining" | "kitchen" | "bedroom";
const building: Record<Place, {doors: Place[]}>; // or something equivalent, e.g. an actual object
```

## Downsides/Tradeoffs

- More complexity in type-checker
- Relatively fringe use-case
- Possibly brittle (small changes to variable definition or type definition may cause circularity to reappear, limiting possible use)

## 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: pytorch
Issue: Error message concerning dtype GRU not identical between devices
Labels: module: error checking,triaged

## 🐛 Bug

<!-- A clear and concise description of what the bug is. -->

In 1.6, a bug exists where a GRU accepts an input `float32` anc a hidden state `float64` but only when on GPU. This will lead to unexpected, explosive results with very large or very small values.

```python
import torch
from torch import nn

USE_GPU = True

torch.manual_seed(2809)
torch.cuda.manual_seed(2809)


device = torch.device("cuda" if USE_GPU else "cpu")
rnn = nn.GRU(10, 10).to(device)
for _ in range(100):
    input = torch.randn(1, 3, 10).to(device)
    h0 = torch.randn(1, 3, 10).double().to(device)
    print("input dtype", input.dtype)
    print("h0 dtype", h0.dtype)
    output, hn = rnn(input, h0)
    print(output.abs().max(), hn.abs().max())
    print()
```
As @ptrblck found in [this topic](https://discuss.pytorch.org/t/is-it-required-that-input-and-hidden-for-gru-have-the-same-dtype-float32/96221), this bug seems to have been solved in 1.7 nightlies. However, an improvement can still be made: The error message is not the same between devices:

- CPU: RuntimeError: expected scalar type Float but found Double
- GPU: RuntimeError: Input and parameter tensors are not the same dtype, found input tensor with Double and parameter tensor with Float

It would probably be better to have identical error messages across devices concerning the same issue.

As said, the original bug was in 1.6 but seems to have been fixed in 1.7 nightlies. The error message in the nightlies could still be improved between devices, though.

Env
---

PyTorch version: 1.7.0.dev20200912+cu101
Is debug build: False
CUDA used to build PyTorch: 10.1
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.4 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: Could not collect
CMake version: version 3.10.2

Python version: 3.7 (64-bit runtime)
Is CUDA available: True
CUDA runtime version: 10.1.243
GPU models and configuration:
GPU 0: Tesla V100-SXM2-16GB
GPU 1: Tesla V100-SXM2-16GB
GPU 2: Tesla V100-SXM2-16GB
GPU 3: Tesla V100-SXM2-16GB

Nvidia driver version: 440.95.01
cuDNN version: /usr/lib/x86_64-linux-gnu/libcudnn.so.7.6.5
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.19.2
[pip3] torch==1.7.0.dev20200912+cu101
Repository: flutter
Issue: <base-config> in Network Security Configuration for Android is not honoured & fatal crash when using IP addresses as <domain>
Labels: platform-android,engine,c: proposal,P3,team-android,triaged-android

## Steps to Reproduce
### A) Not honouring `<base-config>`
1. Update `network_security_config.xml` as
```xml
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="true"/>
    <domain-config cleartextTrafficPermitted="false">
        <!-- List the domains for which you want ensure HTTPS traffic -->
        <domain>secure.example.com</domain>
        <domain>dev.example.com</domain>
    </domain-config>
</network-security-config>
```
2. Set base URL with `http` scheme. _For instance http://10.0.2.2_
3. Run the app.

**Expected results:**
All the domains & IPs expect `example.com` & `dev.example.com` should be allowed to have `http` scheme.

**Actual results:**
`Insecure socket connections are disallowed by platform:` for all domains & IPs

### B) Fatal Crash when setting IP addresses as `<domain>`
1. Update `network_security_config.xml` as
```xml
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="false"/>
    <domain-config cleartextTrafficPermitted="true">
        <!-- List the domains for which you want opt out ensuring HTTPS traffic -->
        <domain>10.0.2.2</domain>
        <domain>insecure.example.com</domain>
    </domain-config>
</network-security-config>
```
2. Set base URL with `http` scheme. _For instance http://10.0.2.2_
3. Run the app.

**Expected results:**
IPs and domains listed above should be allowed to have `http` scheme.

**Actual results:**
![image](https://user-images.githubusercontent.com/9782008/93199453-1fc9bf00-f76e-11ea-98a6-f72671cdbbe7.png)
Repository: godot
Issue: Allow Hidpi leads to wrong window scale
Labels: bug,platform:macos,topic:porting,regression

**Godot version:**
3.2.3 RC 6 Official, MacOS

**OS/device including version:**
- MacBook Pro (13", 2020)
- 2,3 GHz Quad-Core Intel Core i7
- 16 GB 3733 MHz LPDDR4X
- Intel Iris Plus Graphics 1536 MB

**Issue description:**
Checking "Allow Hidpi" in the project settings (Display > Window > Dpi) scales down the window size to half (?) its intended size.
It happens with newly created vanilla 3D-projects, too. So this seems not to be about some other conflicting setting.
This appears to be a regression as the current stable build does not have this problem. It has been around for a number of release candidates already.

**Steps to reproduce:**
Check "Allow Hidpi" in project settings (Display > Window > Dpi).

**Minimal reproduction project:**
Happy to provide the fresh test-project I just created but since this is a one click operation for a newly created project, I refrained from uploading anything at this point for now.
Repository: node
Issue: http2: Client can return partial response (instead of error emit)
Labels: http2

* **Version**: v14.10.1
* **Platform**: macOS 10.15.6
* **Subsystem**: http2

### What steps will reproduce the bug?

1. Setup a http2 server that will:
  a. Send a response containing a `content-length` header.
  b. Stall after transmitting part of the data (or just the headers).
  c. Stop the transmission with a `RST_STREAM` frame with `error_code = 0`.
1. Create a http2 client (new or old api), and call the server, trying to receive the content.
1. Validate that `content-length` bytes have been received.

FYI, I don't know how to setup such a server, though it can occur naturally with envoy in http2 mode.

### How often does it reproduce? Is there a required condition?

100%. It requires the stream to be closed with a `RST_STREAM` frame containing `error_code = 0`.

### What is the expected behavior?

http2 client emits an error.

### What do you see instead?

No error. Just a partial response, with less than `content-length` bytes.

### Additional information

This is caused by an nghttp2 bug: https://github.com/nghttp2/nghttp2/pull/1508

The bug causes [this callback](https://github.com/nodejs/node/blob/fb1ab198945d9ed8a9572d7838862ba9b9b106de/lib/internal/http2/core.js#L500) to be called with `code = NGHTTP2_NO_ERROR ` when the server sends a `RST_STREAM` frame with `error_code = 0` for an active stream.

More details in my initial reported issue here: https://github.com/sindresorhus/got/issues/1462
Repository: godot
Issue: Single discrete modulate key breaks animation player
Labels: bug,topic:editor

**Godot version:**
3.2.2 stable


**OS/device including version:**
linux mint


**Issue description:**
Modulate faults with animation player. If you have a discrete modulate with a single key then two things happen:

1. After you have ran an animation, when you take the track back to the beginning, or simply slide the track to different time lines, modulate is not updated. All other tracks are. It only resets back to normal when you click play. See Animated Gif showing sprite red and only changes back to normal after pressing play.

2. If you try to set modulate to a single value after a continuous modulate then the modulate does nothing until the animation plays. Refer to animated gif - after it goes dark red from first modulate, the third modulate that turns it brighter is ignored until it reaches the very end of the animation player, then it changes the colour.

Now, refer to the image. Here I have simply made modulate a discrete that goes to bright red. After I add this extra key, I can slide along the track fine and modulate works, however it still will not change to the bright red until after the animation finishes playing. If I change track three from discrete to continuous it works fine.

![Peek 2020-09-15 14-03 modulate bug](https://user-images.githubusercontent.com/12863685/93214789-84305280-f75d-11ea-93a5-7e86f950bb23.gif)

![image](https://user-images.githubusercontent.com/12863685/93214777-7f6b9e80-f75d-11ea-9546-5fa4939ea538.png)

<!-- What happened, and what was expected. -->


**Steps to reproduce:**


**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->