sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: tauri
Issue: [bug] MacOS menu doesn't change based on window
Labels: type: bug,platform: macOS,status: needs triage

### Describe the bug

This might be a "works as intended" but it should be documented.
Basically, the menu stays with the value of the latest call to `.menu` and doesn't change based on the currently focused window. Meaning that you are kinda forced to use a single menu for the whole application.

### Reproduction

1. Start with any basic application 
2. Open a second window with with `.menu`
3. The menu sticks with the menu defined in the second window

### Expected behavior

Unsure what behaviour is expected on MacOS, it would be nice if it switched but worst case it should be documented.

### Platform and versions

```
Environment
  › OS: Mac OS 11.6.3 X64
  › Node.js: 16.17.0
  › npm: 8.15.0
  › pnpm: 7.17.1
  › yarn: 1.22.15
  › rustup: 1.25.1
  › rustc: 1.65.0
  › cargo: 1.65.0
  › Rust toolchain: stable-x86_64-apple-darwin

Packages
  › @tauri-apps/cli [NPM]: 1.2.0 (outdated, latest: 1.2.1)
  › @tauri-apps/api [NPM]: 1.2.0
  › tauri [RUST]: git+https://github.com/caido/dependency-tauri?branch=caido#f73dc6487fa9e5ca8f60b092d31ea7f5d8a7a24b (1.2.0),
  › tauri-build [RUST]: git+https://github.com/caido/dependency-tauri?branch=caido#f73dc6487fa9e5ca8f60b092d31ea7f5d8a7a24b (1.2.0),
  › tao [RUST]: 0.15.3,
  › wry [RUST]: 0.22.0,

App
  › build-type: bundle
  › CSP: default-src blob: data: filesystem: ws: wss: http: https: tauri: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self'
  › distDir: ../caido-ui/dist
  › devPath: http://localhost:10000/
  › framework: Vue.js

App directory structure
  ├─ dist
  ├─ node_modules
  ├─ scripts
  └─ src
```

### Stack trace

_No response_

### Additional context

_No response_
Repository: rust
Issue: Confusing error message for unable to infer types
Labels: A-diagnostics,T-compiler,D-newcomer-roadblock,D-terse

Given the following [code](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=43c2179566e47a3d0540c3f91fde0672):

```rust
fn main() {
    let s = "2";
    let vec: Vec<Vec<usize>> = vec![vec![]; 10];

    let f = |x: &str| x.parse().unwrap();
    vec[f(s)].push(10);
}

```

The current output is:

```
error[E0282]: type annotations needed
 --> min.rs:6:5
  |
6 |     vec[f(s)].push(10);
  |     ^^^^^^^^^ cannot infer type

error: aborting due to previous error

For more information about this error, try `rustc --explain E0282`.
```

The error message as it is is quite confusing, especially for beginners (like me). The _actual_ root cause of the error is at the definition of `f`, where the return type of `.parse` (and hence of `f`) cannot be infered, since there is no way for the compiler to tell for what types is `SliceIndex<>` implemented for.

---
**Suggestion 1:** I propose to improve the error message so that it points to the part `f(s)` specifically, and even better to also tell the user to specify the type of `f`, even though the compiler might not be able to tell what it should be.

**Suggestion 2:** Not sure if it is a good idea, but adding a special warning / hint for indexing vectors might be nice, since this pattern is so common for beginners? Something like this already exists for a different type of error, I believe:

```rust
fn main() {
    let s = "2";
    let vec: Vec<Vec<usize>> = vec![vec![]; 10];

    let f = |x: &str| x.parse::<isize>().unwrap();
    vec[f(s)].push(10);
}
```

Gives the error

```
error[E0277]: the type `[Vec<usize>]` cannot be indexed by `isize`
 --> min.rs:6:9
  |
6 |     vec[f(s)].push(10);
  |         ^^^^ slice indices are of type `usize` or ranges of `usize`
  |
  = help: the trait `SliceIndex<[Vec<usize>]>` is not implemented for `isize`
  = help: the trait `SliceIndex<[T]>` is implemented for `usize`
  = note: required for `Vec<Vec<usize>>` to implement `Index<isize>`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0277`.
```

This is my first time submitting a report, hopefully I didn't get anything wrong ^_^
Repository: stable-diffusion-webui
Issue: [Bug]: Batch Img2Img doesn't retain PNG information
Labels: bug-report

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What happened?

I'm using batch Img2Img, but the pics that're outputting are coming out as Jpg.

I reconfirmed that the setting that converts to jpg if the png is too large is unchecked and it still does it.

I converted the input images to png and now PNGs are outputted but no information is stored on it like txt2img.  I'm using Dynamic prompting so it would be helpful to have this information retained.

### Steps to reproduce the problem

1. Go to img2img -> Batch img2img and Input Input and Output Directory
2. Press Generate
3. Drag PNG into PNG info and nothing is displayed


### What should have happened?

No, the data should write to the png

### Commit where the problem happens

44c46f0ed395967cd3830dd481a2db759fda5b3b

### What platforms do you use to access UI ?

Windows

### What browsers do you use to access the UI ?

Brave

### Command Line Arguments

_No response_

### Additional information, context and logs

_No response_
Repository: godot
Issue: Godot 4.0 crashes if game window closed while debug break
Labels: bug,platform:windows,topic:core,needs testing

### Godot version

4.0b6

### System information

Windows 10

### Issue description

In 3.x if the game breaks during a debug error, you could close the game window and go back to Godot to fix the issue, but since 4.0 if you try to X the game window while it's running, it crashes and hangs until windows has to force it to close.

### Steps to reproduce

- Run a game in godot
- Wait until debug error causes the game to halt
- Close the game window
![image](https://user-images.githubusercontent.com/16231628/205739082-9d08dc01-e20a-4627-8447-9a0353b38eae.png)


### Minimal reproduction project

[crashbug.zip](https://github.com/godotengine/godot/files/10157743/crashbug.zip)
Repository: godot
Issue: editor crash on Viewport own_world disable
Labels: bug,topic:editor,confirmed,crash

### Godot version

v3.5.1.stable.official [6fed1ffa3]

### System information

macOS 13.0.1 (22A400)

### Issue description

while working on a 3d sky box, I managed to create a node structure which will crash the editor, once I select the checkbox own_world of a Viewport.

error message:

Exception Type:        EXC_BAD_ACCESS (SIGABRT)
Exception Codes:       KERN_INVALID_ADDRESS at 0x00000000000002b0
Exception Codes:       0x0000000000000001, 0x00000000000002b0

### Steps to reproduce

in the project attached, enable the own_world checkbox in the SkyBox2 node.

### Minimal reproduction project

[own_world_crash.zip](https://github.com/godotengine/godot/files/10157777/own_world_crash.zip)
Repository: stable-diffusion-webui
Issue: [Feature Request]: Multi-resolution Textual Inversion
Labels: enhancement,extension-request

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

Unsure if really better than current TI but, for the sake of completeness :

Be able to train "multi-resolution" textual inversion embeddings as in https://github.com/giannisdaras/multires_textual_inversion

### Proposed workflow

1. Go to .... 
2. Press ....
3. ...


### Additional information

_No response_
Repository: rust
Issue: Tracking Issue for Style Evolution (RFC 3338)
Labels: C-tracking-issue,A-rustfmt,S-tracking-unimplemented,T-style

This is a tracking issue for the RFC "Style Evolution" (rust-lang/rfcs#3338).

This feature will require development in rustfmt, a bit of development in cargo, and stabilization of both; it will also require ongoing work to develop (and document) new style editions, each of which will start out unstable and later get stabilized. This tracking issue should remain open until we've done the implementation and successfully tested it with a new (unstable) style edition.

### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

### Steps

- [x] Open a new (nightly only) style edition 2024, and start adding style improvements to it incrementally, documenting them in the style guide
- [ ] Implementation in `rustfmt`/`cargo-fmt` (both owned by t-rustfmt), specifics tracked in https://github.com/rust-lang/rustfmt/issues/5720
- [ ] Stabilize the `rustfmt` and `cargo-fmt` options.
- [ ] Stabilize the 2024 style edition

[stabilization-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs

### Implementation history

<!--
Include a list of all the PRs that were involved in implementing the feature.
-->
Repository: PowerToys
Issue: Unblock using "Alt + Space" to move a window beyond the top of the monitor (to hide the title bar)
Labels: Product-Window Manager

### Description of the new feature / enhancement

Add an option to unblock using "Alt + Space" to move a window beyond the top of the monitor (to hide the title bar). Currently windows that are moved past the top of the monitor area snap back to ensure the title bar always remains visible. In other words, disable the vertical "Title Bar Guard" (feature name uncertain).

### Scenario when this would be used?

It would reclaim some vertical screen space for power users relying on hotkeys to navigate. Also, many legacy games are forced to run in windowed mode due to fullscreen compatibility issues and cannot be resized. This feature would prevent the lower portion of the window from being cut off to display the unwanted title bar.

### Supporting information

This would achieve a similar end-result as the following requests:
https://github.com/BiGilSoft/WindowTop/issues/199
https://github.com/microsoft/PowerToys/issues/430
https://github.com/microsoft/PowerToys/issues/9276
Repository: rust
Issue: Confusing compilation error when forgetting to deref_mut in a chain of iterators
Labels: A-diagnostics,T-compiler,D-confusing,D-newcomer-roadblock,D-terse

This doesn’t compile:

```rust
fn foo(items: &mut [u8]) -> u8 {
    // The centent of this function isn’t important
    items.sort();
    42
}

fn main() {
    let mut x: Vec<Vec<u8>> = vec![
        vec![0, 1, 2],
        vec![3, 4, 5],
    ];
    let x = x
        .iter_mut()
        .map(foo) // <-- this line
    println!("{:?}", x);
}
```

```rust
error[[E0631]](https://doc.rust-lang.org/stable/error-index.html#E0631): type mismatch in function arguments
  --> src/main.rs:20:14
   |
1  | fn foo(items: &mut [u8]) -> u8 {
   | ------------------------------ found signature defined here
...
20 |         .map(foo);
   |          --- ^^^ expected due to this
   |          |
   |          required by a bound introduced by this call
   |
   = note: expected function signature `fn(&mut Vec<u8>) -> _`
              found function signature `for<'r> fn(&'r mut [u8]) -> _`
note: required by a bound in `map`

For more information about this error, try `rustc --explain E0631`.
```

The solution is either to call first deref

```rust
.map(std::ops::DerefMut::deref_mut).map(foo)
```
or
```rust
.map(|items| items.as_mut())
```

Or to use a lambda

```rust
.map(|mut items| foo(&mut items))
```

The current error doesn’t help to understand what the issue is and it’s very confusing because it may look like a lifetime error (because of the `for<'r>`…).

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=c6ac2ca7a31b126442978d30419e07a8

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: storybook
Issue: [Feature Request]: remove babel transformations in web-components-webpack preset
Labels: help wanted,maintenance,web-components

### Is your feature request related to a problem? Please describe

The [web-components-webpack preset](https://github.com/storybookjs/storybook/tree/next/code/presets/web-components-webpack) add some babel transformation by default to some specific libraries.

With storybook v7 they are not needed anymore and only increase complexity / build time:

- supports import.meta.url: webpack 5 already supports it - https://webpack.js.org/api/module-variables/#importmetaurl . Even if not supported, this is not really needed to run web components in storybook or in general
- transforms some libraries / packages (polymer, lit, vaadin): with v7 dropping support to ie does not makes sense anymore to transform such libraries. Also the selection of libraries is arbitrary / questionable: polymer is not a thing anymore. Why vaadin, a freemium product? Why not ui5, carbon, spectrum libraries - as good or better than vaadin?

### Describe the solution you'd like

Remove babel transformations in [web-components-webpack preset](https://github.com/storybookjs/storybook/tree/next/code/presets/web-components-webpack) 

### Describe alternatives you've considered

Remove [web-components-webpack preset](https://github.com/storybookjs/storybook/tree/next/code/presets/web-components-webpack)

### Are you able to assist to bring the feature to reality?

yes, I can

### Additional context

Even with storybook v6 this is not needed for those that target evergreen browsers. In my projects, i manually remove babel transformation:

```js
 webpackFinal: async function (config) {
      const ruleIndex = config.module.rules.findIndex(
        (rule) => rule.use && rule.use.options && rule.use.options.babelrc === false
      )
      if (ruleIndex !== -1) {
        config.module.rules.splice(ruleIndex, 1)
      }     
    return config
  },
```
Repository: TypeScript
Issue: `hereby runtests --no-typecheck --tests 'Public API'` produces bad baselines if not preceded by `npm run build`
Labels: Infrastructure

I guess running the tests tends to skip .d.ts emit for speed, but that emit is necessary for saving the API baseline. Consequently it’s very easy to accept and commit out-of-sync API baselines. I’m not sure what the best fix is here. @jakebailey thoughts?
Repository: vscode
Issue: Support for different default language
Labels: feature-request,l10n-platform

Hi,
I checked that bundle.l10n.json can only be set in English.
In our extension, the strings in the code are in Spanish, like this:

`const message = l10n.t('Hola');
`

This generates a bundle.l10n.json in Spanish, and we want to have a bundle.l10n.en.json translated in English.
But this doesn't work, since for English language it doesn't take the strings from bundle.l10n.en.json (it takes them from the l10n.t text)

In other words, if I have a file  `bundle.l10n.en.json` doesn't work if my vscode is in english. Instead, it takes the string from l10n.t().

Do you have any solution for this?

Thank you very much
Repository: react
Issue: Bug: non-Hook startTransition waits for stale work to finish
Labels: Type: Needs Investigation,Component: Concurrent Features

Not sure if this is a bug, but it breaks my expectations.

Here's the same example with `useTransition` and `startTransition`.

- `useTransition`: https://codesandbox.io/s/kgs8wi?file=/App.js
- `startTransition`: https://codesandbox.io/s/delicate-mountain-fr04u3?file=/App.js

Repro steps:

1. Click "Posts"
2. Immediately click "Contact"

With `useTransition`, the state change is instant because rendering slow Posts component is abandoned.

With `startTransition`, the state change is slow because it waits for the Posts component to finish rendering anyway.
Repository: pytorch
Issue: [Distributed] `Invalid scalar type` when `dist.scatter()` boolean tensor
Labels: oncall: distributed

### 🐛 Describe the bug

I am trying to scatter boolean tensor but failed with error: `Invalid scalar type` while it works well with dtype=uint8.

**torch version: 1.13.0+cu117**

```
def worker(rank, world_size):
    ...
    dtype = th.uint8
    dtype = th.bool
    scatter_list = [ th.tensor([True, True, True, True], dtype=dtype) for _ in range(4) ]
    gather_list = [ th.tensor([False, False, False, False], dtype=dtype) for _ in range(4) ]
    for i in range(world_size):
        dist.scatter(gather_list[i], scatter_list if i == rank else [], src=i)
```
```
File "/home/ubuntu/.local/lib/python3.6/site-packages/torch/distributed/distributed_c10d.py", line 2290, in scatter
    work.wait()
RuntimeError: Invalid scalar type
```

This error also happens in other distributed call like `dist.all_reduce()`.
```
import os
import torch
from torch import distributed as dist
import torch.multiprocessing as mp

def worker(rank, world_size):
    os.environ['MASTER_ADDR'] = 'localhost'
    os.environ['MASTER_PORT'] = '12355'
    device = 'cpu' #'cuda'
    dist.init_process_group('gloo' if device == 'cpu' else 'nccl', rank=rank, world_size=world_size)

    dtype = torch.bool
    #dtype = torch.uint8
    tensor = torch.tensor([0,1], dtype=dtype)
    dist.all_reduce(tensor)

if __name__ == '__main__':
    mp.spawn(worker, args=(2,), nprocs=2, join=True)
```

### Versions

Collecting environment information...
PyTorch version: 1.13.0+cu117
Is debug build: False
CUDA used to build PyTorch: 11.7
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.5 LTS (x86_64)
GCC version: (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Clang version: Could not collect
CMake version: version 3.16.3
Libc version: glibc-2.31

Python version: 3.8.10 (default, Jun 22 2022, 20:18:18)  [GCC 9.4.0] (64-bit runtime)
Python platform: Linux-5.15.0-1022-aws-x86_64-with-glibc2.29
Is CUDA available: True
CUDA runtime version: 11.7.99
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration: GPU 0: Tesla T4
Nvidia driver version: 515.65.01
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.24.0rc1
[pip3] torch==1.13.0
[pip3] torchaudio==0.13.0
[pip3] torchvision==0.14.0
[conda] No relevant packages

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu
Repository: godot
Issue: Crash in headless mode (Failed method: CanvasItem::_redraw_callback)
Labels: bug,topic:rendering,crash,regression,topic:2d

### Godot version

4.0 dev Beta 6 & 7

### System information

Arch Linux

### Issue description

My game crashes at startup when I try running it in headless mode (to run a dedicated server).
I have tested it and this *does not* happen in Beta 4, but it does from Beta 6 onwards.

Here's the output I get:

```
Failed method: CanvasItem::_redraw_callback

================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.0.beta6.official (7f8ecffa56834dce3ccbd736738b613d51133dea)
Dumping the backtrace. Please include this when reporting the bug on: https://github.com/godotengine/godot/issues
[1] /usr/lib/libc.so.6(+0x38a00) [0x7fb3c68e8a00] (??:0)
[2] ./Godot_v4.0-beta6_linux.x86_64() [0x4129a25] (??:0)
[3] ./Godot_v4.0-beta6_linux.x86_64() [0x4361ac3] (??:0)
[4] ./Godot_v4.0-beta6_linux.x86_64() [0x43630e0] (??:0)
[5] ./Godot_v4.0-beta6_linux.x86_64() [0x29491d7] (??:0)
[6] ./Godot_v4.0-beta6_linux.x86_64() [0x436378a] (??:0)
[7] ./Godot_v4.0-beta6_linux.x86_64() [0x2bbbc40] (??:0)
[8] ./Godot_v4.0-beta6_linux.x86_64() [0x2bbbd7a] (??:0)
[9] ./Godot_v4.0-beta6_linux.x86_64() [0x2be7bd8] (??:0)
[10] ./Godot_v4.0-beta6_linux.x86_64() [0x2bf9733] (??:0)
[11] ./Godot_v4.0-beta6_linux.x86_64() [0x42cc1e4] (??:0)
[12] ./Godot_v4.0-beta6_linux.x86_64() [0x29070e4] (??:0)
[13] ./Godot_v4.0-beta6_linux.x86_64() [0x48aee25] (??:0)
[14] ./Godot_v4.0-beta6_linux.x86_64() [0x4365757] (??:0)
[15] ./Godot_v4.0-beta6_linux.x86_64() [0x29c6f15] (??:0)
[16] ./Godot_v4.0-beta6_linux.x86_64() [0xe5e375] (??:0)
[17] ./Godot_v4.0-beta6_linux.x86_64() [0xd98200] (??:0)
[18] /usr/lib/libc.so.6(+0x23290) [0x7fb3c68d3290] (??:0)
[19] /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7fb3c68d334a] (??:0)
[20] ./Godot_v4.0-beta6_linux.x86_64() [0xdb974e] (??:0)
-- END OF BACKTRACE --
================================================================
fish: Job 1, './Godot_v4.0-beta6_linux.x86_64…' terminated by signal SIGABRT (Abort)
```

Full log: [godot.log](https://github.com/godotengine/godot/files/10160456/godot.log)


### Steps to reproduce

I have no idea :/

### Minimal reproduction project

I'm sorry but I have no idea.

The best I can think of to test this is to clone (with LFS!) my game Liblast from `main` branch:
https://codeberg.org/Liblast/Liblast

And try running it with `--headless`.
Repository: flutter
Issue: [web] Fix other places that use clientX/Y rather than offsetX/Y (text input?, semantics helper?)
Labels: engine,platform-web,P2,team-web,triaged-web

So far, these are the places that I've found that aren't using the correct coordinates for the events they're handling (they'd only work in full-screen mode):

### pointer_binding.dart

In the pointer_binding, it seems that 'pointerup' events are incorrectly attached to domWindow. Those should be attached to the glassPane. See:

* https://github.com/flutter/engine/blob/main/lib/web_ui/lib/src/engine/pointer_binding.dart#L690

(There's probably a need to synthesize a 'pointercancel' event if there's a pointerup detected OUTSIDE of the glassPane too!)

### text_field.dart

See:

* https://github.com/flutter/engine/blob/main/lib/web_ui/lib/src/engine/semantics/text_field.dart#L294-L299

(and below)

### semantics_helper.dart

See:

* https://github.com/flutter/engine/blob/main/lib/web_ui/lib/src/engine/semantics/semantics_helper.dart#L331-L340

(Using client coordinates rather than offset. Note that for touch events, there's no "offset" and it needs to be computed from the clientBoundingRect of the event target!)