sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Can't use `arguments` property name within arrow function in JS
Labels: Bug

# Bug Report

### 🔎 Search Terms

`is:issue arguments property in:title`

### 🕗 Version & Regression Information

<!-- When did you start seeing this bug occur?

"Bugs" that have existed in TS for a long time are very likely to be FAQs; refer to
  https://github.com/Microsoft/TypeScript/wiki/FAQ#common-bugs-that-arent-bugs

If possible, please try testing the nightly version of TS to see if it's already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly

Note: The TypeScript Playground can be used to try older versions of TypeScript.

Please keep and fill in the line that best applies:
-->
- This changed between versions 4.1.x and 4.2.x (and is still present in v4.3.0-dev.20210324)

### ⏯ Playground Link

[Playground link with relevant code](https://www.typescriptlang.org/play?ssl=1&ssc=1&pln=7&pc=1&useJavaScript=true#code/MYewdgzgLgBAZiEMC8MAUBKFA+GBvAWACgZSYAbAU1igAsBLMAcxX2LI5gEMAnJgVwC2lMFAgAuGAEYANO06kA9IpgA9GAFEePED0kBhLmDAhYcRgBMYYLsJgByXgOGiI9gHTzSAXwDcxP2IgA)

### 💻 Code

```js
const foo = () => {
    let thing = {
        arguments: 1,
        // ^ Error: Cannot find name 'arguments'.
    };
};
```

### 🙁 Actual behavior

*Note: this only appears when checking JavaScript.*

Defining an object with a property named `arguments` inside an arrow function is treated as a reference to an `arguments` identifier.

### 🙂 Expected behavior

A property named `arguments` is valid JavaScript, whether in an arrow function or not.
Repository: pytorch
Issue: torch.pow(tensor, tensor) throws RuntimeError for dtype bool 
Labels: triaged,module: numpy

## 🐛 Bug

`torch.pow(tensor, tensor)` doesn't work for dtype `bool`, although its method variant works.

## To Reproduce

Steps to reproduce the behavior:

1. Try `torch.pow(tensor, tensor)` for `bool` tensor.
2. On CPU, the runtime error is:
   `RuntimeError: "pow" not implemented for 'Bool'`.
   On CUDA, the runtime error is:
  `RuntimeError: "pow_cuda" not implemented for 'Bool'`

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior

numpy supports the function variant of power for bool, so PyTorch should too.

## Environment

Local build based on the current source code in the master branch.


cc @mruberry @rgommers @heitorschueroff
Repository: pytorch
Issue: torch.pow returns incorrect value for 0^0j
Labels: triaged,module: complex,module: numpy

```
>>> pow(0, 0j)
(1+0j)
>>> x=torch.zeros(2)
>>> x
tensor([0., 0.])
>>> torch.pow(x, x*1j)
tensor([nan+nanj, nan+nanj])
>>> np.power(np.array([0]), np.array([0j]))
array([1.+0.j])
```

cc @ezyang @anjali411 @dylanbespalko @mruberry @rgommers @heitorschueroff
Repository: go
Issue: x/build: use rr-project.org for running Go builds/tests on Linux?
Labels: Builders,NeedsInvestigation

We have a lot of intermittent failures on the builders, which are hard to reproduce. Evidently the Firefox project had similar struggles, so they built https://rr-project.org/, which allows recording and replaying program executions on linux/x86. Perhaps we should look into using it for our builders too?

Quickly skimming build.golang.org, it's not clear to me if there are enough flaky failures on linux/x86 to warrant the ~20% slowdown (according to their website). It seems like most flakiness is on non-linux or non-x86, unfortunately, and rr doesn't currently support any other platforms.

Maybe the regabi builder could benefit from it at least. It seems to have had some flakiness a couple weeks ago.

/cc @aclements @bcmills
Repository: pytorch
Issue: "Skipped!" tests should have more descriptive skipped reason
Labels: module: tests,triaged,enhancement

Currently we have

```
    # Creates device-specific tests.
    @classmethod
    def instantiate_test(cls, name, test, *, generic_cls=None):

        def instantiate_test_helper(cls, name, *, test, dtype, op):

            # Constructs the test's name
            test_name = _construct_test_name(name, op, cls.device_type, dtype)

            # wraps instantiated test with op decorators
            # NOTE: test_wrapper exists because we don't want to apply
            #   op-specific decorators to the original test.
            #   Test-sepcific decorators are applied to the original test,
            #   however.
            if op is not None:
                try:
                    active_decorators = []
                    if op.should_skip(generic_cls.__name__, name, cls.device_type, dtype):
                        active_decorators.append(skipIf(True, "Skipped!"))
```

The skip decorator here is very undescriptive and doesn't explain why the test was skipped. I believe that `should_skip` iterates through some list of skips 

```
    def should_skip(self, cls_name, test_name, device_type, dtype):
        return any(si.is_active(cls_name, test_name, device_type, dtype)
                   for si in self.skips)
```

Ideally `is_active` would explain why it is active, and then propagate that information to the decorator so we have a more descriptive skip reason.

cc @mruberry @VitalyFedyunin @walterddr
Repository: vscode
Issue: Problems from main vscode build or extensions build can be shown, not both when a file is closed
Labels: bug,tasks,confirmed

Testing #119471

- Follow steps in the linked item
- Have compile errors in the extension build and also the main build
- Open one of the files - the problems pane has errors from both builds
- Close that file - the problems pane only has errors from one of the builds

Seems random which one it is

![image](https://user-images.githubusercontent.com/323878/112387571-2d2cac80-8caf-11eb-9dd4-f5e865515b5a.png)

![image](https://user-images.githubusercontent.com/323878/112387600-387fd800-8caf-11eb-8d37-aa9e5a70f29f.png)
Repository: terminal
Issue: Shift modifer conficts between "disable mouse input" and "extend selection"
Labels: Area-Input,Area-TerminalControl,Product-Terminal,Issue-Task

### Windows Terminal version (or Windows build number)

1.6.10571

### Other Software

tmux 3.0a

### Steps to reproduce

In Windows terminal, if you have an existing selection and then make a new selection while the shift key is held, the beginning of the selection is not changed, but instead of the selection is extended.

If you are using an application that supports mouse input (tmux in my example, but this should hold true for any application that supports mouse input), you have to hold the shift key to disable mouse input so you can natively select text in the terminal.

These 2 features conflict with each other as they are on the same modifier key (shift).

A common pattern for me in tmux, is I want to highlight some text, so I shift+select, but I miss my desired start of the selection, so I attempt to shift+select again, but due to the "extend select" feature, it doesn't move my starting position.
There is no-way I can find to clear the current selection using the mouse. My only workaround is to type a character and delete it again to clear my selection.

### Expected Behavior

I would like to see a way to disable the "extend select" feature, or move it to a different modifier key, so it doesn't conflict.

### Actual Behavior

See Steps to reproduce
Repository: pytorch
Issue: torch-tensor-repr gdb macro doesn't seem to work in opt mode
Labels: triaged

```
(gdb) torch-tensor-repr *this
Python Exception <class 'gdb.error'> Couldn't find method at::Tensor::at::Tensor: 
Error occurred in Python: Couldn't find method at::Tensor::at::Tensor
```

guessing the method was inlined away lol

cc @antocuni
Repository: pytorch
Issue: Optional enhanced logging for operator calls for backend implementor debugging
Labels: triaged,module: backend

A long time ago @cpuhrsch described to me how he had inserted print statements to all operators so he could see what operators were being called for any given piece of Python code. I recently ran into a situation where having an easy to enable trace along these lines would have been helpful when debugging backend problems.

I think the profiler has most of the ingredients we need for this, we just need some simple observer that you can toggle with an env var and just prints out things as they happen.

cc @ilia-cher
Repository: rust
Issue: Hint to suggest annotating type to assist unsized coercion
Labels: A-diagnostics,T-compiler,A-coercions,A-suggestion-diagnostics,D-papercut,D-terse

It would be useful if we could suggest for users to add type annotations to assist in places where the compiler is unable to automagically infer an unsized coersion, e.g. when declaration is separated from usage by a `let` statement like [this code (playground link)](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=ef17fcd9ce4fe4c3e6fa735fed6e8ad2):

```rust
struct Wrapper<T>(T);

fn takes_any(x: Wrapper<Box<dyn std::any::Any>>) {}

fn test() {
    let x = Wrapper(Box::new(1i32));
    takes_any(x);
}
```

The current output is:

```
   Compiling playground v0.0.1 (/playground)
error[E0308]: mismatched types
 --> src/lib.rs:9:15
  |
9 |     takes_any(x);
  |               ^ expected trait object `dyn Any`, found `i32`
  |
  = note: expected struct `Wrapper<Box<(dyn Any + 'static)>>`
             found struct `Wrapper<Box<i32>>`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0308`.
error: could not compile `playground`

To learn more, run the command again with --verbose.
```

Ideally the output should also suggest adding an explicit type annotation to assist in unsizing, like:

```
 --> src/lib.rs:8:11
  |
8 |    let x: Wrapper<Box<dyn Any>> = Wrapper(Box::new(1i32));
  |           ^^^^^^^^^^^^^^^^^^^^^
help: Annotate the type when the value is created
```

This error can show up when users are refactoring their code to make lines shorter or more readable, and they might otherwise be confused why an innocuous change can lead to a pretty esoteric compiler error that doesn't suggest a clear fix. Unsure what the best "help" message should be, though!
Repository: TypeScript
Issue: In a JS file, using module.exports in a file changes the type of module from NodeModule to typeof import("...")
Labels: Suggestion,Awaiting More Feedback

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->
When using a JS file with `@types/node`, the type of `module` changes from `NodeModule` to something strange (`typeof import("/sandbox/not_working");`) after including a line like `module.exports = {}`.

### 🔎 Search Terms

<!--
  What search terms did you use when trying to find an existing bug report?
  List them here so people in the future can find this one more easily.
-->
module.exports, NodeModule, typeof import

### 🕗 Version & Regression Information

<!-- When did you start seeing this bug occur?

"Bugs" that have existed in TS for a long time are very likely to be FAQs; refer to
  https://github.com/Microsoft/TypeScript/wiki/FAQ#common-bugs-that-arent-bugs

If possible, please try testing the nightly version of TS to see if it's already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly

Note: The TypeScript Playground can be used to try older versions of TypeScript.

Please keep and fill in the line that best applies:
-->
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about `4.2.3`

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior

  The TypeScript Workbench can be used for more complex setups, try
  https://www.typescriptlang.org/dev/bug-workbench/

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
[CodeSandbox link with relevant code](https://codesandbox.io/s/typescript-playground-export-forked-7f4vc?file=/not_working.js)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```js
/// <reference types="node"/>
// INFO: This is JS

/**
 * @param {NodeModule} aModule
 */
function createLogger(aModule) {}

createLogger(module); // INFO: module here is triggering the error.

// INFO: THIS LINE BREAKS IT
module.exports = {};

```

### 🙁 Actual behavior

<!-- What happened, and why it was wrong -->
```
var module: {
    "\"/sandbox/not_working\"": typeof import("/sandbox/not_working");
}

Argument of type '{ "\"/sandbox/not_working\"": typeof import("/sandbox/not_working"); }'
is not assignable to parameter of type 'NodeModule'.

  Type '{ "\"/sandbox/not_working\"": typeof import("/sandbox/not_working"); }'
  is missing the following properties from type 'NodeModule': require, id, filename, loaded, and 3 more.

ts(2345)
```

### 🙂 Expected behavior

<!-- What you expected to happen instead, and why -->
I expected `module` to always be of type `NodeModule`.
Repository: PowerToys
Issue: add user-defined file-ext but supported format for "File Explorer add-ons utility"
Labels: Idea-New PowerToy,Product-File Explorer

Thanks to this power tool, I love the function named "Preview Pane" in "File Explorer add-ons utility", which supports markdown format.

However, some of my other markdown tools use different file-ext than simply .md or .markdown. Therefore, it would be great if there is an option to add user-defined file-ext, mapping to the supported format when previewed.

Thanks!
Repository: flutter
Issue: Proposal to add PageView.separated
Labels: c: new feature,framework,f: material design,c: proposal,team-design,triaged-design

I want to use PageView with a separate view like ListView.separated
Repository: pytorch
Issue: qsize not implemented error
Labels: module: multiprocessing,triaged,module: macos

## 🐛 Bug

<!-- A clear and concise description of what the bug is. -->

## To Reproduce

Steps to reproduce the behavior:
```
from torch.multiprocessing import Queue
queue = Queue()
print(queue.qsize())
```
Working at 1.5.0 ver (desktop, ryzen 2700)
NOT working at 1.7.1 ver (laptop, m1 chip macbook)
It seems like it is not the problem with just a version, but macbook version is not working on both my macbook pro 2011 early and macbook air m1 chip. 

It shows the NOT IMPLEMENTED error.


 - PyTorch Version (e.g., 1.0): 1.7.1 
 - OS (e.g., Linux): macos
 - How you installed PyTorch (`conda`, `pip`, source): pip install
 - Build command you used (if compiling from source):
 - Python version: 3.6
 - CUDA/cuDNN version:
 - GPU models and configuration:
 - Any other relevant information: macbook air m1

## Additional context

<!-- Add any other context about the problem here. -->
Repository: TypeScript
Issue: TypeScript incorrectly says return is not assignable to an intersection containing all the required props
Labels: Bug

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

& generic intersection omit spread

### 🕗 Version & Regression Information

- This is the behavior in every version I tried, and I reviewed the FAQ for entries about generics

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior

  The TypeScript Workbench can be used for more complex setups, try
  https://www.typescriptlang.org/dev/bug-workbench/

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
[Playground link with relevant code](https://www.typescriptlang.org/play?ts=4.3.0-dev.20210324&ssl=1&ssc=1&pln=20&pc=1#code/FAUwHgDg9gTgLgAgJYDs4hgMwIYGMQIBC2AziAAoxQQkIDewCyAJgPwBcCJcMqA5gG5GCFNgC2ITt14pBwAL7BQkWIjgBPCAUrUSAdSRwAFgElmAHnIJw6FM1rEyOmgD4EAXgQB5MYfPDyABphAHIkZhDgNwAyehYpHn4EeSFlaHgEZhAcAFcAG0RMHJRcOCQoFAQcpyoaA2MzS2swW3siUgpakhcACmEILs5yYABKIa760wtyNwYmXAruOPDOcOdAkXEQDYA6PahjDGSPBAHdIXnFxHCTtdqEVlYEAAMAEjpRCXkAWnDn1KYMBAcByMEqdBYG0+2wQex2ByMRxSCmAQA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
export interface BaseProps {
  id?: string;
  name: string;
}

export type PropsWithId<P extends BaseProps> = Omit<
  P,
  'id'
> & { id: string };

export default function usePropsWithId<P extends BaseProps>(
  props: P
): PropsWithId<P> {
  const { id: idProp, name, ...other } = props;
  const id = idProp ?? `${name}-id`;

  return { id, name, ...other };
}
```

### 🙁 Actual behavior

The return line gets this TypeScript error:

```
Type '{ id: string; name: string; } & Omit<P, "id" | "name">' is not assignable to type 'PropsWithId<P>'.
  Type '{ id: string; name: string; } & Omit<P, "id" | "name">' is not assignable to type 'Omit<P, "id">'.
```

This doesn't make sense since `PropsWithId<P>` is `Omit<P, 'id'> & { id: string };`

### 🙂 Expected behavior

This should work without a TypeScript error.
Repository: TypeScript
Issue: Suggestion: Allow getters to have predicate return types
Labels: Suggestion,Awaiting More Feedback

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

## 🔍 Search Terms

getter, predicate, type guard

## ✅ Viability Checklist

My suggestion meets these guidelines:

* [✅] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [✅] This wouldn't change the runtime behavior of existing JavaScript code
* [✅] This could be implemented without emitting different JS based on the types of the expressions
* [✅] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [✅] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

This has been requested before (e.g., #6994) but declined because at the time getters were merely an aspect of implementation. Since that is [no longer the case](https://github.com/microsoft/TypeScript/issues/43036#issuecomment-790858039), would there be any interest in revisiting the suggestion?

## 📃 Motivating Example
```ts
class Person {
    name?: string;
}

class Thing {
    constructor(public owner: Person | null = null) {}

    get isOwned(): this is Owned<this> {
      return !!this.owner;
    }
}

type Owned<T extends Thing> = T & { owner: NonNullable<T['owner']> };
```

## 💻 Use Cases

I have a use case much like the above. Currently type narrowing by checking `thing.owner` isn't honored when `thing` is used as a function argument:
```ts
function doSomethingWithOwnedThing(ownedThing: Owned<Thing>) {}

declare const thing: Thing;

if (thing.owner) {
    thing.owner.name; // ok
    doSomethingWithOwnedThing(thing); // not ok (thing.owner is possibly `null`)
}
```
With the above, I can create a normal function or method that returns a type predicate or otherwise simply assert that `thing` is an `Owned<Thing>`. Given that user-defined type guards are encapsulated type assertions, and getters are shiny and neat, a boolean getter that doubles as a type guard would be nicest.
Repository: PowerToys
Issue: Preserve Window position when a session is moved to RDP and back
Labels: Idea-New PowerToy

I would like to preserve the exact position (over multiple monitors) of the windows when I take remote control of a session (without logging off first).
The steps are:
- log on locally on a machine with 3 monitors and open multiple windows over the three
- the session is now locked (win-L)
- open an RDP session from another PC having 2 monitors (and with the rdp client set to use multiple monitors)
The current behavior is to open all the windows in the first monitor

I would like a setting so that the windows positions are preserved as well as the owning monitor.
Since the number of monitors is different I would expect the "exceeding windows" to fall back in the previous. In my example the windows belonging to monitor number 3 to be opened on the number 2 instead.

**Notes**
1. I tried to simulate this behavior with the fancy zones, but I could not because windows can be moved around and do not really belong to a zone. I am just willing to simulate the same experience when the session is moved remotely.
2. It should work also in the opposite direction. If you open a new window when you are connected remotely, it should be restored in the same position/monitor when you log in back to the local machine.

It is probably more complicated to explain than getting it done :)
Repository: ant-design
Issue: even if set Tree expandedKey = [], async loaded children are still rendered
Labels: 🐛 Bug,Inactive

- [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/yibushujujiazai-antd4123-forked-1qw1f?file=/index.js)

### Steps to reproduce
1. set expandedKey = []
2. click to expand node

### What is expected?
async children are not rendered

### What is actually happening?
The node is not expanded but async children are rendered

| Environment | Info |
|---|---|
| antd | 4.12.3 |
| React | 16.14.0 |
| System | Windows |
| Browser | Chrome |


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: react
Issue: Bug: Radio/Checkbox inputs not triggered when setting state in listener on a parent element
Labels: Type: Bug,Component: DOM,Status: Unconfirmed

Hello

I wanted to highlight a div after clicking on it (and hide the highlight after clicking anywhere else). So in componentDidMount, I added two event listeners (on the div and on the window object).
The problem is kind of wild: when I use setState in a listener added in componentDidMount, radio buttons are not triggered.
When the listener does not use setState or uses setTimeout(() => this.setState(...), 0), radio buttons works expectedly.
When creating a code example, I also tried checkboxes, and they do not work as well. BUT, for example, button inputs work expectedly.

React version: 16.13.1 (in my app), 17.0.2 (in code sand box) - issue is in both of them

## Steps To Reproduce

You can use this prepared code example: https://codesandbox.io/s/react-setstate-listener-input-bug-wjsdk
The example also shows other listeners set ups which work expectedly.

## Current possible workaround

As mentioned earlier, we can use setTimeout(() => this.setState(...), 0) to gain expected behavior, but it is not a bug fix.