sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: "unused import" could be more helpful ("nothing to export")
Labels: A-diagnostics,T-compiler

### Code

```Rust
mod misc {
    const WOW: usize = 1;
}

pub use misc::*;
```


### Current output

```Shell
warning: unused import: `misc::*`
 --> src/main.rs:6:9
  |
6 | pub use misc::*;
  |         ^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

warning: `playground` (bin "playground") generated 1 warning (run `cargo clippy --fix --bin "playground"` to apply 1 suggestion)
```


### Desired output

```Shell
Either an additional hint saying why this lint is complaining "There is nothing to export"

Or a new lint or something.
```


### Rationale and extra context

In more complex codebases it's not immediately obvious what the problem is. I'd prefer a message like "nothing to export".

### Other cases

_No response_

### Rust Version

```Shell
rustc 1.75.0 (82e1608df 2023-12-21)
binary: rustc
commit-hash: 82e1608dfa6e0b5569232559e3d385fea5a93112
commit-date: 2023-12-21
host: aarch64-apple-darwin
release: 1.75.0
LLVM version: 17.0.6
```


### Anything else?

_No response_
Repository: pytorch
Issue: [FakeTensor] calling a view op mutates the nbytes on the input's storage
Labels: triaged,oncall: pt2,module: fakeTensor

```
import torch
from torch._subclasses import FakeTensorMode

with FakeTensorMode():
    x = torch.randn(4, 2)
    print(id(x.untyped_storage()))
    print(id(x.untyped_storage()))
    print(x.untyped_storage().nbytes())
    y = x.as_strided((4, 2), (1, 2))
    print(id(x.untyped_storage()))
    print(x.untyped_storage().nbytes())
```

prints:
```
139697665009088
139697665009088
32
139697665009088
24
```

I printed the storage id just to show that the storage is not getting swapped out - we are inplace changing the nbytes on the input's storage.

It looks like this is happening because:
(1) FakeTensor caching eventually calls `set_()` to handling aliasing when it sees a view op ([code](https://github.com/pytorch/pytorch/blob/main/torch/_subclasses/fake_tensor.py#L1125))
(2) `set_`'s meta function seems to mutate the nbytes ([code](https://github.com/pytorch/pytorch/blob/main/aten/src/ATen/native/TensorShape.cpp#L426))

cc @ezyang @msaroufim @anijain2305 @chauhang @eellison
Repository: tauri
Issue: [bug] Deadlock when sending events with tracing enabled (v2 beta)
Labels: type: bug,status: needs triage

### Describe the bug

[ moving this here from Discord ]

I'm getting a deadlock when I try to resize the window (or re-focus it, or any other action that sends a window event from the main thread to itself).

See the video for some more details, but this is the gist:

It seems like the deadlock is caused when one of my (not main) threads runs a `window.emit('whatever', ...)`, which acquires a lock on the webview and holds it until the script has been run (I think - not 100% sure on what it waits for). Then when I resize the window, that tries to acquire a lock on the webview too, which is already locked by the emitted event. Then it just hangs forever because it can't get the lock until the main thread runs the emitted JS thing, which will never happen because it's paused waiting for the lock 🙃 That's my theory anyway.

I noticed it seemed to start happening when I added the tauri-devtools plugin. With Fabian's suggestion in Discord, I was able to create a minimal reproduction with just the tauri `tracing` feature enabled. I can't get it to happen when `tracing` is not enabled.

Fabian thought this might be related: https://github.com/tauri-apps/tauri/pull/9429

https://github.com/tauri-apps/tauri/assets/505704/4f4f5b9d-ad1d-4dce-a030-93c341e90798

### Reproduction

https://github.com/dceddia/tauri-tracing-freeze

### Expected behavior

Ideally no deadlock 😄

### Full `tauri info` output

```text
This is from the minimal repro:

Projects/tauri-tracing-freeze % pnpm tauri info

> tauri-tracing-freeze@0.0.0 tauri /Users/dceddia/Projects/tauri-tracing-freeze
> tauri "info"


[✔] Environment
    - OS: Mac OS 14.2.1 X64
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.77.1 (7cf61ebde 2024-03-27)
    ✔ cargo: 1.77.1 (e52e36006 2024-03-26)
    ✔ rustup: 1.27.0 (bbb9276d2 2024-03-08)
    ✔ Rust toolchain: stable-aarch64-apple-darwin (default)
    - node: 20.8.0
    - pnpm: 8.11.0
    - yarn: 1.22.21
    - npm: 10.1.0

[-] Packages
    - tauri [RUST]: 2.0.0-beta.14
    - tauri-build [RUST]: 2.0.0-beta.11
    - wry [RUST]: 0.39.0
    - tao [RUST]: 0.27.0
    - tauri-cli [RUST]: 1.4.0
    - @tauri-apps/api [NPM]: 2.0.0-beta.7
    - @tauri-apps/cli [NPM]: 2.0.0-beta.12

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - framework: Svelte
    - bundler: Vite
```


### Stack trace

```text
There's no crash, but check out the video for some relevant stack traces while execution was paused.
```


### Additional context

_No response_
Repository: pytorch
Issue: Update example for FSDP optim_state_dict
Labels: triaged,module: fsdp

### 📚 The doc issue

The function signature is `optim_state_dict(model, optim, optim_state_dict=None, group=None)` but the example is calling `optim_state_dict = FSDP.optim_state_dict_to_load(optim_state_dict, model, optim)` which passes the args in the wrong order.

Link: https://pytorch.org/docs/stable/fsdp.html#torch.distributed.fsdp.FullyShardedDataParallel.optim_state_dict

### Suggest a potential alternative/fix

Update the docs to show passing in the arguments correctly.  

cc @zhaojuanmao @mrshenli @rohan-varma @awgu @fegin @penguinwu @kwen2501 @chauhang
Repository: tauri
Issue: [v2]Uncaught (in promise) missing Origin header
Labels: type: documentation

i use this code to show a window:
```typescript
import {WebviewWindow} from "@tauri-apps/api/webviewWindow";
async function handleKeydown(){
  const appWindow = WebviewWindow.getByLabel('tool')
  console.log(appWindow);
  console.log(appWindow?.window);
  console.log(await appWindow?.isVisible())
  // await appWindow?.show()
}
```
but encounter some problem:
```
_WebviewWindow {label: 'tool', listeners: {…}}
POST http://ipc.localhost/plugin%3Awindow%7Cis_visible 400 (Bad Request)
:1420/#/CandleChart:1  Uncaught (in promise) missing Origin header
```
![image](https://github.com/tauri-apps/tauri/assets/76581880/4352b1ef-539c-4fde-92e3-d1dcd5c2c968)
I am a beginner in the front-end, and I am not sure if it is because tauri is not properly configured or just because of a front-end issue.
I have reviewed the documentation and issue, but did not find any similar issues, so how should I solve them?
Repository: terminal
Issue: Legacy mode + shortcut propsheet may reset Default Terminal setting
Labels: Product-Conhost,Issue-Bug,Area-DefApp,zInbox-Bug

While messing around on Windows 10 I came across an 'automatic' reset of the Let Windows Decide setting.  I don't know if this relates to what triggered the initial report.  Tested on Win10 21H2 and 22H2 (the latter with or without Windows Terminal installed). Don't have a Win11 system to test on. I have a console-using application with a Desktop shortcut. Right clicking the shortcut and selecting Properties shows a Properties dialog with all of the Console specific tabs.  The Options tab has the option 'Use legacy console'.  To reproduce:

1 - open Settings/developers and set default terminal option to Windows Console Host.
2 - close the settings window (reopening and checking verifies it has stayed 'set')
3 - Access the Properties menu _by right clicking on the shortcut_
4 - Navigate to Options, and toggle (either select or deselect) the use Legacy console option.   
5 - close the Properties dialog.  
6 - reopen developer Settings.  Note that terminal option has been reset to Let Windows Decide.

Repeated this on systems with and without Windows Terminal installed.  On windows 10 it seems 'let windows decide' still reverts to conhost.exe.  If this also happens on win11, I believe it's expected to chose Windows Terminal.  So it seems this could cause users to have their expected terminal switched unknowingly.  Note that if I go to the properties menu within the open application to set the Legacy property, this change does not happen.  I don't know what's different about accessing the properties from a shortcut vs from within an open application.

_Originally posted by @NRJank in https://github.com/microsoft/terminal/issues/15654#issuecomment-2051995221_
Repository: vscode
Issue: "Open Recent" menu don't expand environment variables (Git Bash) on Windows machine
Labels: bug,windows,confirmation-pending,terminal-persistence,terminal-process

<!-- ⚠️⚠️ 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**/No

<!-- 🪓 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. -->
- VS Code Version: `1.88.1`
- OS Version: Microsoft Windows 11 Pro 10.0.22631 Build 22631

Steps to Reproduce:

1. Open the project using Terminal:

```bash
$ code .
```

2. Check variable in Git Bash using Terminal (VSCode):

```bash
$ echo $ANDROID_SDK_ROOT/
C:\Users\alimektor\AppData\Local\Android\Sdk
```

3. Close the **VSCode**.
4. Open **VSCode**→ **File** → **Open Recent**  → **`<project>`**
5. Check variable in Git Bash using Terminal (VSCode):

```bash
$ echo $ANDROID_HOME 
```

Expected result:

```text
C:\Users\alimektor\AppData\Local\Android\Sdk
```

Actual result:

```text
%LOCALAPPDATA%\Android\Sdk
```
Repository: terminal
Issue: Reported incompatibility with GNU Octave
Labels: Area-Server,Issue-Bug,Product-Terminal,Priority-2

The [GNU Octave](octave.org) is a cross platform project built to use the default OS terminal. Currently we would love to be able to identify if that is the new Windows Terminal.  [There is some incompatibility between conhost and the new Windows Terminal](https://savannah.gnu.org/bugs/index.php?63430) that is [causing](https://savannah.gnu.org/bugs/index.php?63430) [strange](https://stackoverflow.com/questions/77490853/octave-showing-weird-output-and-command-window-not-working/77694207) [artifacts](https://stackoverflow.com/questions/77614821/octaves-comand-window-glitches-when-i-run-a-script/77620351) and [program](https://octave.discourse.group/t/octave-crashing-with-weird-characters-and-not-loading/) [crashes](https://stackoverflow.com/questions/77474803/octave-crashes-running-a-script-that-used-to-run-with-no-issues/77578495) for users of the new Windows Terminal that became very apparent when win11 made it the default. Octave is primarily developed on linux and crossbuilt for windows users, and we have few windows developers working that part of the program.

For now we wanted to create a script to try to identify if Octave was started in the Windows Terminal to prompt the user to switch, but so far have just settled on checking if the the registry key was set for having Windows Console Host be system default, and[ prompt the Windows users to switch the system default to that if it's not](https://octave.discourse.group/t/workaround-for-weird-behavior-of-command-window-widget-in-windows/4981). Yes, it is a rather poor workaround. but it's effective. Until we have the developer resources to better troubleshoot the conhost / windows terminal incompatibility (or finish developing a separate, cross-platform compatible terminal widget to bundle with Octave), that change solves the problem for the users. But it does come with some false positives for the prompt because it gets set off when the windows setting is "let windows decide" even if that wouldn't use the new terminal, causing some other user confusion.   So, it would at least be cleaner if at startup we could positively identify the Windows terminal.

_Originally posted by @NRJank in https://github.com/microsoft/terminal/issues/7434#issuecomment-2050836000_
Repository: material-ui
Issue: [docs-infra] Dark mode not persisting after switching from light mode 
Labels: scope: docs-infra

### Steps to reproduce

Link to live example: (required)

Steps:
1.Navigate to the website in light mode.
2.Switch to dark mode.
3.Note the appearance in dark mode.
4.Refresh the page or navigate to another page within the website.


### Current behavior

After switching from light mode to dark mode, the website briefly displays in light mode before switching back to dark mode.

https://github.com/mui/material-ui/assets/93616362/5c558e6d-cfff-469e-8271-bcc007c00889



### Expected behavior

The website should consistently remain in dark mode after the user has selected it, regardless of previous light mode usage.

### Context

This issue affects the user experience of the website, particularly for users who prefer dark mode for extended periods. Consistent dark mode usage is expected for better accessibility and visual comfort.

### Your environment

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.
```
</details>


**Search keywords**: MUI, dark mode, light mode, bug, behavior, environment, reproducible
Repository: pytorch
Issue: JIT reports RuntimeError when decorating forward with torch.jit.script
Labels: oncall: jit

### 🐛 Describe the bug

Hi there, I have accidentally put `@torch.jit.script` above the `forward` method and it produces a strange error.
I guess the decorator should be ignored or report a clearer message if this is not an expected case.
Thank you!

```python
import torch
from torch import nn

class Model(nn.Module):
    def __init__(self, h: int = 16) -> None:
        super().__init__()
        self.fc1 = nn.Linear(h, h)

    @torch.jit.script
    def forward(self, x: torch.Tensor):
        return torch.tanh(self.fc1(x))
    
m = Model(42)
y = m(torch.randn(42, 42))
```

```
Traceback (most recent call last):
  File "/path/to/test.py", line 4, in <module>
    class Model(nn.Module):
  File "/path/to/test.py", line 9, in Model
    @torch.jit.script
     ^^^^^^^^^^^^^^^^
  File "/path/to/site-packages/torch/jit/_script.py", line 1395, in script
    fn = torch._C._jit_script_compile(
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeError:
'Tensor (inferred)' object has no attribute or method 'fc1'.:
  File "/path/to/test.py", line 11
    @torch.jit.script
    def forward(self, x: torch.Tensor):
        return torch.tanh(self.fc1(x))
                          ~~~~~~~~ <--- HERE
```

### Versions

PyTorch version: 2.2.1
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 14.4.1 (arm64)
GCC version: Could not collect
Clang version: 15.0.0 (clang-1500.3.9.4)
CMake version: version 3.29.2
Libc version: N/A

Python version: 3.12.2 | packaged by conda-forge | (main, Feb 16 2024, 20:54:21) [Clang 16.0.6 ] (64-bit runtime)
Python platform: macOS-14.4.1-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Apple M2 Max

Versions of relevant libraries:
[pip3] numpy==1.26.4
[pip3] torch==2.2.1
[pip3] torchvision==0.17.1
[conda] Could not collect

cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel @ezyang @msaroufim @bdhirsh @anijain2305 @chauhang
Repository: angular
Issue:  Rename Change detection "Default" 
Labels: area: core,core: change detection

### Description

`Default` is just the worst name for an enum option - [Alex](https://twitter.com/synalx/status/1777715839837577433)

I agree, with the changes around signal coming default feels like a bad name. Ideally with signal people start using OnPush more. I think it be better for newcomer if it was kroe descriptive
Repository: rust
Issue: E0593 could suggest using tuple as closure arg
Labels: A-diagnostics,T-compiler,A-suggestion-diagnostics

### Code

```Rust
` stderr.lines().enumerate().find(|i, line| line == ice_msg)`
```


### Current output

```Shell
Checking icemaker v0.1.0 (/home/matthias/vcs/github/icemaker_tree_update/icemaker)
error[E0593]: closure is expected to take 1 argument, but it takes 2 arguments
    --> src/main.rs:1082:44
     |
1082 |                 stderr.lines().enumerate().find(|i, line| line == ice_msg)
     |                                            ^^^^ --------- takes 2 arguments
     |                                            |
     |                                            expected closure that takes 1 argument

For more information about this error, try `rustc --explain E0593`.
```


### Desired output

```Shell
something like help/hint:
wrap the closure args in a tuple

1082 |                 stderr.lines().enumerate().find(|(i, line)| line == ice_msg)
     | +                                               -+-------+- warp closure args in a tuple
```


### Rationale and extra context

_No response_

### Other cases

_No response_

### Rust Version

```Shell
rustc 1.79.0-nightly (a07f3eb43 2024-04-11)
binary: rustc
commit-hash: a07f3eb43acc5df851e15176c7081a900a30a4d7
commit-date: 2024-04-11
host: x86_64-unknown-linux-gnu
release: 1.79.0-nightly
```


### Anything else?

_No response_
Repository: PowerToys
Issue: Very Small Translation Error in German
Labels: Issue-Bug,Product-Settings,Area-Localization,Loc-Sent To Team,Issue-Translation

### Microsoft PowerToys version

0.80.1

### Utility with translation issue

Settings

### 🌐 Language affected

German

### ❌ Actual phrase(s)

"Fensters anheften"
![grafik](https://github.com/microsoft/PowerToys/assets/71886240/cf666bf2-f0bd-47d3-81a6-4b4f05772c33)


### ✔️ Expected phrase(s)

"Fenster anheften"

### ℹ Why is the current translation wrong

"Fenster" (German word for "window") has stays the same in Plural form ("one Fenster", "multiple Fenster").
Repository: rust
Issue: Using `as` to get `todo!` to work with `impl` return gives false unreachable code warning
Labels: A-diagnostics,T-compiler

### Code

```Rust
pub fn f() -> impl Iterator<Item = ()> {
    todo!() as core::iter::Empty<()>
}
```


### Current output

```Shell
warning: unreachable expression
 --> src/lib.rs:2:5
  |
2 |     todo!() as core::iter::Empty<()>
  |     -------^^^^^^^^^^^^^^^^^^^^^^^^^
  |     |
  |     unreachable expression
  |     any code following this expression is unreachable
  |
  = note: `#[warn(unreachable_code)]` on by default

warning: `playground` (lib) generated 1 warning
```


### Desired output

```Shell
No warning
```


### Rationale and extra context

Using `todo!()` with a return type that is `impl` currently causes a type error. Using `as` to give it a specific type fixes that but brings this incorrect warning message.

`as T` by itself shouldn't really be considered an expression.

### Other cases

_No response_

### Rust Version

```Shell
rustc 1.77.2 (25ef9e3d8 2024-04-09)
binary: rustc
commit-hash: 25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04
commit-date: 2024-04-09
host: aarch64-apple-darwin
release: 1.77.2
LLVM version: 17.0.6

rustc 1.78.0-beta.6 (27011d5dc 2024-04-09)
binary: rustc
commit-hash: 27011d5dc09a8d1ac2289d024f54ecac9fc70d47
commit-date: 2024-04-09
host: aarch64-apple-darwin
release: 1.78.0-beta.6
LLVM version: 18.1.2

rustc 1.79.0-nightly (aa067fb98 2024-04-10)
binary: rustc
commit-hash: aa067fb984d36462548bb785da221bfaf38253f0
commit-date: 2024-04-10
host: aarch64-apple-darwin
release: 1.79.0-nightly
LLVM version: 18.1.3
```


### Anything else?

_No response_
Repository: vscode
Issue: Git - Add an option to cancel a git pull/push request if it takes too long
Labels: feature-request,git

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please review our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Before submitting, search existing issues to avoid duplicates. -->
<!-- Describe the feature you're requesting. -->
I'm uncertain whether this issue fits more as a bug or a feature request; it seems to it's more of a bug due to how annoying it is but anyways.

Context:
Here is the context, at my French engineering school, we use a hosted version of GitLab on the school servers for school projects. Accessing the server requires connecting through the school's VPN. Therefore, I must ensure that the VPN is active before pulling/pushing changes.

Problem:
The issue takes place when I forget to enable the VPN before initiating a push/pull operation in Visual Studio Code. In such cases, Visual Studio Code keeps trying to send the request persistently for 2 minutes or longer without providing an option to cancel. The only way to stop it is to restart Visual Studio Code, which gets very annoying especially when working on big projects with a lot of extensions enabled and on a not so powerful laptop. Ideally, there should be a configurable setting to define the duration Visual Studio Code retries a failed network request before prompting an error notification indicating the failure due to network issues.

Note that this issue isn't unique to my situation; it can also occur in scenarios where a user experiences Wi-Fi disruptions or any other network-related problems. I understand that it may be hard to implement the timeout, but at least add an option somewhere in the scm panel to cancel the current ongoing request, I suppose that should not be too complicated!
Repository: PowerToys
Issue:  Borderless mouse won't transfer files
Labels: Issue-Bug,Needs-Triage,Product-Mouse Without Borders

### Microsoft PowerToys version

Release v0.80.1

### Installation method

Microsoft Store

### Running as admin

Yes

### Area(s) with issue?

Mouse Utilities

### Steps to reproduce

I can't transfer files between the two computers, only text. I'm using Windows 11 Pro on one computer and Windows 10 Home Single Language on the other computer.

### ✔️ Expected Behavior

I can't transfer files between the two computers, only text. I'm using Windows 11 Pro on one computer and Windows 10 Home Single Language on the other computer.

### ❌ Actual Behavior

Only transfers text.

### Other Software

There is not.