sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Assertion function methods complains about missing annotation even with explicit annotation
Labels: Suggestion,Awaiting More Feedback

This may be working as intended but the error message is at least unclear for this case. It's not obvious why explicit annotation with a Union is different than explicit annotation with a class type.


**TypeScript Version:**  3.9.4

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
- assertion function union
- assertion function

**Code**

```ts
type Pet = Cat | Dog;

type Filter<V extends Pet, T extends 'dog' | 'cat' > = V extends { type: T } ? V : never

abstract class Base {
    abstract type: 'dog' | 'cat'   
  
    assert<T extends 'dog' | 'cat'>(this: Pet, type: T): asserts this is Filter<Pet, T>  {
        if (this.type === type) return
        throw new Error('nope')
    }
}

class Dog extends Base {
    type = 'dog' as const
    bark() { }
}       
class Cat extends Base  {
    type = 'cat' as const
    meow() { }
}

const a: Pet = new Dog() as any

const b: Dog = new Dog() as any

a.assert('dog')
a.bark()

b.assert('dog')
b.bark()
```

**Expected behavior:**

`a.assert()` to narrow the type and not complain about an explicit type annotation

**Actual behavior:**

`a.asserts` is marked as implicitly typed

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->

https://www.typescriptlang.org/play/index.html?ssl=38&ssc=9&pln=3&pc=1#code/LAKFBcE8AcFMAIAKtzwLzwMIENUB94ARAewHMBuUCGBAMQEsAbcWAJwB4A1eWADxYB2AEwDOSFABp4AFR79YwsQHIhZJfAJKAxrnUA+dPG59Bo+AG94UOAC4Z8AL7wA-Efh2BsAG5sqIbABGIuCs2FqoWozYImIAQtEI5qDwKfCBwaHhVjR2Kmoa8Nq6qcnwpSnRImzg7LImCmZ5pOqaOuBKegAU4AAW9CJ2yOBS1rB20gCUdpXVYr398AsMzGzsQ1LSBhblqSn0AGbw3X0iAHSj6GgYoxPwrCgArqwCO7u9rMQA7vCe3wCirA+rE6SgExDgSgmOwcoBhYBA+weAnC9GIAjSMWq0hotTkpmUqmaBSK7S6XkGkmythkUwxVVY4DEXkWYmWLA46xkWySIF2ByOXnONEu1xot3u4CeL15qXeXx+sH+gOIwNB4NgkNhfkilSIZDxDTiCW2MpSFwwTXU0XgWjRwR2AWwrAA1p1bpY4U5dilQDqYlhcAbFPB4lUUjy3sKLW0rWJbQJ7ab4ABbWBfN0WRxa+G+u2obAU1AYX560gZ63YASQXMJ1ABOwkUiGEuN8tiSvV+HYU4zBkgwma-ynR0ut1+AI9zF9y1QkATkeu2dAA


**Related Issues:** <!-- Did you find other bugs that looked similar? -->

#36931
#37241
Repository: rust
Issue: Formalize SVH stability for a specific release and target
Labels: A-linkage,T-compiler,C-feature-request,A-reproducibility

The Rust compiler does a pretty good job at generating strict version hashes that are stable for a given combination of the compiler revision, target, and the inputs, disregarding extraneous variation like the absolute path of the build directory. This can be confirmed by a [test](https://github.com/mzabaluev/github-actions-playground/actions/runs/153838631).

As outlined [in this discussion](https://internals.rust-lang.org/t/stability-of-dylibs-per-compiler-release/12648), if this stability is committed to as a feature, it would enable stabilized use of Rust dylib crates in revision-controlled sandbox environments like Flatpak.
Repository: rust
Issue: Remove `fn pretty_printing_compatibility_hack `
Labels: C-cleanup,A-pretty,A-macros,T-compiler,A-proc-macros,A-proc-macro-back-compat

https://github.com/rust-lang/rust/pull/73345 adds a hack to support some older versions of `proc-macro-hack` and `procedural-masquerade` which included incorrect asserts.
The hack detects some specific enums used by those crates literally by their names and names of their variants.

Using newer versions of those crates fixes the issues
- `proc-macro-hack` requires a major version bump so it doesn't happen automatically
- for `procedural-masquerade` only a bugfix version update is required, so `cargo update` should do the job, but the old version is fixed in hundreds of `Cargo.lock`s according to crater.

This hack needs to be removed eventually.
Now it's July 1 2020, so on July 1 2021 or later we need to run crater once more to estimate the use of these old versions again.
Then we could assume that crates not updating from outdated versions for so long are not maintained and we can break them and remove the hack.
Repository: pytorch
Issue: [JIT] Infer type of argument foo = None to be Optional[Tensor]
Labels: high priority,triage review,oncall: jit

A pretty common pattern in PyTorch code is to write things like:

```
def forward(self, src, src_mask, tgt_in, pos=None):
```

(this example taken from `stanza/models/common/seq2seq_model.py` in https://github.com/stanfordnlp/stanza)

When I script functions like this, I have to add the annotation `pos: Optional[Tensor]` manually. But it seems very modest and easy for JIT to extend its special case (where it default infers all arguments to be Tensor): if an argument has default argument None, then we infer its type to be Optional[Tensor].

cc @ezyang @gchanan @zou3519 @bdhirsh @jbschlosser @gmagogsfm @suo
Repository: pytorch
Issue: [JIT] cannot statically infer the expected size of a list in this context for positional arguments to Tensor.view()
Labels: oncall: jit,weeks,TSUsability,TSRootCause:UnsupportedConstructs

This program doesn't work:

```
import torch.jit

@torch.jit.script
def f(x, y):
    return x.view(*y.size())
```

however, if you remove the asterisk, it is ok. I have seen this in the wild as `x.view(20, *y.size())` as a convenient away to avoid tuple concatenation. The explicit tuple form works (`x.view((20,) + y.size())`)

cc @suo @gmagogsfm
Repository: ant-design
Issue: DatePicker control - Narrator should announce dates or month when user navigate through calendar using keyboard
Labels: Inactive,⌨️ Accessibility


![calendar_accessibility](https://user-images.githubusercontent.com/64444288/86277637-e54b7f80-bb8b-11ea-87bd-11eb233481d8.PNG)
- [x] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### Reproduction link
[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/s/igmjw)

### Steps to reproduce
1. Open the code sandbox link
2. Start windows narrator
3. Navigate to DatePicker control using tab and hit enter which will open the calendar
4. Press tab and arrow keys to navigate through dates or month
5. It seems that narrator do not announce the dates or month in the calendar
6. Aria label needs be added in the calendar and windows narrator should announce the date or month when user navigate through calendar using keyboard.

### What is expected?
 Aria label needs be added in the calendar and windows narrator should announce the date or month when user navigate through each date or month using keyboard.

### What is actually happening?
Windows narrator not announcing date or month in DatePicker control using keyboard.

| Environment | Info |
|---|---|
| antd | 4.4.0 |
| React | 16.12.0 |
| System | Windows 10 |
| Browser | Edge Version 81.0.416.72 (Official build) (64-bit) or Chorme Version 81.0.4044.138 (Official Build) (64-bit) |


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: TypeScript
Issue: Officially document type checking behavior for operators WRT bigint
Labels: Discussion

## Search Terms

bigint operator type checking

## Suggestion

I'd like to see official documentation of the design decision TS has made regarding type checking of operators now that bigint
is in play.

## Use Cases

The closure-compiler team is currently working on our support for BigInt.
We want to make sure the type design choices we make there are compatible with TS going forward.

It appears that right now when you perform an arithmetic operation on 2 `any` values, TS infers the result to be of type `number`, even in ESNext mode where one might expect the result to be `number|bigint`.

https://www.typescriptlang.org/play/?target=99#code/DYUwLgBAhgXNB2BPCBeCBGeBuAUKSARnFEqhtnuBAMZwECWA5vfJGlBAFQQFZA

I am inclined to do the same for closure-compiler, but I'd first like to make sure that this behavior was an intentional design choice for TS and not an oversight/bug that is likely to change in the near future.

My point of view on this is that logically the `*` operator (for example) is overloaded, so there are really 2 versions of it.

1. The original `*` can take anything (except `bigint`), and always returns a `number`.
2. The new `bigint * bigint` version, which always returns a `bigint`, or throws an exception if one operand is not a `bigint`.

The compiler should assume it's dealing with #1, unless type information indicates it is seeing #2.

Insisting that all operands be clearly typed as `bigint` if you want `bigint` results prevents users from
crossing the streams and accidentally mixing `bigint` and `number` values in computations.

## Examples

1. What is the result type of `bigint|number * bigint|number`? I expect `bigint|number` with no error message, since you may want to write methods that are intentionally meant to work for either case.
2. What is the result type of `bigint * any`? I expect the `bottom/can't happen` type, and an error message since we can't be sure that the right operand will be a `bigint` at runtime.
3. What is the result type of `any * any`? I expect `number` (current TS behavior), because it's undesirable for old code to suddenly think it might have a `bigint`, and new code should be explicit about using `bigint` to avoid runtime errors.

## 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: [web] link to a Specific Line or Paragraph on a web page
Labels: c: new feature,framework,platform-web,P3,team-web,triaged-web

<!-- Thank you for using Flutter!

     If you are looking for support, please check out our documentation
     or consider asking a question on Stack Overflow:
      * https://flutter.dev/
      * https://api.flutter.dev/
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     If you have found a bug or if our documentation doesn't have an answer
     to what you're looking for, then fill our the template below. Please read
     our guide to filing a bug first: https://flutter.dev/docs/resources/bug-reports
-->

## Use case

How do I get the ability to reference to a particular part of the page (a paragraph or a tab) in Flutter web. In traditional web url, this is made possible by anchoring the div to be references with a #. For e.g. in the link https://cloud.google.com/customers/featured/paypal#take-the-next-step, the link takes as directly to the div that is tagged as take-the-next-step

Is there a way to do this in Flutter Web yet ?

## 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.
-->
Repository: pytorch
Issue: Allow TLS to keep distributed autograd context alive
Labels: feature,triaged,module: rpc

As of today, we release the distributed autograd context when exiting the context manager:

https://github.com/pytorch/pytorch/blob/c71ec1c717e5b225f28ef3bacde416c69f3c4d77/torch/distributed/autograd/__init__.py#L32-L37

As a result, the following code wouldn't work, as when running the `run_backward` callback function, the distributed autograd context might have been released. 

```python

class Model(nn.Module):
    def forward(self, x):
        return ps_rref.rpc_async().foward(x)

with dist_autograd.context() as context_id:
    def run_backward(out_fut):
        dist_autograd.backward(context_id, [loss_fn(out_fut.wait(), label)]

    model(x).then(run_backward)
```

### Pitch

Instead of always releasing the distributed autograd context on exit the scope, we can manage its lifetime using a `shared_ptr` or other reference counting methods. Then, we can let the TLS own a copy of the `shared_ptr` to the context. So that callbacks can still access the context if necessary. Another option might be expanding `context_id` into a custom type whose lifetime dictates the distributed autograd context's lifetime. 

This feature will be useful to parallelize the backward pass in pipeline parallel applications. 


cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @rohan-varma @xush6528 @jjlilley @osalpekar @jiayisuse
Repository: pytorch
Issue: JIT fuser result of dropout doesn't fully match eager mode 
Labels: oncall: jit,triaged

Running this test with legacy executor should repro:
```
    def test_dropout_cuda(self):
        # Dropout AD is dispatched to _fused_dropout in CUDA case,
        # which is not included in TestJitGeneratedFunctional
        
        x = torch.ones((4, 4)).cuda().requires_grad_()

        with enable_profiling_mode_for_profiling_tests():
            @torch.jit.script
            def func(x):
                return torch.nn.functional.dropout(x)


            with freeze_rng_state():
                out = func(x)
                #grad = torch.autograd.grad(out.sum(), x)

            with freeze_rng_state():
                out_ref = torch.nn.functional.dropout(x)
                #grad_ref = torch.autograd.grad(out_ref.sum(), x)

            print("out=", out)
            print("out_ref=",out_ref)
            self.assertEqual(out, out_ref)
            self.assertEqual(grad, grad_ref)
```
cc: @ngimel @Krovatkin 


cc @suo @gmagogsfm
Repository: flutter
Issue: [video_player] [RFC] Add "muted" attribute to Video Player API?
Labels: c: new feature,p: video_player,package,team-ecosystem,P3,triaged-ecosystem

For videos to auto-play on the web, they must start "muted".

The current video player platform interface API does not have a direct way of setting a "muted" attribute [other than assuming that volume 0.0 means "muted"](https://github.com/flutter/plugins/pull/2819#discussion_r437626495).

Does the Video Player plugin need a "muted" attribute, as mentioned in the discussion above? Or is the web workaround "acceptable"?
Repository: TypeScript
Issue: Add refactoring option to convert between function declaration and function variable
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

-  refactor function declaration 
-  refactor to arrow function

## Suggestion

<!-- A summary of what you'd like to see added or changed -->

Consider adding refactoring from

```ts
const fn = (x: number): number => {
  return x + 1
}
```

into

```ts
function fn(x: number): number {
  return x + 1
}
```

and vice-versa.

## Use Cases

<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->

I found myself doing this refactor by hand many times. I think the main use cases are:

*  Project has code style which enforces one of the above, and you're pasting some other code.
*  Particular function declaration simply looks better when written as block-less arrow function.
*  After refactoring an arrow function to a variable in current scope, it always picks the arrow style, but it could be written as a declaration as well.

## Examples

<!-- Show how this would be used and what the behavior would be -->

Don't know if viable, but here it goes:

```tsx
export const Component: React.FC<Props> = props => {
  return <h1>Hello, {props.name}</h1>
}

export function Component(props: Props) {
  return <h1>Hello, {props.name}</h1>
}
```

## 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: go
Issue: runtime: idle GC interferes with auto-scaling
Labels: NeedsDecision,compiler/runtime

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.14 linux/amd64
</pre>

But this has been true for years.

### What did you do?

Run a mostly-idle application in a container with CPU limits under a mechanism that monitors CPU use and increases the job's CPU reservation if it appears to be too little. Specifically, this was observed with a latency-sensitive policy that looked at high percentile usage sampled over a short time period.

### What did you expect to see?

Since the application is mostly idle, a small CPU reservation should be adequate and the auto-scaler should not need to grow that reservation.

### What did you see instead?

Because the garbage collector attempts to use any idle cores up to GOMAXPROCS, even an otherwise mostly idle application will see periodic spikes of CPU activity. These will happen at least every 2 minutes if not more frequently. In this case, the auto-scaler's policy was sensitive enough that these spikes caused it to grow the job's CPU reservation. However, then the garbage collector uses all of the new CPU reservation. This leads to a feedback cycle where the auto-scaler continually grows the reservation.

See also #17969, https://github.com/golang/go/issues/14812#issuecomment-518902192.

/cc @mknyszek 

### Thoughts

We've been thinking for a while now that idle GC may be more trouble than it's worth. The idea was to speed up the mark phase, so the write barrier is on for less time and we allocate black for less time. However, if an application is mostly idle, then it's not very sensitive to the (very small) performance impact of the write barrier and probably doesn't produce much floating garbage from allocate-black; and if an application isn't mostly idle, then it's not benefiting from idle GC anyway.
Repository: pytorch
Issue: Improve error messaging when using dictionaries as inputs to a trace
Labels: oncall: jit,triaged,enhancement

## 🚀 Feature
## Motivation

The JIT tracer supports using dictionaries as input, like:
```
import torch
from typing import Dict

class TestModule(torch.nn.Module):
    def __init__(self):
        super(TestModule, self).__init__()

    def forward(self, dict_input):
       return dict_input['x']

input_1 = {'x': torch.tensor(1)}
m = TestModule()
m_traced = torch.jit.trace(m, (input_1, ))
```

However, the tracer "burns in" the structure of the dict (more precisely, it inlines all keys as constants and burns in the value types). The resulting graph looks like:
```
graph(%self : __torch__.TestModule,
      %2 : Dict(str, Tensor)):
  %3 : str = prim::Constant[value="x"]()
  %4 : Long() = aten::__getitem__(%2, %3)
  return (%4)
```

If you try to use a dictionary with a different key, you will get a very opaque error message
```
input_2 = {'y': torch.tensor(1)}
m_traced(input_2)

Traceback (most recent call last):
  File "/private/home/suo/scratch/test.py", line 27, in <module>
    m_traced(input_2)
  File "/scratch/suo/pytorch/torch/nn/modules/module.py", line 722, in _call_impl
    result = self.forward(*input, **kwargs)
RuntimeError: The following operation failed in the TorchScript interpreter.
Traceback of TorchScript (most recent call last):
/scratch/suo/pytorch/torch/jit/__init__.py(1108): trace_module
/scratch/suo/pytorch/torch/jit/__init__.py(954): trace
/private/home/suo/scratch/test.py(24): <module>
RuntimeError: KeyError: x
```

We ought to improve the error messaging here, with reference to the expected structure and how it's different from the structure the user passed in.

cc @suo @gmagogsfm
Repository: PowerToys
Issue: Trigger FancyZone for windows that are dragged not by the TitleBar.
Labels: Idea-Enhancement,Product-FancyZones,Issue-DCR

# Summary of the new feature/enhancement
I have the script at my PC, written on AutoHotkey, which allows me to Move Windows using Any It Parts. This functionality mapped to Middle Mouse Button. FancyZone feature works only if I drag window by TitleBar. It would be nice if we could make it work with any dragged window. 
Not sure if it possible at all, but may be you have some ideas.
Repository: vscode
Issue: Git - Timeline produces confusing results on with merged branch
Labels: bug,git,timeline,timeline-git

I just merged a branch into another branch, then looked at a change in the Timeline view. I was confused that it shows a diff that doesn't match what that commit should have had, but I think it makes sense if it is diffing that version of the file with the previous commit that shows in the flattened view in the Timeline. (where the previous commit is not actually the parent commit of the one I'm looking at). If I look at the commit history in gitlens and look at that commit/file, I see the expected diff. Is that by design?
Repository: pytorch
Issue: [FR] torch.floor/ceil should support output int dtype
Labels: triaged,enhancement,module: type promotion

```
In [21]: x
Out[21]:
tensor([[2, 0, 1],
        [1, 2, 2]])

In [22]: torch.floor(torch.randn(2,3)*10, out=x)
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
<ipython-input-22-d7f2bdd35edf> in <module>
----> 1 torch.floor(torch.randn(2,3)*10, out=x)

RuntimeError: result type Float can't be cast to the desired output type Long
```

Ideally, a `dtype` option should also be added.

cc @nairbv
Repository: vscode
Issue: [themes] 'Generate Color Theme From Current Settings' omits semantic token settings
Labels: feature-request,themes

Issue Type: <b>Bug</b>

1. Launch the semantic-tokens-sample extension.
2. Follow the README.md instructions to add `editor.semanticTokenColorCustomizations` to your settings.
3. Run the `Developer: Generate Color Theme From Current Settings` command.
4. Review the generated color theme document but find no sign of your semantic token color customizations.

VS Code version: Code - Insiders 1.47.0-insider (b16b467d3e03e1a1ae05b5836e4e5a5af504e86d, 2020-07-01T05:32:07.483Z)
OS version: Windows_NT x64 10.0.18363


<!-- generated by issue reporter -->