sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: storybook
Issue: Viewports on Safari are incorrectly calculated
Labels: bug,compatibility with other tools,addon: viewport

**Describe the bug**
Viewports are incorrectly calculated on Safari.

Here is a screenshot from Chrome:

<img width="1920" alt="Screenshot 2021-12-05 at 01 24 19" src="https://user-images.githubusercontent.com/17653648/144728835-4dc1fcc4-08d7-4ccb-9cad-3d7625b44ad9.png">

And here is from Safari:

<img width="1917" alt="Screenshot 2021-12-05 at 01 26 47" src="https://user-images.githubusercontent.com/17653648/144728837-71645dce-b5b2-4548-8926-cc4fbe9c4a02.png">

In both cases the same viewport is selected - "Tablet" but the UI is different.

**To Reproduce**
https://github.com/Mikilll94/storybook-repro

1. Clone the repo and run
```
npm install
npm run storybook
```

2. Open Safari and select "Tablet" viewport.
3. Open Chrome and select "Tablet" viewport.
4. As you can see the UI is different.

**System**
System:
    OS: macOS 11.6.1
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
  Binaries:
    Node: 16.13.0 - /usr/local/bin/node
    Yarn: 1.22.15 - /usr/local/bin/yarn
    npm: 8.1.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 96.0.4664.55
    Safari: 14.1.2

**Additional context**
The behavior on Safari is incorrect.

The tablet viewport is defined like this:
```
      middle: {
        name: 'Tablet',
        styles: {
          width: '768px',
          height: '963px',
        },
      },
```

and in `page.css` I have the following CSS

```
@media (min-width: 768px) {
  .repro-grid {
    grid-auto-flow: column;
  }
}
```

This CSS is correctly applied in Chrome for "Tablet" viewport but it is not applied in Safari.
Repository: TypeScript
Issue: In declaration files generated from JavaScript files and their JSDoc, unresolved types are not converted to `any`.
Labels: Needs Investigation

# Bug Report

With TypeScript 4.5.2, when we generate declaration files from JavaScript files and their JSDoc annotations with `tsc --allowJs --declaration --emitDeclarationOnly`, unresolved types are not converted to `any`. I can see the same issue with `4.6.0-dev.20211204`.

### 🔎 Search Terms

JSDoc, allowJs, declaration

### 🕗 Version & Regression Information

- This changed between versions 4.4.4 and 4.6.0-dev.20211204


### 💻 Code

Generate `main.d.ts` from  `main.js` with `tsc --allowJs --declaration --emitDeclarationOnly main.js`

`main.js`

```js
/**
 * 
 * @param {SomeClass} a 
 * @returns {SomeClass}
 * 
 */
function f(a) {
    return a
}
```


### 🙁 Actual behavior

With `4.6.0-dev.20211204`, `main.d.ts` :

<!-- What happened, and why it was wrong -->
```ts
/**
 *
 * @param {SomeClass} a
 * @returns {SomeClass}
 *
 */
declare function f(a: SomeClass): SomeClass;
```

### 🙂 Expected behavior

With `4.4.4`, `main.d.ts`:

<!-- What you expected to happen instead, and why -->

```ts
/**
 *
 * @param {SomeClass} a
 * @returns {SomeClass}
 *
 */
declare function f(a: any): any;
```
Repository: deno
Issue: watcher: disable terminal raw mode at each restart
Labels: feat,--watch

After each restart watcher should also disable terminal raw mode (`Deno.setRaw`), as it makes it impossible to kill running command using `Ctrl+C`. It's especially annoying when we haven't specified correct permissions as we have to reopen the terminal.
Repository: pytorch
Issue: [feature request] `torch.to(obj, device)` supporting recursive lists/dicts/tuples of tensors probably by uplifting/promoting `torch.distributed.utils._recursive_to`
Labels: triaged,needs research,function request

Often it is needed to move model results to cpu (or inputs to gpu). Once the data structures get a bit complicated, dicts and lists appear often in model results. Often we have to roll a little utility method like below. If indeed other people had to write this sort of utilities, may make sense to include something like this to core.

```python
def to(obj, device):
  if torch.is_tensor(obj):
    return obj.to(device)
  if isinstance(obj, dict):
    return {k : to(v, device) for k, v in obj.items()}
  if isinstance(obj, tuple):
    return tuple(to(v, device) for v in obj)
  if isinstance(obj, list):
    return [to(v, device) for v in obj]
  return obj
```

cc @albanD @mruberry @jbschlosser @walterddr
Repository: pytorch
Issue: `torch.transpose` should raise an error when indexing 0 for 0 dimensional tensor.
Labels: triaged,module: viewing and reshaping

## 🐛 Bug

`torch.transpose` should raise an error when indexing 0 for 0 dimensional tensor. Because you cannot index 0 for a 0 dimensional tensor.

## To Reproduce

```python
import torch
tensor = torch.rand(torch.Size([]))
res1 = torch.transpose(tensor, 0, 0)
```
It will succeed. But when you index 0 for this tensor it will fail
```
tensor[0]
# IndexError: invalid index of a 0-dim tensor. Use `tensor.item()` in Python or `tensor.item<T>()` in C++ to convert a 0-dim tensor to a number
```

## Expected behavior

Raise an error.

## Environment

PyTorch Version (e.g., 1.0): 1.10.0
OS (e.g., Linux): Linux
How you installed PyTorch (conda, pip, source): conda
Python version: 3.9.5
CUDA/cuDNN version: 11.1
GPU models and configuration: RTX 3090
Repository: godot
Issue: Vulkan: VoxelGI is much brighter at 512 subdivisions compared to 64, 128 or 256 subdivisions
Labels: bug,topic:rendering,topic:3d

### Godot version

4.0.dev (2a9dd654b)

### System information

Fedora 34, GeForce GTX 1080 (NVIDIA 470.74)

### Issue description

Indirect lighting and reflections from VoxelGI appear to be much brighter at 512 subdivisions compared to 64, 128 or 256 subdivisions. It's possible to (partially) compensate for this by decreasing VoxelGIData's **Energy** property to 0.25, but this requires manual work that could be avoided.

## Use Two Bounces disabled

| 64 subdivisions | 128 subdivisions | 256 subdivisions | 512 subdivisions |
|-|-|-|-|
| ![2021-12-05_17 30 54](https://user-images.githubusercontent.com/180032/144754937-55c7fc15-c3e0-4826-b002-33276df2a060.png) | ![2021-12-05_17 30 41](https://user-images.githubusercontent.com/180032/144754936-db57d5ee-de3e-48bb-a3d1-4e352c9ec277.png) | ![2021-12-05_17 30 28](https://user-images.githubusercontent.com/180032/144754934-e78d08f3-3260-4d4e-b28b-ab47b050903c.png) | ![2021-12-05_17 30 15](https://user-images.githubusercontent.com/180032/144754932-448065ec-bffe-453a-baf3-854a6fedf161.png) |

## Use Two Bounces enabled

| 64 subdivisions | 128 subdivisions | 256 subdivisions | 512 subdivisions |
|-|-|-|-|
| ![2021-12-05_17 23 19](https://user-images.githubusercontent.com/180032/144754851-2a26d005-43cb-4d33-be1a-37e6cbbee5f7.png) | ![2021-12-05_17 23 38](https://user-images.githubusercontent.com/180032/144754852-2519b5e8-feee-456f-a303-0b43e94bc775.png) | ![2021-12-05_17 24 08](https://user-images.githubusercontent.com/180032/144754853-b581a54e-4c01-4a63-a22f-cfda6115a506.png) | ![2021-12-05_17 24 54](https://user-images.githubusercontent.com/180032/144754854-be71648f-2b6a-4c13-9c4a-897420a2e607.png) |

### Steps to reproduce

- Add a VoxelGI node. Set **Subdiv** to 256.
- Add some MeshInstances with their global illumination mode set to **Baked**.
- Select the VoxelGI node and click **Bake** in the toolbar at the top of the 3D editor viewport.
- Set **Subdiv** to 512 and click **Bake** again.

### Minimal reproduction project

[test_voxelgi_large.zip](https://github.com/godotengine/godot/files/7656349/test_voxelgi_large.zip)
Repository: PowerToys
Issue: [FZ] - Apply layout to multiple desktops
Labels: Idea-Enhancement,Product-FancyZones,FancyZones-VirtualDesktop

### Description of the new feature / enhancement

I use 4 desktops with my large monitor. After defining a fancy zone, I find that it is only applied to the initial desktop where I defined the zone. So currently I have to redo the zone definition for each desktop.

Some ideas
1. an setting option (checkbox) to apply the same fancyzone across all desktops. 
2. set a fancy zone as default (for all desktops)

Found with powertoys v0.55.1 using Windows 10

### Scenario when this would be used?

When using multiple desktops which are super useful for multi tasking as they keep all windows together needed for working on a specific task

### Supporting information

_No response_
Repository: godot
Issue: Vulkan: VoxelGI VRAM size estimation is inaccurate
Labels: bug,topic:rendering,topic:editor,topic:3d

### Godot version

4.0.dev (2a9dd654b)

### System information

Fedora 34, GeForce GTX 1080 (NVIDIA 470.74)

### Issue description

VoxelGI VRAM size estimation in the editor appears to be too conservative. Actual VRAM usage seems much higher.

In the testing project linked below, these are the VRAM size *deltas* I measured from my system:

| Mode | Estimated | Actual | Estimated → Actual factor |
|-|-|-|-|
| No VoxelGI | N/A | 0 MB | N/A |
| VoxelGI Subdiv 64 | 0.25 MB | 5 MB | 20 times larger |
| VoxelGI Subdiv 128 | 2 MB | 260 MB | 130 times larger |
| VoxelGI Subdiv 256 | 16 MB | 510 MB | ~31.88 times larger |
| VoxelGI Subdiv 512 | 128 MB | 2260 MB | ~17.66 times larger |

The delta is measured from the "No GI" VRAM size mentioned in the absolute VRAM usage values below:

```
GPU has 8192 MB of VRAM.

Engine not running: 750 MB
No GI: 970 MB
64 subdiv: 975 MB
128 subdivisions: 1230 MB
256 subdivisions: 1480 MB
512 subdivisions: 3230 MB
```

Antialiasing and other effects were disabled, and the project is running at the default window size of 1024×600. All other setting were left to their default values.

It seems there is no singular amplification value that would be reliable in all cases. From the above testing, we can conclude that the average amplification factor across all subdivision sizes is **50**. However, the testing project uses mostly horizontal VoxelGI extents, which means the Y axis has 4 times less voxels than in a VoxelGI with fully cubic extents (Y axis as tall as others). This can likely influence the amplification factor.

### Steps to reproduce

- Look at your VRAM usage when the editor is not running (use `nvidia-smi` on Linux, or any other program that displays VRAM usage). This is the "Engine off" VRAM usage scenario.
- Create a project with some meshes. Save the scene, then quit to the project list. Run the project. Look at VRAM usage again. This is the "No GI" VRAM usage scenario.
- Open the project in the editor again, then add a VoxelGI node. Configure some meshes with their global illumination mode set to **Baked**.
- Look at the VRAM size estimation. **Note that you will currently have to modify the source code and recompile to see the label, as per https://github.com/godotengine/godot/issues/53529.**
- Bake VoxelGI. Quit to the project list a second time.
- Run the project from the project manager (to ensure the editor isn't running at the same time). Look at VRAM usage a third time. This is the "VoxelGI Subdiv 128" VRAM usage scenario.
- Repeat this operation with higher and lower VoxelGI subdivision sizes.

### Minimal reproduction project

[test_voxelgi_large.zip](https://github.com/godotengine/godot/files/7656482/test_voxelgi_large.zip)
Repository: ant-design
Issue: showSelectedFirst new prop on Select component
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?
When selecting many items from Select dropdown  - some of them may not fit inside input (as tags) and user is not sure which items she/he choose. The only solution is to search for item or  scroll throughout all dropdown and find one . In case od many items in dropdown list, this can be hard. This prop will show all selected items on the top od dropdown after close / open. The state od top selected items will change with every new dropdown open.

### What does the proposed API look like?
showSelectedFirst = boolean


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: PowerToys
Issue: Text converter between different keyboard layouts
Labels: Idea-New PowerToy

### Description of the new feature / enhancement

A new keyboard shortcut (something like <kbd>Win</kbd>+<kbd>Shift</kbd>) to switch between keyboard layouts like <kbd>Win</kbd>+<kbd>Space</kbd> does but WITH converting selected text to the chosen keyboard layout.

### Scenario when this would be used?

When you have 2+ different keyboard layouts installed and need to switch between them very often, you can mistakenly start typing text on the wrong one.

For example, I have 3 keyboard layouts installed: for typing in Ukrainian, Russian, and English. Chatting with friends in Ukrainian, searching for some info in Russian, and coding simultaneously require changing the layout every time I switch between these activities. I often forget about this and start typing with the wrong one selected producing something like `Ghbdsn? zr cghfdb` instead of `Привіт, як справи?` or `мукн шьзщкефте ьуыыфпу` instead of `very important message`. Sometimes you can write a very large piece of text on the wrong keyboard layout and then have to retype everything.

With a specific keyboard shortcut, you can select that text written on the wrong layout, hold down <kbd>Win</kbd>, and press <kbd>Shift</kbd> several times to convert the selected text. Example scenario:

Select `мукн шьзщкефте ьуыыфпу` -> hold down <kbd>Win</kbd> and press <kbd>Shift</kbd> once (conversion to Ukrainian happens) -> `мукн шьзщкефте ьуііфпу` still not the right one -> press <kbd>Shift</kbd> again (conversion to English happens) -> `very important message` finally the right one!

Additionally, the new shortcut can also send <kbd>Win</kbd>+<kbd>Space</kbd> to also display the system's built-in language switching dialog and change the layout to let the user continue typing with the right one selected.

![image](https://user-images.githubusercontent.com/45333177/144759532-d4c10299-0192-45b4-8ae9-c5c0d02c99fb.png)

### Supporting information

_No response_
Repository: deno
Issue: Deno.readDir won't return all files
Labels: bug,runtime

If a filename has funny characters `Deno.readDir` will silently ignore those files.

First unzip [bug.tar.zip](https://github.com/denoland/deno/files/7660780/bug.tar.zip) which produces `bug.tar` file
Now untar `bug.tar` which produces `bug` directory
Now run `deno run --allow-read readDirBug.js`:

```js
for await(const entry of Deno.readDir("bug")) {
	console.log(entry);
}
```

It only shows 2 entries, should be 4. 

NodeJS finds these files just fine:
```js
import { readdir } from 'fs/promises';

const entries = await readdir("bug");
for (const entry of entries) {
	console.log(entry);
}
```

System info:
```
Linux 5.14.7
deno 1.16.4 (release, x86_64-unknown-linux-gnu)
v8 9.7.106.15
typescript 4.4.2
```

EDIT: Added attachment, [bug.tar.zip](https://github.com/denoland/deno/files/7660780/bug.tar.zip)
Repository: TypeScript
Issue: Assignment operators allow assigning invalid values to literal types
Labels: Suggestion,In Discussion

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

- `addition assignment string literal`
- `append string literal`

<!--
  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.
-->

### 🕗 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 string literals

### ⏯ 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?#code/C4TwDgpgBAIghsOUC8UDeUBucA2BXCALigHIcBLYCAJ1xKgF8AoJgYwHsA7AZ2CgBMEcYvEQp0WXAWJlKNOoxaDEAOmz5oAek1QAKuGjluUAEQUqtHCabaodgHoB+JULVToAalQkAZu3b0tgCCYJCc-OScAOZQSLzUkTFGUGDs3NzkAEY4EAA0AhDcYHJQlFCZEImxUPFV5vI4UKCQKjY6Ds5MynBuGlC2AHLsAO5NABbQzYbGtdEstt2lM8DkOI3sPk0GsEKx4VCscJzl0GBw6RD8sThcUbltUBCYEMfDE8fAE5J9Y+fj0MNqLcti0mHhuBBRHAABTdACUAG4WD48JxWCsuFBwZChNCAPoiIRw4iYdjkK5oZhAA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
type Data = { value: 'literal' }

const data: Data = { value: 'literal' }
data.value += 'foo' // Appending a string is possible, despite it being a string literal type.

// data is still of type Data and can be passed along,
// even when the value has the wrong type.
useData(data);

function useData(_: Data): void {}
```

The same applies to any literal type (e.g. `number`). See #48857 for more examples.

### 🙁 Actual behavior

<!-- What happened, and why it was wrong -->
Appending a random string to the property typed as the literal `"literal"` is possible.

### 🙂 Expected behavior

<!-- What you expected to happen instead, and why -->
I would expect an error, saying that the the type `"literalfoo"` is not assignable to `"literal"`.

---

Ping @S0AndS0
Repository: rust
Issue: Warn about unnecessary blocks
Labels: A-lints,A-diagnostics,T-lang

rustc already warns about unnecessary semicolons:
```Rust
fn main() {
	;;;;;;;;;;;;
}
```
```
warning: unnecessary trailing semicolons
 --> mytest.rs:2:2
  |
2 |     ;;;;;;;;;;;;
  |     ^^^^^^^^^^^^ help: remove these semicolons
  ```
However, there is no warning about unnecessary blocks:
```Rust
fn main() {
	{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}
}
```

Is this feasible to implement? Should this be the responsibility of another tool? (clippy, rustfmt)

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"obeis"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: rust
Issue: Raw string missing quote characters diagnostic does not mention missing quote characters
Labels: A-diagnostics,T-compiler

[Given the following code](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f9d908ad9af77758b5988c03f0890dd3):
```rust
    let _data = br#
        [
	        {"name":"Lucy","age":18,"achievement":[95,86.5,90]},
	        {"name":"Lily","age":19,"achievement":[92.5,89,91]},
	        {"name":"Jack","age":20,"achievement":[93,90,93.5]}
        ]
    #;
```

The current output is:

```
error: found invalid character; only `#` is allowed in raw string delimitation: \n
 --> src/main.rs:2:17
  |
2 |       let _data = br#
  |  _________________^
3 | |         [
  | |_
```

However, the problem isn't that I wanted to use `br#\n" ... "\n#`, it's that I left out the `"`s completely.

I thought the confusion was perhaps because the raw string itself contained `"`, but [the same error results if there are no `"`](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=128726992adc063b84e3daaba7d5be71):
```
    let _data = br#[ zoinks ]#;
```

Ideally the output should suggest adding the `"` after/before the `r#`/ending `#`.  Alternatively it could at least mention the quote-requiring syntax.  (If this seems too implicitly obvious, note that [not every language](https://perldoc.perl.org/perlop#Quote-and-Quote-like-Operators) requires quotes.)

No change in output on Nightly or Beta.
Repository: PowerToys
Issue: PT Run - Allow us to choose shortcut for "open containing folder" and "open path in console"
Labels: Idea-Enhancement,Product-PowerToys Run,Run-Plugin,Run-Plugin Manager

### Description of the new feature / enhancement

Allow us to choose shortcut for "open containing folder" and "open path in console". in the search menu To me, using ALT+Enter or CTRL+Enter makes a lot more sense. Allowing us to choose the shortcuts would be helpful.

### Scenario when this would be used?

Everyday usage.

### Supporting information

_No response_
Repository: vscode
Issue: Configuration defaults are not displayed in feature contributions tab of extension editor
Labels: feature-request,config,papercut :drop_of_blood:

Testing #138075

I created an extension that solely consist of the `package.json` file:
```json
{
    "name": "settings-override",
      "displayName": "settings-override",
      "description": "testing settings overrides",
      "version": "0.0.1",
      "engines": {
          "vscode": "^1.63.0"
      },
      "contributes": {
          "configurationDefaults": {
              "[markdown]": {
                  "editor.wordWrap": "on"
              }
          }
      }
 }
```

When I install this extension as a `vsix` I get the following:
1. The settings details page does not show any contributions: 
![image](https://user-images.githubusercontent.com/4674940/144765455-571a9892-4d5c-46c8-882f-4f157a494313.png)
Repository: PowerToys
Issue: [PowerRename] Change default to "Apply and exit" instead of "Apply"
Labels: Idea-Enhancement,Product-PowerRename

### Description of the new feature / enhancement

In PowerRename, I would prefer "Appy and exit" as the Default for the Apply-Button or at least an Option in the Setting to choose the default.


### Scenario when this would be used?

I only apply one change to a batch of files. So it's an extra click every time I use the tool. 
I found this more convenient in the earlier versions. Apart from the fact that the old UI took up much less space.

### Supporting information

_No response_
Repository: rust
Issue: Which MIR passes should run on generator drop shims?
Labels: T-compiler,A-MIR,C-bug,A-coroutines

Under normal circumstances, MIR shims have the following 5 passes applied:
- [`AddMovesForPackedDrops`](https://github.com/rust-lang/rust/blob/e2116acae59654bfab2a9729a024f3e2fd6d4b02/compiler/rustc_mir_transform/src/add_moves_for_packed_drops.rs#L8-L39)
- [`RemoveNoopLandingPads`](https://github.com/rust-lang/rust/blob/e2116acae59654bfab2a9729a024f3e2fd6d4b02/compiler/rustc_mir_transform/src/remove_noop_landing_pads.rs)
- `SimplifyCfg` (a trivial cleanup pass)
- [`CriticalCallEdges`](https://github.com/rust-lang/rust/blob/e2116acae59654bfab2a9729a024f3e2fd6d4b02/compiler/rustc_mir_transform/src/add_call_guards.rs)
- [`AbortUnwindingCalls`](https://github.com/rust-lang/rust/blob/e2116acae59654bfab2a9729a024f3e2fd6d4b02/compiler/rustc_mir_transform/src/abort_unwinding_calls.rs)

However, generator drop shims are created by [cloning the MIR for the original generator](https://github.com/rust-lang/rust/blob/e2116acae59654bfab2a9729a024f3e2fd6d4b02/compiler/rustc_mir_transform/src/generator.rs#L921) (?), which means they start out in `MirPhase::GeneratorLowering`. Prior to #91475, `run_passes` silently returned without doing anything if the `MirPhase` was greater than or equal to the expected one, so the aforementioned MIR passes were never executed. That behavior was only relevant when building drop shims, so #91475 added an explicit check to preserve it.

Was this intentional? Notably `AddMovesForPackedDrops` and `AbortUnwindingCalls` have soundness implications, and `CriticalCallEdges` is needed to work around some codegen issues, so it seems like they should always run. However, they might not be applicable to generators specifically.

Perhaps @tmandry knows the answer, or knows someone who does?