sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Git - Add note about creating SSH keys to the "Clone a repo" onboarding task
Labels: feature-request,git

<!-- ⚠️⚠️ 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. -->

When completing the clone a repo task in the onboarding experience, the item was marked as complete once I pasted in a GitHub URL and clicked enter, but I ended up running into a (somewhat cryptic) error immediately afterward because I didn't have my GitHub SSH keys set up on my machine yet. 

I figure this will be a non-issue for most developers who have had the experience of setting up a new dev machine more than a few times. However, I could see that being an **_incredibly_** confusing state to end up in if I were a new coder just getting started.

As a result, I think it might be really nice to explore the inclusion of some kind of note telling people to make sure they have SSH keys correctly configured (with links to the relevant GitHub docs) to hopefully keep the VS Code onboarding process smooth for new devs.
Repository: pytorch
Issue: [MetaIssue] Investigate if we should be reusing primtorch formulas for `is_dynamic`
Labels: triaged,lazy

1. Investigate how hard it would be to integrate https://github.com/pytorch/pytorch/blob/1c1c68b1e31351030843c773e73fab736cbfaf1b/torch/_meta_registrations.py formulas to compute `is_dynamic` in LTC
2. Cross reference how many MaskRCNN ops that are not covered with existing SSA shape functions already have shape functions in https://github.com/pytorch/pytorch/blob/1c1c68b1e31351030843c773e73fab736cbfaf1b/torch/_meta_registrations.py and decomps in https://github.com/pytorch/pytorch/blob/master/torch/_decomp/decompositions.py
3. Sync with @ezyang about his timeline maybe it would be possible to prioritize some ops for MaskRCNN?
4. Benchmark JIT SSA vs meta shape propagations.
5. Communicate to Google if we decide to transition to meta functions
6. If we decide to transition to meta functions: E2E PoC. Hopefully this will build enough infrastructure.
7. If we decide to transition to meta functions:  Migration plan

This is based on @Gamrix 's doc: https://docs.google.com/document/d/1DhNxC9mtQdSXOktlSIoAKUCgN95Dx998FHcoPhJdJU8/edit#heading=h.l6gc8x2z7bv5
Repository: next.js
Issue: [NEXT-776] commonjs types for `next/jest` are incorrect
Labels: TypeScript,linear: next

### Verify canary release

- [X] I verified that the issue exists in Next.js canary release

### Provide environment information

    Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 21.4.0: Fri Mar 18 00:46:32 PDT 2022; root:xnu-8020.101.4~15/RELEASE_ARM64_T6000
    Binaries:
      Node: 16.15.1
      npm: 8.11.0
      Yarn: 1.22.18
      pnpm: N/A
    Relevant packages:
      next: 12.1.7-canary.31
      react: 17.0.2
      react-dom: 17.0.2

### What browser are you using? (if relevant)

Not applicable

### How are you deploying your application? (if relevant)

Not applicable

### Describe the Bug

Using the boilerplate from the documentation for [Setting up Jest (with the Rust Compiler)](https://nextjs.org/docs/testing#setting-up-jest-with-the-rust-compiler) and with `tsconfig.json#compilerOptions.checkJs` enabled a type-error is generated.

```bash
error TS2349: This expression is not callable.
  Type 'typeof import("/{projectPath}/node_modules/next/jest")' has no call signatures.

4 const createJestConfig = nextJest({
                           ~~~~~~~~
```

The issue appears to be with the commonjs/esm interoperability layer, because:

### Known Workarounds

If you bypass the `next/jest` entrypoint and its interoperability layer, and instead `require` from the `dist/build` folder then it works as expected. Ie.

```diff
- const nextJest = require("next/jest");
+ const nextJest = require("next/dist/build/jest/jest").default;
```

### Expected Behavior

There should be no type-errors when using `next/jest` as documented and with `checkJs` enabled.

### To Reproduce

1. Install `typescript` and `next`.
2. Create a javascript file (nominally called `jest.config.js`) and populate it with the contents of the code-snippet in [Setting up Jest (with the Rust Compiler)](https://nextjs.org/docs/testing#setting-up-jest-with-the-rust-compiler).
3. Add a `tsconfig.json` and ensure that `compilerOption.allowJs` and `compilerOption.checkJs` are both set to `true`, so that the `jest.config.js` file is typechecked.

See [here](https://codesandbox.io/s/little-water-f1l0wj?file=/jest.config.js) for a minimal reproducible example.

<sub>[NEXT-776](https://linear.app/vercel/issue/NEXT-776/commonjs-types-for-nextjest-are-incorrect)</sub>
Repository: pytorch
Issue: Mirror and implement `SymbolicIntNode` API for `SymInt` so we can trace in C++
Labels: triaged,lazy
Repository: pytorch
Issue: [MetaIssue] Propagating SymInts through Autograd
Labels: triaged,lazy

* a scalar grad check relies on numel
* support implicit reductions
	* sum_to
	* is_expandable_to
* add SymInt overload to zeros
* codegen to use sym_sizes for ops w/ symint overloads in derivative formulas
* InputMetadata to use SymInt
Repository: flutter
Issue: [go_router] Support hot-reload
Labels: c: new feature,t: hot reload,package,c: proposal,P3,p: go_router,team-go_router,triaged-go_router

It's currently not possible to update the `routes` list when the app is hot-reloaded. 

For example, adding a route such as "/page3" to [example/lib/main.dart](https://github.com/flutter/packages/blob/main/packages/go_router/example/lib/main.dart) and hot-reloading will have no effect. 

GoRouter could be changed to a Widget, or we could recommend defining GoRouter in the build method:

```dart
class App extends StatelessWidget {
  App({Key? key}) : super(key: key);

  static const String title = 'GoRouter Example: Declarative Routes';

  @override
  Widget build(BuildContext context) {
    final GoRouter _router = GoRouter(
      routes: <GoRoute>[
        GoRoute(
          path: '/',
          builder: (BuildContext context, GoRouterState state) =>
          const Page1Screen(),
        ),
        GoRoute(
          path: '/page2',
          builder: (BuildContext context, GoRouterState state) =>
          const Page2Screen(),
        ),
      ],
    );
    return MaterialApp.router(
      routeInformationParser: _router.routeInformationParser,
      routerDelegate: _router.routerDelegate,
      title: title,
    );
  }
}
```

The above example throws a runtime exception if you add "/page3" and try to navigate to it:

![Screen Shot 2022-06-07 at 1 39 53 PM](https://user-images.githubusercontent.com/1145719/172478302-8d342e27-253f-4113-aae7-148b72e3a78e.png)

cc: @rrousselGit
Repository: pytorch
Issue: Multi-node, Multi-GPU set up tutorial for Slurm cluster
Labels: oncall: distributed,triaged

### 🚀 The feature, motivation and pitch

We need to have a tutorial/doc about setting up Multi-node, Multi-GPU environment for Slurm cluster. https://github.com/aivanou/disttraining/tree/main/slurm is a good starting point, but we need to furnish it and make sure it works and publish a tutorial/doc on it.

### Alternatives

_No response_

### Additional context

_No response_

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @kwen2501
Repository: TypeScript
Issue: Allow inferring a type alias for derived return types
Labels: Suggestion,Awaiting More Feedback

# Suggestion

## 🔍 Search Terms
function inferred return type alias

## ✅ Viability 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, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion
It would be extremely convenient if a function were able to declare a type alias for its return type inline. A possible syntax for this could be:
```typescript
const createCounter = (): infer Counter => {
  const result = {
    count: 0,
    increment: () => ++result.count,
  };
  return result;
};
```

This would create a type alias automatically, allowing usage like:
```typescript
import { Counter, createCounter } from './counter';
```

## 📃 Motivating Example
Currently, a class declaration automatically emits a type for the resulting constructor function. However, if an object is created with a standard function, this is not possible. The inferred return type of functions can be aliased like:

```typescript
// aliased type:
// type Counter = {
//   get: () => number;
//   increment: () => number;
// }
export type Counter = ReturnType<typeof createCounter>;

const createCounter = () => {
  const result = {
    count: 0,
    increment: () => ++result.count,
  };
  return result;
};
```
This is an powerful pattern, as it allows the implementation to be the source of reference for the type, rather than the other way around. However, while the aliased type is derived from the function, the function itself does not return the aliased type.

```typescript
// type is:
// const counter: {
//   get: () => number;
//   increment: () => number;
// }
// NOT Counter
const counter = createCounter();
```

In order to use the derived type, there are 2 options, both of which are clumsy:
* Put the onus on the caller to explicitly use the type:
```typescript
import { Counter, createCounter } from './counter';

const counter: Counter = createCounter();
```
* Create a superfluous higher order function:
```typescript
export type Counter = ReturnType<typeof createCounterInternal>;

export const createCounter = (): Counter => createCounterInternal();

const createCounterInternal = () => {
  // counter impl
};
```

## 💻 Use Cases
Any function that returns a complex object could benefit from this.
Repository: pytorch
Issue: CI workflow creates too many tags in RSS feed
Labels: module: ci,triaged

Hi, I use GitHub's RSS feed to track the release of many repos. However, it seems that the PyTorch RSS feed is flooded by CI workflow (see https://github.com/pytorch/pytorch/releases.atom and https://github.com/pytorch/pytorch/tags). 

Is it possible that CI workflow is no longer tagged so that I receive only updates for important builds in the RSS feed? 

cc @seemethere @malfet @pytorch/pytorch-dev-infra
Repository: TypeScript
Issue: Assert in getDiagnosticHeadMessageForDecoratorResolution
Labels: Bug,Rescheduled

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 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.
-->

Decorators

### 🕗 Version & Regression Information

New in 4.8, AFAIK.  Still present as of 4c5060181ffcdc00dfcc6ec1d7d34a3ea2c2c1e1.

- This is an assert in the LS - it probably only causes an empty GTD result, which is probably correct in bad code


### 💻 Code

```ts
* @name toArray
*/
toArray(): HTMLElement[];
```

Note: I didn't forget to copy the `/**` - it's absent.

Invoke GTD (F12 or ctrl-click) on `name`.

### 🙁 Actual behavior

```
Error: Debug Failure.
    at getDiagnosticHeadMessageForDecoratorResolution (built\local\tsserver.js:76853:37)
    at resolveDecorator (built\local\tsserver.js:76875:31)
    at resolveSignature (built\local\tsserver.js:76952:28)
    at getResolvedSignature (built\local\tsserver.js:76977:26)
    at getResolvedSignatureWorker (built\local\tsserver.js:48519:21)
    at Object.getResolvedSignature (built\local\tsserver.js:48335:24)
    at tryGetSignatureDeclaration (built\local\tsserver.js:140299:53)
    at getDefinitionAtPosition (built\local\tsserver.js:139932:37)
    at Object.getDefinitionAndBoundSpan (built\local\tsserver.js:140108:31)
    at Object.getDefinitionAndBoundSpan (built\local\tsserver.js:165565:38)
    at IpcIOSession.Session.getDefinitionAndBoundSpan (built\local\tsserver.js:176706:83)
    at Session.handlers.ts.Map.ts.getEntries._a.<computed> (built\local\tsserver.js:175950:61)
    at built\local\tsserver.js:178103:88
    at IpcIOSession.Session.executeWithRequestId (built\local\tsserver.js:178094:28)
    at IpcIOSession.Session.executeCommand (built\local\tsserver.js:178103:33)
    at IpcIOSession.Session.onMessage (built\local\tsserver.js:178129:35)
```

Falls off the end of a switch because there's not case for `MissingDeclaration`.

### 🙂 Expected behavior

No assert.
Repository: pytorch
Issue: Improve PrimTorch testing for view consistency.
Labels: module: tests,triaged,module: viewing and reshaping,module: primTorch

### 🚀 The feature, motivation and pitch

Currently, we check view consistency by checking if `a._is_view` and `b._is_view` are both correct: https://github.com/pytorch/pytorch/blob/master/test/test_ops.py#L394

However, this is not particularly correct. As @ezyang notes (https://github.com/pytorch/pytorch/pull/78994#discussion_r891721598), view is an autograd concept. Thus, even though the ATen version of stack returns a view (https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/TensorShape.cpp#L2213), `a._is_view` returns False for the ATen implementation.

This is problematic for a variety of ops, including `rot90`: https://github.com/pytorch/pytorch/pull/78080#discussion_r885104613

cc: @mruberry @ngimel @ezyang 

### Alternatives

_No response_

### Additional context

_No response_

cc @mruberry @ezyang @ngimel
Repository: node
Issue: Pasting very long strings freezes node REPL on MacOS
Labels: repl,macos

### Version

18.3.0

### Platform

Darwin SoMuchBiggerOnTheInside-2.local 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar 18 00:45:05 PDT 2022; root:xnu-8020.101.4~15/RELEASE_X86_64 x86_64

### Subsystem

_No response_

### What steps will reproduce the bug?

- Open iTerm2 version 3.4.15 and start a new node REPL session.
- Ignoring the comment on the first line, copy the first 3,500 characters of the jQuery v3.6.0 minified library (https://code.jquery.com/jquery-3.6.0.min.js) into the REPL. The REPL will freeze.
- Open a new tab, start a new node REPL, and paste ~2,000 characters of the library into the REPL. The code will be cut short. You can copy and paste new chunks of text into the REPL, as long as you keep your text less than ~2,000 - 3,500 characters in length. However if you paste more than that, the REPL will freeze. 
- Use this formatter to format the jquery library (don't make any changes to the default settings for the formatter): https://webformatter.com/javascript
- Paste the first 128 lines into the REPL (including the first comment line). This is 3,906 characters. The REPL will display errors and only show part of the code you have pasted, but will not freeze. 
- The 129th line is the beginning of a for statement. Copying all of the text up until the end of the keyword `for` (but before the `(`) and pasting this into the REPL will cause it to freeze. If you only copy a part of the word `for` it won't freeze.

### How often does it reproduce? Is there a required condition?

I can replicate these symptoms every time. Note that I can paste the entire jQuery library into a Python REPL (in the same iTerm2 tab) without any freezing at all. The fact that the `for` keyword changes behavior makes me think the error is happening when parsing the language. It may be a regression of #32999 (or a similar bug, for Macs), but pasting the 1000 "a" commands in the gist below (mentioned in  #32999 comments) does not cause the REPL to freeze. 

https://gist.githubusercontent.com/bzoz/bba634114402fee35554f4972a0887b6/raw/c71217ab21ecdf8d6e0874e955fe3b780df4e89f/aaaaaa.txt


### What is the expected behavior?

I expect the REPL to accept the pasted text.

### What do you see instead?

The REPL freezes or only shows part of the pasted text.

### Additional information

_No response_
Repository: pytorch
Issue: Error with Named Tensors and multiple threads
Labels: triaged,module: named tensor

### 🐛 Describe the bug

When using Named Tensors I got an exception when the number of operations was too large.
Steps to reproduce:
```python
torch.randn((50000, 2), names=('K', 'M')).mean('M').mean('K')
```
We get the exception:
```
RuntimeError: aten::unsqueeze is not yet supported with named tensors. Please drop names via `tensor = tensor.rename(None)`, call the op with an unnamed tensor, and set names on the result of the operation.
```
However, if we instead run
```python
torch.randn((500, 2), names=('K', 'M')).logsumexp('M').mean('K')
```
we get no errors.
Moreover, if we run the original code but without multithreading, there is no error either:
```python
torch.set_num_threads(1)
torch.randn((50000, 2), names=('K', 'M')).mean('M').mean('K')
```


### Versions

```
Collecting environment information...
PyTorch version: 1.11.0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.4 (x86_64)
GCC version: Could not collect
Clang version: 13.1.6 (clang-1316.0.21.2.5)
CMake version: version 3.11.1
Libc version: N/A

Python version: 3.9.7 (default, Sep  3 2021, 12:45:31)  [Clang 12.0.0 (clang-1200.0.32.29)] (64-bit runtime)
Python platform: macOS-10.16-x86_64-i386-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.22.4
[pip3] torch==1.11.0
[pip3] torchaudio==0.11.0
[pip3] torchvision==0.12.0
[conda] Could not collect
```

cc @zou3519
Repository: flutter
Issue: Ensure system channels report errors of handlers in the framework instead of sending errors to the engine
Labels: framework,a: error message,P2,team-framework,triaged-framework

We should make the handlers of system channels set by `setMethodCallHandler` report their internal exceptions with `FlutterError.reportError` instead of sending them to the engine. This makes debugging much easier and prevents engine components that do not properly handle errors from swallowing them.

Issue [#104578](https://github.com/flutter/flutter/issues/104578#issuecomment-1138583802) demonstrates the confusion caused by the current way. The exception is silently caught and converted to an error response to the engine, but the engine did not handle the error, and instead went into an unstable state, only failing way later without a proper stacktrace.

This is fixed by https://github.com/flutter/flutter/pull/104711 for the text channel particularly (which also discovered another bug: https://github.com/flutter/flutter/pull/104711#discussion_r891705313), but not to others. We probably shouldn't make it the default behavior for all method channels, because some might use the error response, but we should probably make all system channels in Flutter do so.
Repository: go
Issue: x/build/internal/task: update postTweet to Twitter API v2 when possible
Labels: Builders,NeedsInvestigation

The tweet task currently uses Twitter API v1.1. We can't fully update to Twitter API v2 because the media endpoints aren't available there yet. This is the tracking issue for updating when it's possible.

See:

- https://developer.twitter.com/en/docs/twitter-api/migrate/twitter-api-endpoint-map
- https://twittercommunity.com/t/v1-1-media-endpoints-available-for-essential-access-in-the-twitter-api-v2/171664
- https://twittercommunity.com/t/post-tweet-media-upload-in-v2/148590/20
Repository: PowerToys
Issue: Improved string pattern matching for PowerRename
Labels: Idea-Enhancement,Product-PowerRename,Needs-Triage,Needs-Team-Response

### Description of the new feature / enhancement
Improved string pattern matching for PowerRename

Wildcards, digits from left/right, Sentence case, user filter list (all CAPS conventions), cycle through all conditions until they are changed, auto close when complete, allow only one instance, file HERE when done.....

### Scenario when this would be used?

Everytime we use PowerRename

### Supporting information

_No response_
Repository: rust
Issue: Recovering from keyword identifier mentions raw identifier that never appeared in the source code later
Labels: A-diagnostics,T-compiler

```rust
fn main() {
    let while;
}
```
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=92d99a1b9f37c71ce9f5a5b26f511489
```
error: expected identifier, found keyword `while`
 --> src/main.rs:2:9
  |
2 |     let while;
  |         ^^^^^ expected identifier, found keyword
  |
help: escape `while` to use it as an identifier
  |
2 |     let r#while;
  |         ++

error[E0282]: type annotations needed
 --> src/main.rs:2:9
  |
2 |     let while;
  |         ^^^^^ consider giving `r#while` a type
```
The second error refers to `r#while` while we wrote `while`, because we recover as if we've written a raw identifier. Feel free to close if this is not a problem.
Repository: rust
Issue: process::Command data loss when using Stdio::inherit for stdin and stdin has been read from
Labels: C-bug,T-libs,A-process

I tried this code:

```rust
Command::new(command).
...
.stdin(Stdio::inherit())
```

In this case, I had already read a few bytes from stdin using `stdin()` and `read_exact`.  strace showed that it read 8K from stdin, and that the command started missed the remainder of the 8K.  #58326 discusses this in a roundabout way, but fundamentally it should be safe to read from stdin and then subsequently use it as input to a Command.  The workaround was to use `.stdin(Stdio::piped())` and copy the data across the pipe.  Not ideal.

### Meta
`rustc --version --verbose`:
```
rustc 1.60.0 (7737e0b5c 2022-04-04)
binary: rustc
commit-hash: 7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c
commit-date: 2022-04-04
host: x86_64-unknown-linux-gnu
release: 1.60.0
LLVM version: 14.0.0
```
Repository: storybook
Issue: ResetWrapper is not longer directly exported from @storybook/components
Labels: bug,needs triage

**Describe the bug**
A clear and concise description of what the bug is.

Since 6.5.0 ResetWrapper is no longer exported directly from @storybook/components. This was an unexpected breaking change.

**To Reproduce**
Please create a reproduction by running `npx sb@next repro` and following the instructions. Read our [documentation](https://storybook.js.org/docs/react/contribute/how-to-reproduce) to learn more about creating reproductions.
Paste your repository and deployed reproduction here. We prioritize issues with reproductions over those without.

**System**
Please paste the results of `npx sb@next info` here.

**Additional context**
Add any other context about the problem here.