sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Move randperm() to DistributionTemplates
Labels: triaged,module: random,csprng

To [support randperm](https://github.com/pytorch/csprng/issues/71) in [csprng](https://github.com/pytorch/csprng) it's required to templatize with RNG and move randperm implementation to DistributionTemplates.h, cpu/DistributionTemplates.h and cuda/DistributionTemplates.h

Add a test in cpu_rng_test.cpp

See:
https://github.com/pytorch/pytorch/issues/37368
https://github.com/pytorch/pytorch/issues/37369
https://github.com/pytorch/pytorch/issues/37370
https://github.com/pytorch/pytorch/issues/37371

cc @pbelevich
Repository: TypeScript
Issue: Cannot assign generic type aliases that should be equivalent.
Labels: Bug,Fix Available

Cannot assign generic type aliases that should be equivalent.

Simple test case:

```ts
export type Example<TData>
    = (data: TData | null | undefined) => string | null;

function foo<T>()
{
    let x: Example<T> = undefined!;
    let y: Example<T | null | undefined> = undefined!;

    y = x;

    let x1: (data: T | null | undefined) => string | null = undefined!;
    let y1: (data: (T | null | undefined) | null | undefined) => string | null = undefined!;

    y1 = x1
}
```

Note that 'x' is not assignable to 'y' with `strictNullChecks` on.  It results in the error:

```
Type 'Example<T>' is not assignable to type 'Example<T | null | undefined>'.
  Type 'T | null | undefined' is not assignable to type 'T'.
    'T' could be instantiated with an arbitrary type which could be unrelated to 'T | null | undefined'.
      Type 'undefined' is not assignable to type 'T'.
        'T' could be instantiated with an arbitrary type which could be unrelated to 'undefined'.(2322)
```

This seems very strange though.  `Example` is just a type alias, which shouldn't have an impact on assignability.  If we simply expand the type alias, we get the `x1/y1` case.  In the expanded form the compiler allows this just fine.

Note: this was working in 3.3. It does not seem to work on 4.0.  I'm not sure at what point it may have broken.
Repository: godot
Issue: Godot 3.2.3 RC4 / 3.2.2-Stable "Couldn't open external text editor, using internal" error when trying to use VS Code
Labels: bug,platform:windows,topic:editor

**Godot version:**
Godot 3.2.3 RC4 non-mono build


**OS/device including version:**
Windows 10
GLES3


**Issue description:**
I created a new project and configured Godot to use an external editor (Visual Studio Code). Upon creating a GDScript file VS Code does not open it - it reverts back to the old editor.

I see the following error in the Output console:
![error](https://user-images.githubusercontent.com/8476589/91630153-69967380-ea12-11ea-82c2-1fc49ac11230.png)

![2](https://user-images.githubusercontent.com/8476589/91630164-82068e00-ea12-11ea-93e0-3b0c51692689.png)



**Steps to reproduce:**
1 - Create a new Godot project
2 - Under Editor settings enable 'Use External Editor'
3 - For Exec Path, point it to the visual studio code executable file
4 - For Exec Flags, use either "{file}" or "{project} --goto {file}:{line}:{col}". It does not matter it's the same error.
5 - Press Close
6 - Attach a new script to a node and check the Output console to see the error.
![4](https://user-images.githubusercontent.com/8476589/91630189-c134df00-ea12-11ea-972a-a27e691b6dfc.png)


**Minimal reproduction project:**
N/A
Repository: node
Issue: regression: `require.resolve()` caches `package.json` when it shouldn't
Labels: module

<!--
Thank you for reporting an issue.

This issue tracker is for bugs and issues found within Node.js core.
If you require more general support please file an issue on our help
repo. https://github.com/nodejs/help


Please fill in as much of the template below as you're able.

Version: output of `node -v`
Platform: output of `uname -a` (UNIX), or version and 32 or 64-bit (Windows)
Subsystem: if known, please specify affected core module name
-->

* **Version**: 12+
* **Platform**: any
* **Subsystem**: any

### What steps will reproduce the bug?

Repro at:
https://runkit.com/andreialecu/5f4a0a45b7d56e001a469c1e

```js
const {readFileSync, writeFileSync, mkdirSync} = require(`fs`);
const {join} = require(`path`);
//const rimraf = require(`rimraf`);

//rimraf.sync("./node_modules/foo");
mkdirSync("./node_modules");
mkdirSync("./node_modules/foo");
writeFileSync("./node_modules/foo/bad.js", "module.exports = 'WRONG'");
writeFileSync("./node_modules/foo/good.js", "module.exports = 'CORRECT'");

writeFileSync(`./node_modules/foo/package.json`, JSON.stringify({
  name: 'foo',
  main: "bad.js",
}, null, 2));

// this caches the entry file and it cannot be updated
// comment it out for different output:
console.log(require.resolve(`foo/package.json`));

writeFileSync(`./node_modules/foo/package.json`, JSON.stringify({
  name: 'foo',
  main: "good.js",
}, null, 2));

console.log(require.resolve(`foo`));
console.log(require(`foo`));
```

### How often does it reproduce? Is there a required condition?

Always.

### What is the expected behavior?

I think `require.resolve` should not commit anything to cache (as opposed to `require()`). On node versions `<12` this problem didn't exist, so it may be a regression. 

### What do you see instead?

The `main` entry point of the resolved dependency is cached and sticks for the duration of the process. 

### Additional information

The use case is checking whether the version of a dependency needs updating, and if it does, run `npm/yarn install` to update it (as part of a cli tool, `@angular/cli` in this case). 

After the update finishes, the package would still load as the old version. I expect `require()` to cache it, but not `require.resolve()`. It resulted in a very hard to track bug while working on an issue in the `@angular/cli` repository. Additional info in: https://github.com/angular/angular-cli/pull/18610
Repository: storybook
Issue: Maximum update depth exceeded depending on order of decorators
Labels: question / support,compatibility with other tools,react

**Describe the bug**
I think that this bug is an effect of a combination between the react-final-form and storybook implementations, possibly it's a problem when the decorator contain a component that uses render prop. It's also possible that this is entirely a problem with react-final-form but I've never seen this issue in any other context that I've used that library. The example below reproduce the error message. By switching the order of the decorators, i.e. having the final-form decorator first and the div-wrapper decorator last, makes it go away.

**To Reproduce**
Init CRA project,
`npx create-react-app example --template typescript`
`cd example`

Init storybook
`npx sb init`

Install final-form and react-final-form
`yarn add final-form react-final-form`

Add the following story in the stories directory
```JSX
// Test.stories.tsx
import React from 'react'
//eslint-disable-next-line
import { Story, Meta } from '@storybook/react/types-6-0'
import { Form, Field } from 'react-final-form'

export default {
  title: 'Test',
} as Meta

export const FinalFormTest = () => <Field name="test" component="input" />

const noop = () => {};

/**
 * Change the order of these decorators to make maximum update depth 
 * exceeded error dissappear.
 */
FinalFormTest.decorators = [
  (Story: Story) => (
    <div>
      <Story />
    </div>
  ),
  (Story: Story) => (
    <Form onSubmit={noop}>
      {({ handleSubmit }) => (
          <form onSubmit={handleSubmit}>
            <Story />
          </form>
      )}
    </Form>
  ),
]
```

**Expected behavior**
The decorators should not depend on the order they are defined. Would expect to be able to have the final-form decorator wrapped by the div decorator without getting an exception.

**System:**
System:
    OS: macOS 10.15.6
    CPU: (4) x64 Intel(R) Core(TM) i5-4670 CPU @ 3.40GHz
  Binaries:
    Node: 14.8.0 - /usr/local/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.7 - /usr/local/bin/npm
  Browsers:
    Chrome: 84.0.4147.135
    Safari: 13.1.2
  npmPackages:
    @storybook/addon-actions: ^6.0.20 => 6.0.20
    @storybook/addon-essentials: ^6.0.20 => 6.0.20
    @storybook/addon-links: ^6.0.20 => 6.0.20
    @storybook/node-logger: ^6.0.20 => 6.0.20
    @storybook/preset-create-react-app: ^3.1.4 => 3.1.4
    @storybook/react: ^6.0.20 => 6.0.20
Repository: PowerToys
Issue: [KBM] Specify multiple targets applications
Labels: Idea-Enhancement,Help Wanted,Product-Keyboard Shortcut Manager

## 📝 Provide a description of the new feature

It would be great to have the possibility to specify multiple targets in "Remap shortcuts" (comma separated, semicolon separated or space separated)

![image](https://user-images.githubusercontent.com/19806799/91634027-7359b000-e9ed-11ea-9c8b-13373ef2b0ca.png)
_________________________________________________________________
If you'd like to see this feature implemented, add a 👍 reaction to this post.
Repository: rust
Issue: regression: #[forbid(unreachable_code)] incompatible with the Try ('?') operator
Labels: A-lints,E-needs-test,P-low,T-compiler,C-bug

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code:

```rust
#![forbid(unreachable_code)]

#[allow(dead_code)] // Remove warning.
fn foo() -> Option<()> {
    Some(0)?;
    None // Just so it doesn't emit error here.
}
```

Both on debug and release it generates an error saying that `#[allow(unreachable_code)]` was overridden by the `#[forbid(...)]` attribute, while pointing at the "try" expression.

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.46.0 (04488afe3 2020-08-24)
binary: rustc
commit-hash: 04488afe34512aa4c33566eb16d8c912a3ae04f9
commit-date: 2020-08-24
host: x86_64-pc-windows-msvc
release: 1.46.0
LLVM version: 10.0
```
Repository: go
Issue: x/pkgsite: handle packages from an archived repo specially
Labels: NeedsInvestigation,FeatureRequest,pkgsite

If a repo has been archived (as described for GItHub [here](https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/archiving-repositories)), we should reduce its search rank, and add an indicator to  its pages.
Repository: rust
Issue: Removing FatalErrors from StringReader
Labels: C-cleanup,A-diagnostics,A-parser,T-compiler

[`StringReader`](https://github.com/rust-lang/rust/blob/1dc748fb3d2c54f536e6abd74f1ad34b3624f640/src/librustc_parse/lexer/mod.rs#L30) uses a bunch of Fatal (panicking) errors:

https://github.com/rust-lang/rust/blob/1dc748fb3d2c54f536e6abd74f1ad34b3624f640/src/librustc_parse/lexer/mod.rs#L30

(search for `.raise`)

All of these unwinding errors should be replaced with "normal" error reporting. But we probably need to make sure that we won't cause cascading errors.
Repository: excalidraw
Issue: Further simplify simple line editing?
Labels: discussion

#2090 added rotation to lines, which greatly improved the UX. Have we considered moving 2 points entirely away from the "bounding box" idea? This reintroduces normalization, but instead of having no angles (situation pre-2090), it would the assumption that new lines are created at 0 angle.

Like this:

<img width="720" alt="Screen Shot 2020-08-29 at 16 45 26" src="https://user-images.githubusercontent.com/1473433/91639570-e5df8580-ea17-11ea-92f5-d792ba024719.png">

Or more simply:

<img width="614" alt="Screen Shot 2020-08-29 at 16 52 14" src="https://user-images.githubusercontent.com/1473433/91639590-04de1780-ea18-11ea-9d04-29f93b0ff3c0.png">

If you added a point to the 2-point line it would turn it into a classic bounding box object, and likely should reset the angle to 0.
Repository: TypeScript
Issue: Tuple should be readonly by default
Labels: Suggestion,Awaiting More Feedback

Any tuples can mutate, this entails incorrect typing

**TypeScript Version:**  4.1.0-dev.20200828

**Search Terms:**
"readonly tuple"
"immutable tuple"

**Code**

```ts
const exampleSort: [number, string] = [2, '1'];

exampleSort.sort();

exampleSort // Type: [number, string], RealType: [string, number]

const exampleSplice: [number, string] = [2, '1'];

exampleSplice.splice(0, 1);

exampleSplice // Type: [number, string], RealType: [string]
```

**Expected behavior:**

```ts
const exampleSort: [number, string] = [2, '1'];

// Property 'sort' does not exist on type '[number, string]'.(2339)
exampleSort.sort();

const exampleSplice: [number, string] = [2, '1'];

// Property 'splice' does not exist on type '[number, string]'.(2339)
exampleSplice.splice(0, 1);
```

**Actual behavior:**

```ts
const exampleSort: [number, string] = [2, '1'];

exampleSort.sort();

const exampleSplice: [number, string] = [2, '1'];

exampleSplice.splice(0, 1);
```

**Playground Link:** https://www.typescriptlang.org/play?ts=4.1.0-dev.20200828#code/MYewdgzgLgBApgDwIYFsAOAbOBlEAnKALhgG0wBXFAIzjwBoZo8BLMAcwF0YBeUgJgYByAIyCOAbgBQkxKkw58UAHQRFACgCUUmcnRZcBGAHojMACoBPNHGJlKNeoygt2HBgCU4SDJeu2mrGwMFNS0HNKgkLCyejiYzMA2pCEODAGuPPxCohLSMfLY8YkqRXBqAAwMwlp5ugWlxqa+SXahjumcHl4+Vi0d4dKSQA

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: excalidraw
Issue: Cmd/ctrl-drag of parent element should unbind it from all bound elements
Labels: bug

Holding Cmd/ctrl while dragging bindable element should unbind currently bound linear elements from it.

![excal_feat_unbind_via_cmd](https://user-images.githubusercontent.com/5153846/91640989-ca797800-ea21-11ea-8191-3c7288d5e016.gif)

/cc @xixixao do you want to take this on?
Repository: TypeScript
Issue: Tolerate invalid identifier syntax errors in list parsing
Labels: Suggestion,Experience Enhancement

## Search Terms

parser variable name list identifiers

## Suggestion

Instead of aborting parsing a list when an invalid identifier is reached, have the parser emit a syntax error but otherwise parsing. In other words: it should successfully parse lists such as variable declarations as if the identifiers were valid, with the one difference of emitting a syntax error that doesn't affect parsing.

## Use Cases

Issues such as #11648 and #19352 pop up from situations where the parser attempts to read in a list, such as one of variable declarations, and cannot because an identifier is invalid.

```ts
const case = 123;
//    ~~~~ 'case' is not allowed as a variable declaration name.(1389)
//         ~ Variable declaration expected.(1134)
//           ~~~ Variable declaration expected.(1134)
```

Although #40105 improved the first error message (previously it was also `Variable declaration expected.`), the underlying issue remains: the parser aborts reading in the list, resulting in an odd error message and surprising emitted JavaScript.

```js
const ;
123;
```

## Examples

Collecting a few examples from the linked issues...

```ts
const data = { in: 1 };
const { in } = data;

for (const case of [1, 2, 3]) console.log(case);

const case = 123;

let delete = true;
```

## 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: vscode
Issue: Workbench hovers don't support equivalent of "editor.hover.sticky" setting
Labels: feature-request,workbench-hover

The workbench hovers (custom views, terminal) don't support the "editor.hover.sticky" setting, which is IMO desired, but there is no equivalent setting

There is also the "editor.hover.delay", but not sure if it matters as much to support this or not (again with its own version IMO)

/cc @alexr00
Repository: flutter
Issue: We need richtext text support, similar to Android (TextView.setText(html)) or iOS (TextView.attributedText=html)
Labels: c: new feature,framework,a: typography,customer: crowd,c: proposal,P3,team-framework,triaged-framework

As Flutter is moving into Desktop and Web, it's become more important that we can create large blocks of text, with a variety of bold, italics, embedded links and other styling.

The current solution is to use TextSpan's which is very limited in their use case, are cumbersome to write, and hard to read. 

Other platforms have solutions already, for example:
Swift : https://stackoverflow.com/questions/37048759/swift-display-html-data-in-a-label-or-textview (200 upvotes)
Android: https://stackoverflow.com/a/2116191/463029 (1300 upvotes)
Unity: http://digitalnativestudios.com/textmeshpro/docs/rich-text/

Ideally this is all selectable, and can also support line breaks and multiple paragraphs. Again, all other platforms have these abilities. 

The TextMeshPro example is interesting because it's not HTML based, and provides the bulk of styling anyone would realistically need. It may map better to the existing TextStyles.
Repository: opencv
Issue: Compilation warnings when compiling in release and checking strict aliasing
Labels: priority: low,category: build/install

##### System information (version)

Seen on (but not dependent on the OS or compiler):
- OpenCV => latest (branch master + branch 3.4)
- Operating System / Platform => Windows 64 Bit
- Compiler => mingw64

##### Detailed description

The "-Wstrict-aliasing" option (added when ENABLE_NOISY_WARNINGS is set) gives a lot of warnings at compilation time.

##### Steps to reproduce

ENABLE_NOISY_WARNINGS=ON and CMAKE_BUILD_TYPE=Release in CMake
Repository: excalidraw
Issue: alt-drag should not modify original element
Labels: bug

Currently, `alt-drag` duplicates in such a way that we swap the original element with a new one (with new seed and shape) instead of the one being dragged. This is undesirable.

:warning: Don't forget to adapt arrow binding as it accounts for current, incorrect behavior, and there are no specs for binding so you won't notice any regressions.
Repository: excalidraw
Issue: Configured grid size
Labels: enhancement,discussion

Hey
As a user, I would have configured grid size to have the possibility to stick some points to grid corners.
I read the topic here: https://github.com/excalidraw/excalidraw/pull/1788 but I didn't find any final thoughts...
I can propose the next idea:
<img width="369" alt="Screenshot 2020-08-29 at 22 59 47" src="https://user-images.githubusercontent.com/1523848/91645142-594eba80-ea4b-11ea-875a-9d9a1cdb0e00.png">
Repository: vscode
Issue: Multi line "Copy Message" from problems panel.
Labels: feature-request,error-list

Version: 1.48.2
Ubuntu 20.04 deb package

Currently when observing the problems view, I can use shift to click to select multiple problems (lines). When I subsequently right click and select "Copy Message", it only copies one of the selected lines. It would be nice if I was able to copy the entire contents (or any subset) of the problems view, exactly how it is displayed.
Repository: rust
Issue: Possible Vec::truncate improvement
Labels: E-hard,A-collections,T-libs

The docs of Vec::truncate say:

"If len is greater than the vector's current length, this has no effect."

And indeed if you look at the source code:
https://doc.rust-lang.org/nightly/src/alloc/vec.rs.html#740-742

There's:

```rust
if len > self.len {
    return;
}
```

But isn't it better to use `len >= self.len` instead?
Repository: godot
Issue: GDScript "unknow character" error when using "ñ" character with unquoted NodePath in $ operator
Labels: bug,topic:gdscript

Godot 3.2.2-stable win 64.

PC, Windows 10 Pro 64


**Issue description:**
GDScript "unknow character" error when using "ñ" character. It worked on previous version. I know it because I was following a course on Udemy in wich the teacher uses a previous version of Godot (probably 3.1), he uses the word "Contraseña" to name a Node and then uses the line:
if $VBox/Contraseña.text == "1234": 
And that doesn't give him any error. 
When I do the same, but using Godot 3.2.2-stable win 64, I receive the error "unknown character". I understand that many languages don't support that character, but taking into account that it was previously supported, maybe it is a regression. 



**Steps to reproduce:**
Use the character "ñ" in GDScript, for example "var leña = 3" and you will receive the "Parse error: Unknown character".

**Minimal reproduction project:**
I think this is not needed in this case.
Repository: svelte
Issue: Using svelte's each inside contenteditable
Labels: stale-bot,temp-stale

I don't know whether this is a bug or a feature request, but I discovered today that you can't use `each` reliably within a `contenteditable` element.

I fathomed a technique to add elements using 3 setTimeouts and momentarily emptying the list (`list = []`), then doing `innerHTML = ""`, and finally setting the list again (`list = someNewList`). Alas, for deleting an item there is no such workaround.

To explain this, suppose you have a `<div>` something like the following:

```svelte
<div contenteditable="true">
    {#each items as item}
        <p>{item}</p>
    {/each}
</div>
```

1. When you press return in that div, it creates a `<p>` that svelte doesn't know about. I'm solving this with an action that dispatches an event when the contenteditable blurs.

2. When you delete a line, it removes a `<p>` and if that was an original item i.e. inserted by svelte's `{#each}` then you get a `cannot read property 'removeChild' of null` when you re-set the list.

---

It strikes me that making svelte more aware of `contenteditable` is not the appropriate route to resolve this. So that rules out feature request. 

Instead I'm left thinking, is this a bug? Should svelte disregard errors when removing elements that the user already removed - irrespective how they removed them?