sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: PowerToys
Issue: Allow selection of specific PowerToys Run results with keyboard shortcuts
Labels: Idea-Enhancement,Product-PowerToys Run

### Description of the new feature / enhancement

Hitting Alt (or another modifier) and a digit (1-9) allows user to select one of the first nine results in PowerToys Run. There would be an icon on either the left or right side of the result name to indicate the shortcut.

This could be built in without much nuisance to users who don't use this, but would be better as an optional setting.

Even better would be if this were built to allow the user to select to use the home row keys instead of digits for the shortcuts, or even customize the shortcuts to their liking.

### Scenario when this would be used?

This would be used by any PowerToys Run user who seeks to speed up their workflow.

Personally, this would also add accessibility to disabled users like myself who find it difficult and/or painful to move their hands to the mouse or to the arrow keys on the keyboard.

### Supporting information

Alfred for MacOS uses a shortcut system like this, although it is not as customizable as I suggest.

![alfred-cmd-shortcut](https://user-images.githubusercontent.com/60205993/123861206-c33e2780-d8db-11eb-8490-0d2fe7c9da40.png)
Repository: pytorch
Issue: Automate bumping of `clang-tidy` docker image tag on CI
Labels: module: ci,triaged,module: infra

The `clang-tidy` docker image is built via a GHA workflow on [pytorch/test-infra](https://github.com/pytorch/test-infra). Every time we publish a new tag, we have to update `.github/workflows/lint.yml`. This is a mechanical process that can be automated. 

One solution would be to have a bot that creates a PR that bumping the tag in `.github/workflows/lint.yml` every time a new image is built (similar to how dependabot works). We should be able to skip PR creation via some label on pytorch/test-infra (similar to how [skip-ci] works)

cc @ezyang @seemethere @malfet @walterddr @pytorch/pytorch-dev-infra
Repository: flutter
Issue: Explain relaxing version constraints in package docs.
Labels: d: api docs,package,team-ecosystem,P2,triaged-ecosystem

https://flutter.dev/docs/development/packages-and-plugins/using-packages#conflict-resolution has advice that's really targeted for package authors even though the page is about "Using packages". We should start that section by giving some app-developer-targetted advice about making sure they aren't over-specifying their version constraints. (See https://github.com/flutter/flutter/issues/85560 for one example of why).

We should explicitly say in the docs that using less less restrictive restrains (rather than latest versions) in the *app* pubspec can potentially resolve constraints.
Repository: rust
Issue: Non-terminals, e.g. expr, have diverged between parser and macro matcher
Labels: A-parser,A-macros,T-lang,F-let_chains,A-maybe-future-edition,F-inline_const

Spawned off of PR #84364, based on discussion from lang team meeting ([minutes](https://github.com/rust-lang/lang-team/blob/master/minutes/2021-05-11.md#add-expr202x-macro-pattern-rust84364), [youtube](https://youtu.be/5hmVDeNc1t0?t=776)).

The meaning of the non-terminal "expr" according to the rustc parser has changed (or would like to change) from its meaning according to the current rustc macro matcher.

Concretely:
 * The `inline_const` feature has already added a production roughly of the form `EXPR ::= const { EXPR }`
 * The `let_chains` feature may want (in the future) to add a production roughly of the form `COND_EXPR ::= let PAT = EXPR`, where `COND_EXPR` can occur as a sub-expression in the condition that drives an `if` expression or `while` statement.

In both cases, for backwards compatibility, the `expr` fragment specifier does not accept these new productions. Examples of the kinds of problems this causes follow:
 * [example for inline_const](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=3e7986fb779d5e8242d3844f3dc8ee5e),
 * [example for let_chains](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=b8be79e96d07ca2cd89772b52ee93687).

In other words, today you simply cannot write a macro fragment specifier denoting expressions that will match `const { EXPR }` or `let PAT = EXPR`, other than something like `$e:tt`, which would also match arbitrary token-trees, which won't catch errors as effectively as a more precise fragment specifier.

So, the main question this raises is: How should we resolve this divergence between the parser and macro-rules matcher?

 * E.g. we could add a new fragment specifier (e.g. `expr2024`) that covers the new forms and call it a day.
 * Or we could, at an edition boundary, change the meaning of the `expr` fragment specifier to cover the new forms. (This would probably need to be coupled with an addition of a new fragment specifier that would capture the *old* semantics.)
 * In any case, we need a clear summary of the grammar changes, so that we can understand what `expr` matches now that it did not before.
 * I think any change we make here would be well-served to be documented by writing down the actual grammar being implemented, or rather, the changes to the grammar.
 * We also may need a crater run.
Repository: rust
Issue: min_type_alias_impl_trait: poor diagnostics when TAIT is unconstrained
Labels: A-diagnostics,T-compiler,F-type_alias_impl_trait

The minimized example ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=339dbf8636930ba8cb5195793dae51da):

```rust
#![feature(min_type_alias_impl_trait)]

type Foo = impl Copy;

enum Wrapper<T> {
    First(T),
    Second
}

fn produce() -> Wrapper<Foo> {
    Wrapper::Second
}
```

gives what appears to me to be the correct error:

```
error: could not find defining uses
 --> src/lib.rs:3:12
  |
3 | type Foo = impl Copy;
  |            ^^^^^^^^^
```

but the diagnostics are not very good.

_Originally posted by @nikomatsakis in https://github.com/rust-lang/rust/issues/66426#issuecomment-870924733_
Repository: pytorch
Issue: [NNC] APIs needed to bridge scheduling gap in reductions
Labels: NNC

Here are two APIs that are needed to bridge the scheduling gap in reductions.
  1. API to shuffle statements in a block
  2. API to compress all the buffers in the kernel.

Thanks to @bertmaher for pointing these out.
Repository: electron
Issue: Document the "original-fs" module
Labels: documentation :notebook:,stale-exempt

Electron modifies the `fs` module directly to support ASAR files, this can be a performance burden for use cases that do not require ASAR support however and to support those use cases the "original" fs module is available under `require('original-fs')`.

Although _I_ know this, apparently this is not documented.  Refs #29051.  We should document its existence and its use cases
Repository: pytorch
Issue: Merge seemethere/upload-artifact-s3 and driazati/upload-artifact-s3
Labels: triaged,better-engineering

We use these both in CI and in test-infra, we should have them all be on fork (and ideally the same hash) so there's one place to see the code and the code corresponds to what we use in CI.

The [changes from the fork](https://github.com/seemethere/upload-artifact-s3/compare/main...driazati:main) are:
* aws credentials
* custom s3 prefix
* s3 prefix based on PR number (this can probably be rolled into the previous bullet and we can interpolate everything the actions workflow itself)
Repository: terminal
Issue: Quake mode has rounded corners in Windows 11
Labels: Product-Terminal,Issue-Task,Priority-3,Area-Windowing

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

Windows 11 - 10.0.22000.0 | Terminal preview 1.9.1523.0

### Other Software

Windows 11 preview

### Steps to reproduce

I installed the terminal preview before updating, but I assume it'll have the same behavior whether you install before or after.

After finishing the Windows 11 upgrade, opening the terminal quake mode drop-down, the corners at the top and bottom are curved instead of filling in the full area.

I understand that this is the behavior that Windows 11 has by default for its apps, but this looks weird for the quake mode terminal.

### Expected Behavior

The quake terminal shows without rounded edges.

### Actual Behavior

The quake terminal shows with rounded edges

![image](https://user-images.githubusercontent.com/2301725/123881083-986ac800-d909-11eb-84c8-702efbcdb8c6.png)
Repository: vscode
Issue: [remote] Prefer to open a file in an existing window even when that window is connected to a remote with that file opened
Labels: feature-request,remote

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
![image](https://user-images.githubusercontent.com/41391321/123884719-83923280-d911-11eb-82b8-664b004b23d9.png)

You open a project that has a .devcontainer folder, and vscode asks you to "reopen in devcontainer", so you open the devcontainer.

You now have one vscode window of a project in a devcontainer.

Reproducing:

- You navigate to another application, such as file explorer or GitHub desktop and find a file in the project you're working on, which exists in the devcontainer.

- You right click on the file, and you can choose an option in windows explorer to "Open with code" or in GitHub desktop "open in Visual Studio Code".

It doesn't matter which option you take, you click the menu item.

(I reckon it would also be an issue for just generally opening filetypes that have code as the default opener)

Behaviour:

vscode will now open this file in a brand new vscode window, outside of the devcontainer.

We think the preferred behaviour should be for vscode to detect that this file the user has requested to be opened exists in both the filesystem and in the open devcontainer, and translate that file path to devcontainer/WSL language and open it in the existing devcontainer/remote wsl window.



This is referenced in an issue [here](https://github.com/desktop/desktop/issues/11634) and I just wanted to check and see if this is expected or if it's an actual bug.
Repository: pytorch
Issue: [Docker] Incompatible torchvision for 1.9.0-cuda10.2-cudnn7-runtime tag.
Labels: triaged,module: vision,module: docker

## 🐛 Bug
When attempting to use torchvision ops inside the Pytorch's docker container of tag `1.9.0-cuda10.2-cudnn7-runtime` the following error will be displayed:
```
RuntimeError: Couldn't load custom C++ ops. This can happen if your PyTorch and torchvision
versions are incompatible, or if you had errors while compiling
torchvision from source. For further information on the compatible versions, check 
https://github.com/pytorch/vision#installation for the compatibility matrix. 
Please check your PyTorch version with torch.__version__ and your torchvision
version with torchvision.__version__ and verify if they are compatible, and if not please 
reinstall torchvision so that it matches your PyTorch install.
```

## To Reproduce

Steps to reproduce the behavior:
One can run an example torchvision op inside the mentioned container:

```bash
docker run --rm pytorch/pytorch:1.9.0-cuda10.2-cudnn7-runtime \
 python -c "import torchvision;torchvision.ops.nms(1,2,3)"
```

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior
For the example above, the error should be that I'm passing scalar and not a tensor. For a better example the ops should be 
correctly executed. Either way, there should not be incompatibility error.

## Environment
N/A 

 - PyTorch Version (e.g., 1.0): 1.9.0
 - OS (e.g., Linux): Ubuntu 18.04
 - How you installed PyTorch (`conda`, `pip`, source): Docker
 - Build command you used (if compiling from source): N/A
 - Python version: 3.7
 - CUDA/cuDNN version: 7
 - GPU models and configuration: Tesla K80
 - Any other relevant information: N/A
Repository: flutter
Issue: [iOS]  Statusbar tap to scroll top doesn't work in nested navigation 
Labels: platform-ios,framework,a: fidelity,f: scrolling,d: api docs,d: examples,f: routes,d: stackoverflow,has reproducible steps,P3,found in release: 2.2,found in release: 2.3,team-ios,triaged-ios

ios status bar touch scroll top move doesn't work in nested navigation. 

Is there any workaround for this?

Nested navigation is used a lot in many apps such as Netflix.

With one thought, I tried the following method, but it returns null and it doesn't work.

```dart
SingleChildScrollView(
      controller: PrimaryScrollController.of(Navigator.of(context, rootNavigator: true).context),
      ...
      ...
      ...
    )
```
Repository: vscode
Issue: Trusted uris: added uri should be focused
Labels: bug,polish,workspace-trust

Testing #127549

1. Have a large list of trusted paths.
2. Add Folder -> choose something that will be in the middle or top of the list
3. list refrehses, however the last element gets focused 🐛  

We should instead focus the element that just got added so the user can make a correlation between what she added and what got added in the list.
Repository: create-react-app
Issue: Can't get https running
Labels: needs triage

There's an .env file with following content in the root directory of the react app:

```
HTTPS=true
SSL_CRT_FILE=/ssl/certificate.crt
SSL_KEY_FILE=/ssl/certificate.key
```
```
 /app/myProjectPath:
  total used in directory 484 available 1731267132
  drwxrwxrwx  1 user Domänen-Benutzer   8192 06-16 19:17 ..
  drwxrwxrwx  1 user Domänen-Benutzer   4096 06-21 10:59 .
  -rw-rw-rw-  1 user Domänen-Benutzer     82 06-22 17:18 .env
  drwxrwxrwx  1 user Domänen-Benutzer   4096 06-21 10:59 .git
  -rw-rw-rw-  1 user Domänen-Benutzer    324 2020-06-20  .gitignore
  -rw-rw-rw-  1 user Domänen-Benutzer   1067 06-21 10:56 node_modules
  -rw-rw-rw-  1 user Domänen-Benutzer    759 06-21 10:59 package.json
  -rw-rw-rw-  1 user Domänen-Benutzer    753 06-16 19:28 package.json.bkp
  -rw-rw-rw-  1 user Domänen-Benutzer    176 2020-11-12  post.sh
  drwxrwxrwx  1 user Domänen-Benutzer   4096 06-16 19:17 public
  -rw-rw-rw-  1 user Domänen-Benutzer   9830 06-16 19:17 README.md
  drwxrwxrwx  1 user Domänen-Benutzer   4096 06-16 19:17 src
  -rw-rw-rw-  1 user Domänen-Benutzer 457759 2020-06-20  yarn.lock
```

When the server starts, I've got the output:
```
> react-template@0.1.0 start /app/myProjectPath

> react-scripts start

certificate.crt file exists.

certificate.key file exists.

Starting the development server...

Compiled successfully!

You can now view react-template in the browser.

https://localhost:3000/

Note that the development build is not optimized.

To create a production build, use yarn build.
````

To ensure that both the certificate and key file can be read by node.js, I've added some debug code inside start.js:

```
if(fs.existsSync('/ssl/certificate.crt')) {
	          console.log("certificate.crt file exists.");
} else {
                  console.log('certificate.crt file does not exist.');
}

if(fs.existsSync('/ssl/certificate.key')) {
	          console.log("certificate.key file exists.");
} else {
                  console.log('certificate.key file does not exist.');
}
```

As you can see in the output above, both files could be read at startup.

If I call https://localhost:3000 I've got different browser error messages:

Firefox 89: SEC_ERROR_INADEQUATE_KEY_USAGE

Chrome 88: NET::ERR_CERT_AUTHORITY_INVALID

The same key and certificate files are working well in a simple Apache https config, so I assume the certificate and its key are issued correctly.
So what's wrong with node.js https development server here?
Repository: vscode
Issue: Explore improving search performance to support high `maxResults`
Labels: bug,search,confirmed

extracted from https://github.com/microsoft/vscode/issues/8563#issuecomment-871226262

* open vscode repo
* have `"search.maxResults": 200000000`
* search for `;`
* 🐌 notice how VS Code becomes slower and slower... I can see that  each call to `refreshAndUpdateCount` takes close to 1 second and these calls happen repeatedly

<img width="613" alt="Screen Shot 2021-06-30 at 11 07 10" src="https://user-images.githubusercontent.com/1794099/123934194-54240a00-d993-11eb-9bee-9cb8bde788e5.png">
Repository: create-react-app
Issue: Allow disabling flow during a Babel transformation
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?

In our app (which is not using Flow), we have been facing an issue with the Babel parser used in a Flow-related plugin. See 
 https://github.com/babel/babel/issues/13520 for more context.


### Describe the solution you'd like

We'd like to have a way to disable Flow in the Babel transformation (used, for instance, in some cases when running with Jest). 
Adding `flow: false` in this piece of code solves our issue:

https://github.com/facebook/create-react-app/blob/64df135c29208f08a175c941a0e94d9a56d9e4af/packages/react-scripts/config/jest/babelTransform.js#L26-L37

```js
 module.exports = babelJest.createTransformer({ 
   presets: [ 
     [ 
       require.resolve('babel-preset-react-app'), 
       { 
         runtime: hasJsxRuntime ? 'automatic' : 'classic', 
         flow: false,   // <--- this is enough to solve our issue
...

```

Of course, we may want to make it configurable, so I'd suggest a similar approach for disabling the JSX transforms.
Something like `process.env.DISABLE_FLOW`

### Describe alternatives you've considered

Ejecting is always an option, but since the issue is only happening when executing the tests, we opted for temporarily replace the `babelTransform.js` file with a hardcoded version with the fix. We assume, in the future, either Babel will solve the parsing issue or CRA will add a way to enabling/disabling flow,

### Additional context

More context here: https://github.com/kubeapps/kubeapps/pull/3042#issuecomment-870053634
Repository: godot
Issue: Spot Light with high angle breaks Shadows
Labels: topic:rendering,documentation,topic:3d

### Godot version

3.3.2 Stable

### System information

Windows 10, GLES 2&3, Nvidia Quadro K2000 461.92

### Issue description

Spot Light Angles above 85 degrees with Shadows cause artifacting

Shadows shouldn't be allowed when going past that angle and should just automatically ignore the Shadow setting and treat it as off.

The Editor does warn that going over 90 degrees spot lights cannot cast shadows, but they do, just broken shadows

### Steps to reproduce

Add a Spot Light to light something
Turn shadows on
Get the angle over 85 degrees -> artifacting starts
at 90+ degrees shadows go totally to hell

Result:
![Screenshot 2021-06-30 115650](https://user-images.githubusercontent.com/50302479/123941498-808f5480-d99a-11eb-802f-e4e0316070fe.png)


### Minimal reproduction project

_No response_
Repository: storybook
Issue: Ignore private members and methods from Custom Elements Manifest
Labels: feature request,web-components,block: argstable

**Describe the bug**
The new `setCustomElementsManifest` method correctly loads a Custom Element Manifest and it populates properties in the API table, but it does not filter private members using the `privacy` field in the manifest.

**To Reproduce**
https://github.com/edoardocavazza/custom-elements-manifest-private-members

Run the storybook and open docs page.

**System**

Environment Info:
```
  System:
    OS: macOS 11.3
    CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
  Binaries:
    Node: 15.14.0 - ~/.nvm/versions/node/v15.14.0/bin/node
    Yarn: 2.4.2 - /usr/local/bin/yarn
    npm: 7.7.6 - ~/.nvm/versions/node/v15.14.0/bin/npm
  Browsers:
    Edge: 91.0.864.48
    Firefox: 89.0
    Safari: 14.1
  npmPackages:
    @storybook/addon-actions: ^6.4.0-alpha.9 => 6.4.0-alpha.9 
    @storybook/addon-docs: ^6.4.0-alpha.9 => 6.4.0-alpha.9 
    @storybook/addon-essentials: ^6.4.0-alpha.9 => 6.4.0-alpha.9 
    @storybook/addon-links: ^6.4.0-alpha.9 => 6.4.0-alpha.9 
    @storybook/web-components: ^6.4.0-alpha.9 => 6.4.0-alpha.9
```
Repository: ant-design
Issue: In table column make filter-confirm possible when dropdown becomes hidden
Labels: 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.

### What problem does this feature solve?
It could make the end-user experience consistent.

If we have multiple columns in our table and we have mixed `filters` and `filterDropdown`s from column to column then the user experience is that there are some filers that don't need to be confirmed, only clicking away is enough and there are some that need to be.

### What does the proposed API look like?
Two options come in mind:

**1.**
```javascript
// FilterDropdown.tsx
const onVisibleChange = (newVisible: boolean) => {
[...]
  // add a new flag that will force confirmation on hide
  if (!newVisible && (!column.filterDropdown || column.confirmOnHide)) {
    onConfirm();
  }
```

now we can use it like this
```javascript
<Table.Column
  filterDropdown={<CustomComponent />}
  confirmOnHide
/>
```

**2.**
```javascript
// FilterDropdown.tsx
const triggerVisible = (newVisible: boolean) => {
  setVisible(newVisible);
  /* pass the confirmation function to
   * onFilterDropdownVisibleChange param, so user can call it when needed
   */
  onFilterDropdownVisibleChange?.(newVisible, onConfirm);
};
```

so we can use it like this
```javascript
<Table.Column
  filterDropdown={<CustomComponent />}
  onFilterDropdownVisibleChange={(newVisible, confirm) => {
    if (!newVisible) {
      confirm();
    }
  }}
/>
```


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: rust
Issue: Rust does not perform cross language LTO for C functions forwarding to C++
Labels: C-bug,A-LTO,S-needs-repro

I believe that cross language LTO does not work correctly when calling C++ code from Rust via intermediate C functions.

Consider [this example](https://github.com/Time0o/rust-cross-lang-lto), here a C++ function `foo::do_something` (defined in `cc/foo_cc.h`) is wrapped in a C function `foo_do_something` (declared in `c/foo_c.h`) which is then called from Rust via its FFI (in `rust/foo_main.rs`).

For reference, when linking the static library `libfoo_c.a` that exposes `foo_do_something` to a binary created from another C file (`c/foo_main.c`), a call to `foo_do_something` is correctly reduced to a call to `foo::do_something` in the resulting machine code. However, this is not the case for the binary created by `rustc`, here the main function first jumps to `foo_do_something` which then does nothing but to jump to `foo::do_something`.

I've tested this with `rustc 1.53.0` and `clang 12.0.0`