sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: PowerToys
Issue: Crop and Lock, but with Lock
Labels: Idea-Enhancement,Needs-Triage,Product-CropAndLock

### Description of the new feature / enhancement

Allow Crop and Lock to actually lock (dont update, when for example scrolling), what was cropped. As it is, its a real let down that word Lock is only part of the tools name, as theres no lock functionality to be found that I can see, Id love to be wrong, because this would be really useful.

### Scenario when this would be used?

Allow cropping a section of a large code file (say top while working at the bottom) as reference while working elsewhere in the file.


### Supporting information

_No response_
Repository: next.js
Issue: `useEffect` no longer run twice in React strict mode
Labels: bug

### Link to the code that reproduces this issue

https://github.com/chungweileong94/nextjs-strict-mode-useeffect-bug

### To Reproduce

1. Start the app in development mode
2. Navigate the page

### Current vs. Expected behavior

**Expected:**
- The `useEffect` code should run twice in development mode, which should show some errors (or double "effect" logs) in the console

**Current:**
- The `useEffect` code only run once.

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.5.0: Wed May  1 20:16:51 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T8103
  Available memory (MB): 16384
  Available CPU cores: 8
Binaries:
  Node: 20.11.1
  npm: 10.2.4
  Yarn: 1.22.21
  pnpm: 8.15.7
Relevant Packages:
  next: 14.3.0-canary.81 // Latest available version is detected (14.3.0-canary.81).
  eslint-config-next: N/A
  react: 19.0.0-beta-04b058868c-20240508
  react-dom: 19.0.0-beta-04b058868c-20240508
  typescript: 5.1.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Developer Experience

### Which stage(s) are affected? (Select all that apply)

next dev (local)

### Additional context

I tested the other strict mode behavior (double re-rendering), and it seems to be working. However, the double `useEffect` doesn't seem to work as expected according to the [React documentation](https://19.react.dev/reference/react/StrictMode#fixing-bugs-found-by-re-running-effects-in-development).
Repository: PowerToys
Issue: Fancy zones: fullscreen-mode inside a zone
Labels: Needs-Triage

### Description of the new feature / enhancement

When switching any website or app to fullscreen-mode, the full-screen-content should remain in the actual zone position and not over the whole screen while ingoring the zones.

### Scenario when this would be used?

Many apps or websites have a more clearly-arranged layout when using the fullscreen-mode, e.g. stock chart information.
In my case I would like to arrange some charts from libertex.com (e.g. https://app.libertex.com/products/indexes/FDAX/)
To avoid an overcrowded view when all charts are in window mode, I would like to arrange the fullscreen view in each zone, cf. attached screenshots.
![libertex_fullscreen](https://github.com/microsoft/PowerToys/assets/90938631/1ea064bd-2958-40e6-a01f-cc2d01d64d53)
![libertex_window](https://github.com/microsoft/PowerToys/assets/90938631/dd927bfb-d828-4e6c-9f6b-159a24712e1c)


### Supporting information

_No response_
Repository: rust
Issue: PhantomData confusing documentation
Labels: A-docs

### Location

https://doc.rust-lang.org/std/marker/struct.PhantomData.html#ownership-and-the-drop-check, via https://github.com/rust-lang/rust/blob/21e6de7eb64c09102de3f100420a09edc1a2a8d7/library/core/src/marker.rs#L728

### Summary

https://github.com/rust-lang/rust/pull/103413 updated the documentation for `PhantomData` to say

> Currently, adding a field of type `PhantomData<T>` indicates that your type *owns* data of type `T` in very rare circumstances.

I don't understand.  How rare must these circumstances be for me to use `PhantomData`?  What should I do if my type always owns data of type `T`?

I guess this is not what was meant, but I am finding it hard to figure out what the intention was and propose an improvement.  

Possibly just remove the phrase "in very rare circumstances"?
Repository: rust
Issue: Performance regression between v1.76.0 and v1.77.2
Labels: P-medium,C-bug,A-mir-opt,regression-untriaged

### Code

I'm working on some low-level bit-manipulation code, and discovered that v1.77 generates code that runs at about half the speed compared to the output of v1.76. Since the v1.77 release notes don't mention anything about an LLVM upgrade I figure there must be something going wrong in the `rustc` LLVM IR generation.

Compilable reproduction:
- [Cargo.toml](https://github.com/rust-lang/rust/files/15443250/Cargo.toml.txt)
- [main.rs](https://github.com/rust-lang/rust/files/15443251/main.rs.txt)

The inner loop is `decode_u32()`, which is sort of ugly but isn't doing anything especially complex.

```rust
pub fn decode_u32(buf: &[u8; 5]) -> (u32, usize) {
	if buf[0] < 0x80 {
		return (buf[0] as u32, 1);
	}
	if buf[0] < 0xF0 {
		let x = u32::from_le(unsafe {
			ptr::from_ref(buf).cast::<u32>().read_unaligned()
		});
		if buf[0] < 0b11000000 {
			let decoded = (x & 0x3F) | ((x & 0xFF00) >> 2);
			return (decoded, 2);
		}
		if buf[0] < 0b11100000 {
			let decoded = (x & 0x1F) | ((x & 0xFFFF00) >> 3);
			return (decoded, 3);
		}
		let decoded = (x & 0x0F) | ((x & 0xFFFFFF00) >> 4);
		return (decoded, 4);
	}
	let decoded = u32::from_le(unsafe {
		ptr::from_ref(buf)
			.cast::<u8>()
			.add(1)
			.cast::<u32>()
			.read_unaligned()
	});
	(decoded, ((buf[0] & 0x0F) + 2) as usize)
}
```

The exact timing varies depending on the distribution of input values. The attached reproduction uses a distribution for which the new code is about twice as slow.

```
$ RUSTFLAGS="-Copt-level=3" cargo +1.76.0 build --release
$ time ./target/release/main
real    0m4.182s
user    0m4.181s
sys     0m0.000s
```

```
$ RUSTFLAGS="-Copt-level=3" cargo +1.77.2 build --release
$ time ./target/release/main
real    0m7.699s
user    0m7.694s
sys     0m0.004s
```

### Version it worked on

It most recently worked on: Rust v1.76.0

### Version with regression

`rustc --version --verbose`:
```
$ rustc +1.77.2 --version --verbose
rustc 1.77.2 (25ef9e3d8 2024-04-09)
binary: rustc
commit-hash: 25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04
commit-date: 2024-04-09
host: x86_64-unknown-linux-gnu
release: 1.77.2
LLVM version: 17.0.6
```

<!--
If you know when this regression occurred, please add a line like below, replacing `{channel}` with one of stable, beta, or nightly.

@rustbot modify labels: +regression-from-stable-to-{channel} -regression-untriaged
-->
Repository: pytorch
Issue: [feature request]: Update max onnx opset to 21 for onnxruntime==1.18 compatability
Labels: module: onnx,triaged,OSS contribution wanted,onnx-triaged

## Description
[Onnxruntime==1.18 supports onnx opset 21](https://onnxruntime.ai/docs/reference/compatibility.html).

Pytorch currently does not support conversion to onnx opset 21.

## Proposed implementation
The change seems simple:
Just update the `ONNX_MAX_OPSET` constant from [/torch/onnx/_constants.py](https://github.com/pytorch/pytorch/blob/ba3b05fdf37ddbc3c301294d6a560a816335e717/torch/onnx/_constants.py#L7).

```
"""Constant values used in ONNX."""

ONNX_ARCHIVE_MODEL_PROTO_NAME = "__MODEL_PROTO"

ONNX_BASE_OPSET = 9
ONNX_MIN_OPSET = 7
ONNX_MAX_OPSET = 21
```

**Limitations:**
Using constants shifts the responsibility of updating constants to `pytorch`. Is there an alternative way of detecting that an `OPSET` is not supported without maintenance?

## Workarounds
Currently, the way to workaround this issue is to use some additional code after exporting an onnx file from pytorch:

```
import onnx

opset=21
upgradedModel = onnx.version_converter.convert_version(modelFromTorch, opset)
onnx.save(upgradedModel, modelPath)
```
Repository: rust
Issue: Wrong import hint
Labels: A-diagnostics,T-compiler,C-bug,A-suggestion-diagnostics

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code:
https://github.com/rust-lang/rust-analyzer/issues/17293

I expected to see this happen: 
```
...
help: trait `Interface` which provides `cast` is implemented but not in scope; perhaps you want to import it
|
+ use windows::core::Interface;
|
...
```
Instead, this happened: 

```
error[E0599]: no method named `cast` found for struct `IDXGISwapChain1` in the current scope
   --> src\main.rs:107:36
    |
107 |         let y: IDXGISwapChain3 = x.cast()?;
    |                                    ^^^^ method not found in `IDXGISwapChain1`
    |
   ::: C:\Users\nxcy\.cargo\registry\src\index.crates.io-6f17d22bba15001f\windows-core-0.56.0\src\interface.rs:80:8
    |
80  |     fn cast<T: Interface>(&self) -> Result<T> {
    |        ---- the method is available for `IDXGISwapChain1` here
    |
    = help: items from traits can only be used if the trait is in scope
help: trait `Interface` which provides `cast` is implemented but not in scope; perhaps you want to import it
    |
3   + use windows::windows_core::interface::Interface;
    |


```

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.78.0 (9b00956e5 2024-04-29)
binary: rustc
commit-hash: 9b00956e56009bab2aa15d7bff10916599e3d6d6
commit-date: 2024-04-29
host: x86_64-pc-windows-msvc
release: 1.78.0
LLVM version: 18.1.2
```

</p>
</details>
Repository: bitcoin
Issue: Enable `importprivkey`, `addmultisigaddress` in descriptor wallets
Labels: Feature,RPC/REST/ZMQ

### Please describe the feature you'd like to see added.

Descriptor wallets currently do not support the "legacy" import commands `importprivkey`, `importpubkey`, `importaddress`, `addmultisigaddress`, `importmulti`, and `importwallet`. This was done because the semantics of these RPC cannot be replicated in descriptor wallets, as they just fundamentally work differently (being explicit about what to watch rather than "whatever matches the bag of keys and scripts we have").

I want to suggest the possibility to reconsider that. The exact semantics cannot be replicated, but ignoring that, for many of these RPCs, the almost certain intent of the RPCs can be replicated:
* `importprivkey` and `importpubkey` can be mapped to a `combo()` descriptor
* `importaddress` can be mapped to an `addr()` descriptor
* `addmultisigaddress` can be mapped to a `multi()` descriptor, wrapped in `sh()`, `sh(wsh())`, or `wsh()` depending on the address type (already returned as the `descriptor` field in the RPC output).
* `importmulti` and `importwallet` are more involved, but do contain enough information for mapping to descriptors.

For the simpler ones out of these, it makes sense too. `importprivkey` is simpler to use than learning the descriptor syntax, and no less safe. A reason not to do this is if a user would reasonably expect different semantics, or if there are guides out there that use certain RPCs in a way that relies on the "bag of keys and scripts" behavior, but I doubt it. Another reason not to do this is lack of taproot support in these RPCs, though that could be addressed with warnings, or in some cases, extensions (e.g. nothing prevents us from adding a taproot variant to `addmultisigaddress`).

### Is your feature related to a problem, if so please describe it.

I've seen several complaints about how hard `importdescriptors` is in use for importing a private key, or creating a multisig address. 

### Describe the solution you'd like

_No response_

### Describe any alternatives you've considered

_No response_

### Please leave any additional context

_No response_
Repository: PowerToys
Issue: Windows hotkeys conflict with Powertoys's, even after changing the latter
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.81.0

### Installation method

GitHub

### Running as admin

Yes

### Area(s) with issue?

Always on Top, ColorPicker, Peek, PowerToys Run, Screen ruler, Shortcut Guide

### Steps to reproduce

1. Open PowerToys
2. Either leave the default shortcut for one module, or change it

For the Always on Top module :

3. Open File Explorer
4. Go in a folder containing images
5. Select an image
6. Use the shortcut

For the PowerToys Run module :

3. Go back on the desktop by clicking on the bottom right corner of the screen
4. Use the shortcut

### ✔️ Expected Behavior

PowerToys functions work as they should.

### ❌ Actual Behavior

Either PowerToys shortcuts don't do anything, or identical Windows shortcuts (like Win + Space, to change the keyboard's layout, initially associated with PowerToys Run) work instead

### Other Software

_No response_
Repository: godot
Issue: Label fonts don't change to 1px as shown in the setting text box when font size is enabled
Labels: confirmed,topic:gui

### Tested versions

4.3 dev 6

### System information

Godot v4.3.dev6 - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 970 (NVIDIA; 31.0.15.3623) - Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (8 Threads)

### Issue description

If you turn on font size for the font used in a label, the setting for this says the font should be 1px in size, but it doesn't change.
If you use the up/down button, or type a value in the size field, it changes, but it should immediately change to match the value shown.

It should either immediately change the font to 1px high, or the setting textbox should change to match the default font size (16px)

### Steps to reproduce

Create a label node
Add some text to it in the text setting
Under "Theme Overrides" -> "Font size", turn on the setting. You will see that the font size should be 1px, but the text in your game window stays the same. 
Change 1px value and note that the displayed text then changes


### Minimal reproduction project (MRP)

[FontTest.zip](https://github.com/godotengine/godot/files/15443663/FontTest.zip)
Repository: godot
Issue: C#: ChkCastAny InvalidCastException caused by freeing instances with references in Godot.Collections.Array<T>
Labels: bug,topic:dotnet,crash

### Tested versions

Reproductible:
v4.2.1.stable.mono.official [b09f793f5]
v4.2.2.stable.mono.official [15073afe3]
### System information

Godot v4.2.1.stable.mono - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4070 Ti (NVIDIA; 31.0.15.4584) - AMD Ryzen 7 3700X 8-Core Processor (16 Threads)

### Issue description

Freeing a game object with QueueFree changes its type to GodotObject causing InvalidCastException when trying to access the object via typed array.
I'd like to point out this happens on mere array access, so using IsInstanceValid() is not a possibility. Ironically, it was while trying to use IsInstanceValid() that I found this error.

The error **crashes the game** after a seemingly random number of re-runs. As such if it happens in Process the game will freeze and crash either immediately or after a moment.

### Steps to reproduce

It can be tested with a very short and simple script. However, for your convenience I've uploaded an MRP. All you gotta do is to run it. The code in question is in the main folder. It's called "Proof.cs".

On some occasions, the project will crash before any error is output into the console. In that case try again. Sometimes it crashes before it can output anything and sometimes it prints hundreds of errors before crashing.

### Minimal reproduction project (MRP)

[MinimumReproduction.zip](https://github.com/godotengine/godot/files/15443782/MinimumReproduction.zip)
Repository: flutter
Issue: Change mouse wheel sensitivity at runtime on Windows
Labels: platform-windows,c: proposal,a: desktop,a: mouse,P3,team-framework,triaged-framework

### Use case

Flutter reads the Windows Mouse system configuration at startup, but can not be modified at run time. We should be able to configure different mouse wheel sensitivity for each flutter program, at runtime.

### Proposal

Add a function to modify the sensitivity  of the mouse wheel.
Repository: pytorch
Issue: [inline-inbuilt-nn-modules] tensordict functional calls with nn.Module silently gives the wrong (non-functional) result
Labels: triaged,bug,oncall: pt2,module: dynamo

### 🐛 Describe the bug

The following tests checks that swapping params (ie, making a functional call) works with torch.compile
https://github.com/pytorch/tensordict/blob/80965e0db2a574a9510c833cfceb7cdb0c00eed2/test/test_compile.py#L306-L314

For context, the test takes a copy of the parameters of the module and zeroes that copy, then makes a functional call. The results should all be 0.

The test on this line fails with the compiled version (but works in eager)
- compile, fails: https://github.com/pytorch/tensordict/blob/80965e0db2a574a9510c833cfceb7cdb0c00eed2/test/test_compile.py#L325
- eager, runs:
https://github.com/pytorch/tensordict/blob/80965e0db2a574a9510c833cfceb7cdb0c00eed2/test/test_compile.py#L318
suggesting that compile ignores the functional call.
This can be confirmed by uncommenting [this line](https://github.com/pytorch/tensordict/blob/80965e0db2a574a9510c833cfceb7cdb0c00eed2/test/test_compile.py#L324) which tests that the functional call is (wrongly) equal to the non-functional call. This passes, again confirming that compile ignores the functional call.

Setting `backend="eager"` in the call to compile does not solve the bug. 

There is some shady optimization of `nn.Module.__setattr__` happening in `TensorDict.to_module` but I don't believe this is the explanation since skipping these and falling back on a regulat `setattr(module, param_name, value)` gives the exact same result. 

@bdhirsh pointed me to `TORCHDYNAMO_INLINE_INBUILT_NN_MODULES` which solves the problem!

Happy to provide more context if needed

### Versions

nightly 

cc @ezyang @msaroufim @bdhirsh @anijain2305 @chauhang @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng
Repository: godot
Issue: _integrate_forces(state) is called even if custom_integrator option is off.
Labels: discussion,documentation,topic:physics

### Tested versions

4.2.2

### System information

Win 10

### Issue description

Function _integrate_forces(state) added to script well be called by the engine even if custom_integrator option is off.

### Steps to reproduce

add _integrate_forces(state) to RigidBody2D/3D
add a print function.

### Minimal reproduction project (MRP)

N/A
Repository: electron
Issue: [Feature Request]: Provide instruction and script about how to use a local electron source as npm installation.
Labels: enhancement :sparkles:

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

I'm developing electron and I added new types and made change to signatures. The feature I develop need a test project to debug, and I would like to use the latest generated electron.d.ts for types. But it seems no current method for packing a npm package locally to a folder.

### Proposed Solution

Provide a command to output a npm package folder ready for install locally with latest electron.d.ts

### Alternatives Considered

Nope.

### Additional Information

_No response_
Repository: vscode
Issue: Revert and Stage block buttons are very close together
Labels: diff-editor,under-discussion

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
**Type**: Minor Feature
Stage and revert block buttons in the Working Tree window are very close and can be misclicked.
Unlike the Discard Changes button in the Source Control window, the revert button does not have a confirmation window.

Not a duplicate of https://github.com/Microsoft/vscode/issues/43535
![image](https://github.com/microsoft/vscode/assets/33459428/1138acfa-0929-4dff-af8d-afd0edfa7592)
Repository: excalidraw
Issue: Excalidraw is great but without shortcuts for changing colors it is absolutely unbearable.
Labels: UX/UI,keyboard

Hey, I've been using excalidraw for a while now and the thing is it's such a neat and amazing plugin, I couldn't ever imagining not having it. But this post IS an issue so let's get into that. Excalidraw needs color stroke shortcuts for at least 5 of the layout shortcuts because having to navigate your mouse to the edit button, clicking, navigating to the color strokes, and clicking your desired color stroke doesn't sound that bad but it's very VERY inneficient if you have to change your color every so often. 

I request for there to be a minimum of 5 color shortcuts representing our color palette. This is a to-DIE for feature. This might not be that bad to those who draw using excalidraw but for people who make mind maps with it like me it's very frustrating having to keep doing that over and over again. It's unbearable. I would really appreciate a response on this.

The hot key for it would probably be something like alt+1 and so on or potentially something else. Excalidraw has some really good shortcuts but it's definitely very lackluster when it comes to colors and I think a lot of us feel that way.

Thanks for reading and I hope you implement this feature.
![image](https://github.com/excalidraw/excalidraw/assets/170816583/9c3f8e0f-2528-4100-aced-a4ee63f804b9)
Repository: PowerToys
Issue: Advanced paste doesn't work with simple example
Labels: Issue-Bug,Product-Advanced Paste

### Microsoft PowerToys version

0.81.0

### Installation method

WinGet

### Running as admin

None

### Area(s) with issue?

Advanced Paste

### Steps to reproduce

![image](https://github.com/microsoft/PowerToys/assets/22989529/05c5235f-c33d-4105-9af2-2f087d90f296)


### ✔️ Expected Behavior

_No response_

### ❌ Actual Behavior

_No response_

### Other Software

_No response_
Repository: excalidraw
Issue: Trying to install @next version but running into issues
Labels: support,package:excalidraw

It seems @next isn't really built the same way as main branch? It's almost impossible it seems to just have it be a dropin replacement