sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: feature request: vscode://file scheme url add support for tilde based links
Labels: feature-request,workbench-os-integration

<!-- ⚠️⚠️ 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. -->

Maybe I'm missing something.. but I wish to be able to open file in vscode with a tilde in the path.

That way a server or a greasemonkey JS scriplet can add a  generic file opener button

currently this works

```
vscode://file/Users/t/foo.txt
```

but not

```
vscode://file/~/foo.txt
```

It says path `/~/foo.txt` doesn't exist.

Neither 

```
vscode://file~/foo.txt
```
Nothing happens with this whether the file exists or not.

The support was added long back..
https://github.com/microsoft/vscode/pull/39122

https://github.com/microsoft/vscode-docs/issues/5215
Repository: godot
Issue: Black Background when trying to use pixel perfect transparency
Labels: bug,topic:rendering,needs testing

### Tested versions

I am using, and encountered the recurring issue on the official Godot 4.3.stable build, on compatibility mode.



### System information

Godot v4.3.stable - Windows Version 10.0.22631 Build 22631 - NVIDIA GeForce RTX 3070 Laptop GPU

### Issue description

My native resolution is 1920x1080, and when I set this as the window resolution in project settings, my transparent background turns black. Attempting to screenshot with PrtSc reverts it back to a transparent state, but returns to black afterwards, so I can't attach any screenshots. Changing the resolution to 1920x1079 fixes the issue, but I'm not sure how sustainable it'll be in the long run when adapting to other resolutions since the one pixel gap might become more noticeable.

The project setting window mode is set to Windowed, with Borderless enabled, since fullscreen seems to make the transparent background black. 

### Steps to reproduce

In Project Settings > Display > Window > Size, set the Viewport Width and height to 1920 and 1080 respectively, then turn on Borderless, and set the Mode to Windowed. In the same area, enable Transparent, as well as check "Allowed" under Per Pixel Transparency. Then enable Transparent Background in Rendering > Viewport. 

Running the main scene shows a black background in place of the intended transparent background.

Reducing the resolution to 1280x720, or comically 1920x1079, restores the intended transparent background. 

I assume the fact that my native resolution is 1920x1080 plays an important role in finding the solution.

I'm relatively new to Godot, and using game engines in general, but I hope I provided enough information.

### Minimal reproduction project (MRP)

[planner-project2.zip](https://github.com/user-attachments/files/17969954/planner-project2.zip)
Repository: rust
Issue: "rustc-LLVM ERROR" when using `_mm_cvttps_epi32` on x86_64-unknown-none
Labels: O-x86_64,T-compiler,C-bug,A-target-feature

<!--
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:

```rust
#![no_std]

use core::arch::x86_64::*;

pub unsafe fn func() -> __m128i {
    _mm_cvttps_epi32(_mm_setzero_ps())
}
```

It builds fine on x86_64-unknown-linux-gnu, but fails on x86_64-unknown-none:

```
rustc-LLVM ERROR: Do not know how to split the result of this operator!
```

Adding `#[target_feature(enable = "sse2")]` or using `-C target-feature=+sse2` does not prevent the error.

### 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.85.0-nightly (7442931d4 2024-11-30)
binary: rustc
commit-hash: 7442931d49b199ad0a1cc0f8ca54e327b5139b66
commit-date: 2024-11-30
host: x86_64-unknown-linux-gnu
release: 1.85.0-nightly
LLVM version: 19.1.4
```
Repository: rust
Issue: non-`#[macro_export]`'ed `macro_rules!` macros are impossible to disambiguate from built-in attributes in `use` declarations
Labels: A-attributes,A-macros,T-lang,C-bug

I tried this code:

```rust
macro_rules! warn { () => {} }
pub(crate) use warn;
fn main() { }
```

I expected it to compile.

Instead, it produces an error like this:

```qualify
error[E0659]: `warn` is ambiguous
 --> src/main.rs:3:16
  |
3 | pub(crate) use warn;
  |                ^^^^ ambiguous name
  |
  = note: ambiguous because of a name conflict with a builtin attribute
  = note: `warn` could refer to a built-in attribute
note: `warn` could also refer to the macro defined here
 --> src/main.rs:1:1
  |
1 | macro_rules! warn { () => {} }
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```

`macro_rules` are impossible to qualify it as `self::warn` or `crate::warn` or `super::warn`.
 `use r#warn` doesn't do anything useful too. 

The only thing you can do is something stupid like this:

```rust
macro_rules! warn_hack { ($($tt:tt)*) => { warn!($($tt)*) } }
pub(crate) use warn_hack as warn;
```

This will work, the fact that it works like that is why I consider this a bug.

### Meta

Occurs on all versions with `--edition 2018` or later.
Repository: excalidraw
Issue: Copy and paste items do not snap to grid properly
Labels: bug

Whenever I duplicate something using the alt key specifically it is pasted off-grid, forcing me to move it manually back onto it.
https://github.com/user-attachments/assets/f9de378c-c520-44d8-9971-50873fe44109
The video displays the behaviour in Obsidian-excalidraw, but the same thing happens on the site.
This behaviour is quite inconsistant, never really happening if no hand drawn vectors are selected, and sometimes when there are.

In obsidian I'm running version 2.6.7, not sure how to check version information on the site
Repository: rust
Issue: keyword-idents is incompatible with macros
Labels: A-lints,A-macros,T-compiler,C-bug,A-suggestion-diagnostics,D-invalid-suggestion,D-edition,A-edition-2024,L-keyword_idents_2024,L-keyword_idents,I-edition-triaged

The `keyword_idents` lint has incorrect suggestions in macro_rules macros (there are potentially separate concerns for the definition versus invocation). It suggests changing a new keyword to the raw identifier, but this is a semantic change (see #49520).

## LHS Definition

Consider:

```rust
// edition 2021
#![warn(keyword_idents)]
#[macro_export]
macro_rules! m {
    (gen) => {};
}
```

This suggests changing it to a raw identifier:

```diff
@@ -1,5 +1,5 @@
 #![warn(keyword_idents)]
 #[macro_export]
 macro_rules! m {
-    (gen) => {};
+    (r#gen) => {};
 }
```

However, this is a semantic change because macro_rules does not treat an equivalence between raw and normal identifiers (or keywords). Thus, another crate using this macro:

```rust
// any edition
m!(gen);
```

will fail with the error "no rules expected `gen`", or "no rules expected reserved keyword `gen`" in 2024.

## Invocation

Perhaps more difficult to resolve is the rewrites for an invocation.

Let's say we have a crate (any edition), with something like:

```rust
// crate a, any edition
#[macro_export]
macro_rules! other_macro {
    (gen) => {};
}
```

and then I am trying to migrate my crate to 2024:

```rust
// edition 2021
#![warn(keyword_idents)]
a::other_macro!(gen);
```

This will suggest to change it to `a::other_macro!(r#gen)`, which is incorrect because that does not match any matchers.

I say this is more difficult, because there are some situations where changing the invocation is the correct thing to do. Consider:

```rust
// crate a, any edition
#[macro_export]
macro_rules! other_macro {
    ($e:stmt) => {};
}
```

and trying to migrate another crate to 2024:

```rust
// edition 2021
#![warn(keyword_idents)]
a::other_macro!(let gen = 1);
```

this gives the **correct** suggestion to rewrite it to `a::other_macro!(let r#gen = 1);`, which would fail to compile if it wasn't changed.


## Possible solutions

There are different angles to tackle this problem:

- Changing the suggestions provided by keyword_idents.
- Changing the behavior of macros.

The latter seems like a bigger can of worms.

For the former, some rough thoughts:
- Don't suggest changes on the LHS of a macro_rules matcher. This is clearly a semantics change.
- Detect the situations where changing an invocation is incorrect, and avoid those suggestions. No idea how feasible that is.

## Meta

```
rustc 1.85.0-nightly (7442931d4 2024-11-30)
binary: rustc
commit-hash: 7442931d49b199ad0a1cc0f8ca54e327b5139b66
commit-date: 2024-11-30
host: aarch64-apple-darwin
release: 1.85.0-nightly
LLVM version: 19.1.4
```
Repository: PowerToys
Issue: Image Resizer edit setting Percent issue
Labels: Issue-Bug,Product-Image Resizer,Needs-Triage,Status-Reproducible

### Microsoft PowerToys version

0.86.0

### Installation method

GitHub

### Running as admin

Yes

### Area(s) with issue?

Image Resizer

### Steps to reproduce

Editing preset or add new size, in this setting the "PERCENT" unit stays on width parameter, before it change to precent option and image reduced the desire percent in width and height based on percent, not a fixed width.

![Image](https://github.com/user-attachments/assets/6c48c428-7083-4945-8757-122880ebe6a9)


### ✔️ Expected Behavior

Input desire percent value instead of a fixed width like before.

### ❌ Actual Behavior

Images resize to a fixed width instead of percent based option.

### Other Software

_No response_
Repository: flutter
Issue: Add `ListenableBuilder.all` to make it easier to listen to multiple listenables
Labels: framework,c: proposal,P2,team-framework,triaged-framework

### Use case

Here's how you can listen to multiple `Listenable`s today.

#### Option 1 - multiple `ListenableBuilder`s

```dart
@override
Widget build(BuildContext context) {
  return ListenableBuilder(
    listenable: model1,
    builder: (context, _) {
      return ListenableBuilder(
        listenable: model2,
        builder: (context, _) {
          return Text('Values: $model1, $model2');
        },
      );
    },
  );
}
```

This option is easy to discover but verbose.

#### Option 2 - `Listenable.merge`

```dart
@override
Widget build(BuildContext context) {
  return ListenableBuilder(
    listenable: Listenable.merge([model1, model2]),
    builder: (context, _) {
      return Text('Values: $model1, $model2');
    },
  );
}
```

This option is significantly less verbose. However, this option is hard to discover.

### Proposal

1. **Introduce `ListenableBuilder.all`**, which invokes its `builder` when one or more `Listenable`s change.

   Example:

   ```dart
   @override
   Widget build(BuildContext context) {
     return ListenableBuilder.all(
       listenables: [model1, model2],
       builder: (context, _) {
         return Text('Values: $model1, $model2');
       },
     );
   }
   ```

   This is similar to the `Listenable.merge` option, however, it is easier to discover from the `ListenableBuilder` type.

   If we do this change, we should also update `AnimatedBuilder`.

1. Update `ListenableBuilder`s docs to show how to listen to multiple `Listenable`s.
Repository: go
Issue: cmd/go,x/telemetry/config: collect vcs systems used
Labels: NeedsInvestigation,Telemetry-Proposal

### Summary

I propose we collect a count of whether each vcs system (git, hg, svn, fossil, bzr) was used recently.
I question the continued value of supporting the less used systems (e.g. bazaar, cmd/go special cases launchpad.net, but I believe it has switched primarily to git now).

### Proposed Config Change

-
Repository: rust
Issue: Poor diagnostic when using = instead of : in let bindings
Labels: A-diagnostics,A-parser,T-compiler,D-confusing,D-incorrect

### Code

1.

```rs
let last = u64 = 0;
```

2.

```rs
let val = u64;
```

### Current output

1.

```shell
error[E0423]: expected value, found builtin type `u64`
  --> src/main.rs:21:24
   |
21 |         let last = u64 = 0;
   |                        ^^^
   |
help: you might have meant to introduce a new binding
   |
21 |         let last = let u64 = 0;
   |                        +++
```

2. 

```shell
error[E0423]: expected value, found builtin type `u64`
  --> src/main.rs:21:20
   |
21 |         let last = u64;
   |                    ^^^ not a value
```

### Desired output

1.

```shell
error[E0423]: expected value, found builtin type `u64`
  --> src/main.rs:21:24
   |
21 |         let last = u64 = 0;
   |                        ^^^
   |
help: you might have meant to use `:` instead of `=`
   |
21 |         let last:  u64 = 0;
   |                 +
note: type annotations use `:` instead of `=` (https://doc.rust-lang.org/reference/statements.html#expression-statements)
```

2. 

```shell
error[E0423]: expected value, found builtin type `u64`
  --> src/main.rs:21:20
   |
21 |         let last = u64;
   |                    ^^^ not a value
help: you might have meant to use `:` instead of `=`
note: type annotations use `:` instead of `=` (https://doc.rust-lang.org/reference/statements.html#expression-statements)
```

### Rationale and extra context

This is a silly mistake to make and also simple to detect and autofix.

### Other cases

```Rust

```

### Rust Version

```Shell
1.85.0-nightly (4c39aaff6 2024-11-25)
```

### Anything else?

@rustbot label +D-incorrect +D-confusing +A-parser
Repository: rust
Issue: `std::marker::Freeze` disallows blanket impl since it "could be implemented on `Cell` and `UnsafeCell` in the future"
Labels: T-compiler,C-bug,F-freeze

<!--
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:

```rust
#![feature(freeze)]
use std::{cell::Cell, marker::Freeze};

unsafe trait IntoFreeze {
  type Frozen: Freeze;
}

unsafe impl<T: Freeze> IntoFreeze for T {
  type Frozen = T;
}

unsafe impl<T: IntoFreeze> IntoFreeze for Cell<T> {
  type Frozen = T::Frozen;
}
```

I expected to see this happen: Code should compile since Freeze will never be implemented for `Cell` and `UnsafeCell`.

Instead, this happened:

```
error[E0119]: conflicting implementations of trait `IntoFreeze` for type `Cell<_>`
  --> src/lib.rs:12:1
   |
8  | unsafe impl<T: Freeze> IntoFreeze for T {
   | --------------------------------------- first implementation here
...
12 | unsafe impl<T: IntoFreeze> IntoFreeze for Cell<T> {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `Cell<_>`
   |
   = note: upstream crates may add a new impl of trait `std::marker::Freeze` for type `std::cell::Cell<_>` in future versions

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

### 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`:
```
1.85.0-nightly (2024-11-30 7442931d49b199ad0a1c)
```
Repository: godot
Issue: TileMapLayer's grid and placed tiles are positioned incorrectly inside CanvasLayer with "Follow Viewport" enabled
Labels: bug,topic:editor,topic:2d

### Tested versions

- Reproducible in: v4.3.stable.official [77dcf97d8], v4.2.1.stable.mono.official [b09f793f5]
- Not reproducible in: v3.6.stable.official [de2f0f147]

### System information

Windows 11 - Godot 4.3 Compatibility

### Issue description

I have the following scene:

![Image](https://github.com/user-attachments/assets/740698c3-c9b1-48e9-b0fa-c378cc09595b)

There is a TileMap node and a CanvasLayer parent node. Everything is set to default values except for the CanvasLayer's "Follow Viewport," which is enabled, and "Scale," which is set to 2 (can be any value above 1).

Here are the values in the inspector:
![Image](https://github.com/user-attachments/assets/69bddc7b-45a3-4adc-98f6-eb418acc2d13)

Now, if we select a tile and hover over the scene, we can see a preview of where it will be placed. However, when we click, the tile is placed in a different position. The grid has the same issue.

![Image](https://github.com/user-attachments/assets/8ff1200e-32b7-4988-9f53-32f245e46121)

Enabling the **View -> Preview Canvas Scale** option does not resolve the issue. The preview and the grid remain misaligned with the placed tile.

![Image](https://github.com/user-attachments/assets/9af03494-42ba-4a1c-b2c8-74392a6b11f9)

### Conclusion

This issue makes it impossible to work on larger scenes because the farther the distance from the center of the scene, the worse the problem becomes. At some point, the placed tile is completely off-screen. The only solution at the moment is to disable the "Follow Viewport" option, draw the tiles, and then enable it again.

![Image](https://github.com/user-attachments/assets/44a6ab6f-5267-4abe-a995-95374d70b5f0)

### Testing Godot 3

Here is how it looks in Godot **3.6** (v3.6.stable.official [de2f0f147]). The grid is positioned correctly, and the preview matches the actual position of the placed tile.

![Image](https://github.com/user-attachments/assets/485aa133-b6ae-4838-94fe-87d2f822ea42)

If I enable the **Preview Canvas Scale** option, the alignment starts to be misaligned. However it doesn't break when we are far away from scene zero coordinates.

![Image](https://github.com/user-attachments/assets/2d6c834b-396d-472b-ab8d-627b8ba0cdad)



### Side notes

- It's also broken with the old (and deprecated) TileMap node


### Steps to reproduce

1. Open "main_scene.tscn"
2. Select "Broken_TileMapLayer"
3. Select any tile on the Tile Map panel
4. Hower over the scene to see the preview and try to place the tile
5. You can also select the "Working_TileMapLayer" to see how it works without CanvasLayer as a parent

It might not be visible if camera is positioned perfectly at zero coordinates, so you should move it.

You can also enable grid to see that it's also misaligned:
![Image](https://github.com/user-attachments/assets/de7968b3-52fa-40db-904e-9616a1cc1ca8)

### Minimal reproduction project (MRP)

[canvaslayer-and-tilemap-issue.zip](https://github.com/user-attachments/files/17970402/canvaslayer-and-tilemap-issue.zip)
Repository: vscode
Issue: [Feature request] [Testing] Add again the "expand/collapse" feature in Test Explorer UI
Labels: feature-request,testing

<!-- ⚠️⚠️ 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. -->

The old Test Explorer UI had a "expand tree" in the test list, as well as a "collapse tree" feature

![Image](https://github.com/user-attachments/assets/53c59502-95fd-477a-ab66-e84fd0767e79)

The new Test Explorer UI have only a "collapse" feature, and it is hidden on a context menu

![Image](https://github.com/user-attachments/assets/c5a6188a-85e3-4916-ba20-1532a7f0fe08)

Please, come back with the "expand/collapse" feature, like some other views
Repository: opencv
Issue: python binding: displayOverlay doesn't disappear from the display unless a mouse move event happens over the image
Labels: bug

### System Information

opencv: 4.10.0
os: debian 12
python 3.12.7


### Detailed description

Expected behaviour: 
an overlay should be displayed atop an image and then disappear after delayms has timed out but doesn't.

Also, displayStatusBar doesn't appear to set any text on the window.

Actual:
the overlay appears but doesn't disappear unless a mouse move event happens on the image

Workaround / fix

I have to send a flag to `namedWindow`, either `cv2.WINDOW_GUI_EXPANDED` or `cv2.WINDOW_NORMAL` and call displayStatus bar and set the same timeout value, to get the overlay to disappear without the mouse move event needed. 

Presumably this method must be calling something that displayOverlay doesn't. 

If I use different timeout values in the two method calls, the overlay doesn't disappear.


### Steps to reproduce

For example, this code should display an image, display an overlay for 1.5s and then disappear.
```python
import cv2

im = cv2.imread('foo.png')
cv2.namedWindow('asdf', cv2.WINDOW_GUI_EXPANDED)
cv2.imshow('asdf', im)
cv2.displayOverlay('asdf', 'look at this overlay!', 1500)

cv2.waitKey(0)
```

The overlay appears but doesn't vanish unless I move the mouse cursor across the image.

The overlay disappears with the addition of the displayStatusBar call:

```python
import cv2

im = cv2.imread('foo.png')
cv2.namedWindow('asdf', cv2.WINDOW_GUI_EXPANDED)
cv2.imshow('asdf', im)
cv2.displayOverlay('asdf', 'look at this overlay!', 1500) # the timeout values must be the same between the two calls
cv2.displayStatusBar('asdf', 'asdf', 1500) # doesn't appear to set any text in status bar neither

cv2.waitKey(0)
```


### Issue submission checklist

- [X] I report the issue, it's not a question
- [X] I checked the problem with documentation, FAQ, open issues, forum.opencv.org, Stack Overflow, etc and have not found any solution
- [X] I updated to the latest OpenCV version and the issue is still there
- [X] There is reproducer code and related data files (videos, images, onnx, etc)
Repository: rust
Issue: Confusing diagnostics with nested precise capturing RPIT
Labels: A-diagnostics,T-compiler,requires-nightly,D-confusing,F-impl_trait_in_fn_trait_return

### Code

```Rust
#![feature(impl_trait_in_fn_trait_return)]

trait Foo {}
impl Foo for &() {}

fn foo<'a>(u: &'a ()) -> impl FnOnce() -> (impl Foo + use<'a>) + use<'a> {
    move || u
}
```

### Current output

```shell
error[E0700]: hidden type for `impl Foo` captures lifetime that does not appear in bounds
 --> src/main.rs:7:13
  |
6 | fn foo<'a>(u: &'a ()) -> impl FnOnce() -> (impl Foo + use<'a>) + use<'a> {
  |                                            ------------------ opaque type defined here
7 |     move || u
  |             ^
  |
  = note: hidden type `&()` captures lifetime `'_`

error[E0720]: cannot resolve opaque type
 --> src/main.rs:6:44
  |
6 | fn foo<'a>(u: &'a ()) -> impl FnOnce() -> (impl Foo + use<'a>) + use<'a> {
  |                                            ^^^^^^^^^^^^^^^^^^ recursive opaque type
7 |     move || u
  |     --------- returning here with type `{closure@src/main.rs:7:5: 7:12}`
```

### Desired output

```

```

### Rationale and extra context

I assume using precise capturing in this position isn't meant to be supported.

Both of these diagnostics seem inaccurate.

The first is talking about some elided lifetime, when the only relevant lifetime is named.

The second is claiming that the return type is recursive when it _obviously_ isn't. This disappears when getting rid of the inner `use<'a>` so is somehow triggered by using that in this location.

Equivalent-ish code avoiding the closure traits compiles successfully on stable:

```rust
trait Foo {}
trait Bar { type Foo: Foo; }
impl Foo for &() {}
impl Bar for &() { type Foo = Self; }

fn foo<'a>(u: &'a ()) -> impl Bar<Foo = impl Foo + use<'a>> + use<'a> {
    u
}
```

### Other cases

```Rust

```

### Rust Version

```Shell
1.85.0-nightly

(2024-11-30 7442931d49b199ad0a1c)
```

### Anything else?

_No response_