sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: VS Code unable to recognize any configured extension settings
Labels: info-needed

<!-- ⚠️⚠️ 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.94.2
Commit: 384ff7382de624fb94dbaf6da11977bba1ecd427
Date: 2024-10-09T16:08:44.566Z
Electron: 30.5.1
ElectronBuildId: 10262041
Chromium: 124.0.6367.243
Node.js: 20.16.0
V8: 12.4.254.20-electron.0
OS: Darwin arm64 23.6.0

OS 

NAME="Amazon Linux"
VERSION="2"
ID="amzn"
ID_LIKE="centos rhel fedora"
VERSION_ID="2"
PRETTY_NAME="Amazon Linux 2"
ANSI_COLOR="0;33"
CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2:-:internal"
HOME_URL="https://amazonlinux.com/"
VARIANT="internal"

None of my extensions are able to load any configuration values and config values in the settings.json are "greyed out" as if VS Code cannot recognize them. This issue has been occurring even after trying different VS Code version.s

Steps to Reproduce:

1. Not sure

![Image](https://github.com/user-attachments/assets/bc83573d-ee4e-47c3-a133-4ec1031b4a7e)
Repository: excalidraw
Issue: Japanese x Chinese unicode issue
Labels: enhancement,font

Japanese Kanji characters have a common origin with Chinese Hanzi, but they are not completely the same, as they have slightly different keystrokes. The problem is that they share unicode codepoints (likely unicode simplified too much here), which essentially means that a single font has to prefer one variation over the other. With #8530, most Kanji will be displayed as Hanzi (as Xiaolai is biased towards Chinese), which might be unreadable for some Japanese or even unusable in certain Japanese use cases/domains. See the following example:

![Image](https://github.com/user-attachments/assets/9da0517a-f8ba-4441-919f-7460967175cc)

Further discussion https://discord.com/channels/723672430744174682/1291770040764465244/1293553830251860030.

To solve this we likely have no other option than to introduce a separate Japanese fallback font with Kanji and "active it" (~push above Xiaolai in the fallback chain) once Japanese variation is preferred/detected. 

**Technical challenges**
- Japanese font should be fairly similar to Xiaolai
  - could we use Kanji from `Kose font`?
    ~ the font Japanese variant of Xiaolai, https://github.com/lxgw/kose-font
- How shall we decide when Japanese variation should be activated?
  - consider having a scene/workspace toggle (defaulting to `false`) to always prefer Japanese variation
  - consider autodetection (toggle on) based on client-side location/ app language? (not bullet-proof, but could work for most cases)
  - consider autodetecting Japanese based on Hiragana / Katakana in the workspace > scene > element (with element allowing combining Kanji/Hanzi codepoints in one scene, but likely being more complex and with a small character set for auto-detection)
- Introducing a new Japanese font should not cause a breaking change for existing Japanese diagrams
  - consider specifying fallback fonts on the element level
    - i.e. `fallbackFamilies: "SetoFont"` or `fallbackFamilies: "SetoFont, Segoe UI Emoji"`
- Both client-side and server-side exports shall receive the flag to include the Japanese fallback font
  - could be especially challenging for server-side PNG / PDF in E+, as we would have to have "two sets" of merged fonts (one with just Chinese, other with just Japanese; possibly per each family x weight variation) and decide in runtime which one to use
    - that would also lock us into one option per scene, due to the limitations of `Resvg` and `PdfKit` (unless we find a workaround, auto-detection on the element would be worthless)
Repository: godot
Issue: Theme / Theme Overrides Inspectors  Inconsistency
Labels: enhancement,topic:editor,usability

### Tested versions

v4.4.dev3.official [f4af8201b]


### System information

Windows 10 - v4.4.dev3.official [f4af8201b] - Vulcan

### Issue description

![1](https://github.com/user-attachments/assets/4c526b0c-5a18-4c4c-a1da-e02637e0c60d)

Theme Inspector UI has properties aligned in alphabetic order (please see image)
But Theme Overrides UI (Inpspector > Control  > Theme Overrides ) has properties aligned in custom order.
It would be much more convenient to sort the properties in both inspectors in the same order

### Steps to reproduce

file:///mnt/data_05tb/Art/Games/theme_overrides_inconsistency/theme_overrides_inconsistency.zip

### Minimal reproduction project (MRP)

Create theme
Create theme overrides
Repository: excalidraw
Issue: "Copy to clipboard as SVG" fails with `NotAllowedError` in Safari
Labels: bug,safari,export

"Copy to clipboard as SVG" fails with `NotAllowedError` in Safari.

**Steps to reproduce**
1. go to https://excalidraw.com/#json=hfnjGpV1NwRvEs_wfHTmK,wOiYn6lSALmGVH8SmJfXPw
2. trigger "Copy to clipboard as SVG" from the context menu

**Actual result**
![Image](https://github.com/user-attachments/assets/8c90b975-0af1-421b-82c6-715416eb1730)
```
NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied
```

**Expected result**
SVG is copied to the clipboard, as it is in Chromium-based browsers.
Repository: deno
Issue: `@sentry/profiling-node` support problem: `dyld missing symbol called`
Labels: bug,node native extension

Version: Deno 2.0.2

I'm trying to migrate a company codebase to Deno.

I suspect this is a result of https://github.com/getsentry/profiling-node/issues/123. I don't believe NAPI nan is supported in Deno yet.

# Reproduction

Check out this repo https://github.com/lino-levan/sentry-profiling-deno-bug
Repository: tauri
Issue: [bug] http reqwest
Labels: type: bug,status: needs triage

### Describe the bug

None of the solutions I've found work for my configuration. So I decided to use `https` in localhost. But I run into a problem when declaring my `mkcert` signed certificates.

```xml
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">localhost</domain>
        <trust-anchors>
            <certificates src="@raw/certs" />
        </trust-anchors>
    </domain-config>
</network-security-config>
```
I copied my `*.pem` certificates into `src-tauri/gen/android/app/src/main/res/raw/certs/`.
Here my error :
```bash
* What went wrong:
Execution failed for task ':app:processX86_64DebugResources'.
> A failure occurred while executing com.android.build.gradle.internal.res.LinkApplicationAndroidResourcesTask$TaskAction
   > Android resource linking failed
     ERROR: ~/code/project/src-tauri/gen/android/app/src/main/res/xml/network_security_config.xml:6: AAPT: error: resource raw/certs (aka com.project.app:raw/certs) not found.
```

EDIT : my question is « why @raw is not resolve ? » and what can I do ?

### Reproduction

- add `tauri_plugin_http` and all config in the `guide` tauri website
- add *f my case* `https://localhost:3000` to `capabilities` config
- generate self-signed certificates with `mkcert`
- follow the official doc https://developer.android.com/privacy-and-security/security-config?hl=fr#trust-anchors
- run `cargo tauri android dev`

### Expected behavior

The android app runs and can make an external reqwwest

### Full `tauri info` output

```text
[✔] Environment
    - OS: Ubuntu 24.4.0 x86_64 (X64)
    ✔ webkit2gtk-4.1: 2.44.0
    ✔ rsvg2: 2.58.0
    ✔ rustc: 1.81.0 (eeb90cda1 2024-09-04)
    ✔ cargo: 1.81.0 (2dbb1af80 2024-08-20)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (default)
    - node: 20.17.0
    - pnpm: 9.10.0
    - npm: 10.8.2

[-] Packages
    - tauri 🦀: 2.0.4
    - tauri-build 🦀: 2.0.1
    - wry 🦀: 0.46.1
    - tao 🦀: 0.30.3
    - tauri-cli 🦀: 2.0.2

[-] Plugins
    - tauri-plugin-http 🦀: 2.0.1
    - tauri-plugin-fs 🦀: 2.0.1
    - tauri-plugin-log 🦀: 2.0.1

[-] App
    - build-type: bundle
    - CSP: null
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
```


### Stack trace

_No response_

### Additional context

This is originally a web app built with `leptos`. So, there is a server and the desktop version can make a request without problem and without `tauri_plugin_http::init` using `invoke` fn. This did not work with `android` version, so I tried to use `https`.
Repository: rust
Issue: Macros do not accept empty `vis` at the end of the token tree
Labels: A-macros,T-lang,T-compiler,C-bug,WG-macros

<!--
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
macro_rules! m {
    ( ($v:vis) ) => {};
}

fn main() {
    m!( () );
}
```

I expected to see this happen: the code compile successfully. [The reference says](https://doc.rust-lang.org/stable/reference/macros-by-example.html#metavariables) `vis` is "a possibly empty [Visibility](https://doc.rust-lang.org/stable/reference/visibility-and-privacy.html) qualifier", so it should match empty.

Instead, this happened: the code is rejected with:
```
error: no rules expected the token `)`
 --> src/main.rs:6:10
  |
1 | macro_rules! m {
  | -------------- when calling this macro
...
6 |     m!( () );
  |          ^ no rules expected this token in macro call
  |
note: while trying to match meta-variable `$v:vis`
 --> src/main.rs:2:8
  |
2 |     ( ($v:vis) ) => {};
  |        ^^^^^^
```

[Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=19bf5dcbe88b8d0b7dc9b8404fc234f5).

@rustbot label +A-macros
Repository: PowerToys
Issue: Advanced paste new feature request
Labels: Needs-Triage

### Description of the new feature / enhancement

Clipboard launches automatically when you copy something. 

### Scenario when this would be used?

Sometime, when I do development, I used to find myself copying multiple thing and want to paste each of them in a different place, and I have to enter the command, click on the first one and paste it, and then, redo the command to launch the clipboard again, scroll to find the 6th one and paste it. I would be great if the clipboard remains open and I can paste each thing without having to enter the same command and to scroll to look for what I need.

### Supporting information

_No response_
Repository: tauri
Issue: [bug] A new Channel instance can only transmit once.
Labels: type: bug,status: needs triage

### Describe the bug

Under Linux Gnome,，A new Channel instance can only transmit once.The backend outputs 6 times, while the frontend only outputs 3 times
![截图 2024-10-20 10-22-36](https://github.com/user-attachments/assets/cca6aa23-3a14-483c-8306-5d1cf4c26664)


### Reproduction

_No response_

### Expected behavior

_No response_

### Full `tauri info` output

```text
$ pnpm run tauri info                                                   [10:28:13]

> wave@0.1.0 tauri /home/lei/wave
> tauri "info"


[✔] Environment
    - OS: Arch Linux Unknown x86_64 (X64)
    ✔ webkit2gtk-4.1: 2.46.1
    ✔ rsvg2: 2.59.1
    ✔ rustc: 1.81.0 (eeb90cda1 2024-09-04)
    ✔ cargo: 1.81.0 (2dbb1af80 2024-08-20)
    ✔ rustup: 1.27.1 (2024-05-07)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (default)
    - node: 22.9.0
    - pnpm: 9.12.1
    - bun: 1.1.30
    - deno: deno 1.46.3

[-] Packages
    - tauri 🦀: 2.0.4
    - tauri-build 🦀: 2.0.1
    - wry 🦀: 0.46.2
    - tao 🦀: 0.30.3
    - @tauri-apps/api : 2.0.2
    - @tauri-apps/cli : 2.0.3

[-] Plugins
    - tauri-plugin-shell 🦀: 2.0.1
    - @tauri-apps/plugin-shell : 2.0.0

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - framework: Vue.js
    - bundler: Vite
 
```
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: godot
Issue: `body shape entered` signal called *multiple times* in the same frame, with the same shape
Labels: bug,topic:physics

### Tested versions

- Reproducible in: v4.3.stable.mono.official [77dcf97d8]

### System information

Windows 10 - Vulkan (forward+) - dedicated

### Issue description

Sometimes the **body_shape_entered** signal is called **multiple times** in the same frame with the same shape.
When contact monitor enabled and max contact >= 2
Does not always happen.... but it is fairly consistent. 
**I got a MRP setup that can reproduce this consistently in my machine** 

Here's a print of the collision log:
![log1](https://github.com/user-attachments/assets/f85cb988-a68d-44df-825e-43ea00f55c63)

This caught me by surprise. 

In my use-case, all was working great with _body_entered_.... and then it all broke when I changed it to _body_shape_entered_.
I was doing some stuff when the collision happened where I extracted its shape and queue_freed the body.
So the second collision call broke the game due to the collision shape not being there anymore.

So this problem doesn't seem to happen with **body_entered**... only with **body_shape_entered**... 
And yes, it is the same shape_index/local_shape_index. 
And objects were single shapes too.

### Steps to reproduce

- Create a player rigidbody with contact monitor enabled and at least 2 contacts
- Connect body_shape_entered to player
Result: Collisions will occasionally happen multiple times a frame

MRP example:
- Run the MRP. Check prints for multiple collisions on the same object in the same frame.
- Uncomment line 18 and 19 to see it crash instead of only printing logs when it happened

### Minimal reproduction project (MRP)

[MRP_min-shape-twice.zip](https://github.com/user-attachments/files/17448145/MRP_min-shape-twice.zip)
Repository: godot
Issue: Trying to select objects in TopOrthogonal view gives error message in some situations
Labels: bug,topic:editor,topic:3d

### Tested versions

- Reproducible in: v4.3.stable.mono.official [77dcf97d8]

### System information

Windows 10 - Vulkan (forward+) - dedicated

### Issue description

Trying to select objects with the mouse in the editor in the TopOrthogonal view can cause an error message to appear in the console in some situations.
This does not cause any problems. The selection still works.... 
But it spits this error with each mouse click:
"The target vector and up vector can't be parallel to each other."

![topview](https://github.com/user-attachments/assets/6b8a9f68-f498-436c-aef1-fc4097236ae4)


Here's a video:

https://github.com/user-attachments/assets/5f27c1bd-17c0-49a9-9bfc-4212c17b35e3



I can consistently reproduce this by adding the sun to the scene.

This is produced by the gizmo calling its intersect_ray to check for selection. 
And calling set_look_at with its up direction perpendicular to the position due to the orthogonal view.
Not really sure what this does. I'm guessing it is used to rotate the gizmo's icon so it can check for mouse selection.
https://github.com/godotengine/godot/blob/44fa552343722bb048e2d7c6d3661174a95a8a3c/editor/plugins/node_3d_editor_gizmos.cpp#L655-L659


### Steps to reproduce

- Create a new 3D scene
- Add the the Sun to the scene
- Go to TopOrthogonal view
- Click anywhere (maybe near the origin)

### Minimal reproduction project (MRP)

[MRP_min-shape-twice.zip](https://github.com/user-attachments/files/17448306/MRP_min-shape-twice.zip)
Repository: rust
Issue: `std::sync::OnceLock` is `Eq` but not `Hash`
Labels: T-libs-api,C-bug,T-libs

The standard library type `std::sync::OnceLock` is `Eq` but not `Hash`.  From a theoretical and practical perspective, it should probably be both or neither.

The argument for neither is that the result of `Eq` can change because of a different thread as soon as it is returned.  Similarly, the value of `Hash` can change between comparison of the `Hash` and a follow up comparison with `Eq`.  Both of these are expected short-comings of types that can be changed by other threads.

The argument for both is that `Hash` is fundamentally a property related to equality and not rules out usages in containers where there are some external invariants that guarantee the desired behavior.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: rust
Issue: Regression: geoarrow crate does not compile in release mode on 1.82
Labels: P-high,T-compiler,regression-from-stable-to-stable,C-bug,A-mir-opt-inlining,T-types,WG-mir-opt

This issue is originally reported by @kylebarron at https://github.com/rust-lang/rust/issues/128887#issuecomment-2423159520

The `geoarrow` crate does not compile in release mode on rust 1.82.0, despite compiling fine in debug mode or in rust 1.81.0.

The code can be obtained by:
```sh
git clone https://github.com/geoarrow/geoarrow-rs
cd geoarrow-rs
git checkout 0b6715c6a56f0115f9078803fae945700713b22f
```

The following commands give compilation errors:
```sh
rustup run 1.82 cargo build --release
rustup run nightly cargo build --release
```

The following commands compile fine without errors:
```sh
rustup run 1.81 cargo build --release
rustup run 1.81 cargo build
rustup run 1.82 cargo build
rustup run nightly cargo build
RUSTFLAGS='-Zinline-mir=no' rustup run nightly cargo build --release
```

Note that this is issue is distinct from the previous 1.80-to-nightly geoarrow regression, which is fixed in #129714 and tested in #129757.

@rustbot labels regression-from-stable-to-stable
Repository: ui
Issue: [bug]: CLI `add` command breaks on comments in `tailwind.config.ts` 
Labels: bug

### Describe the bug

![image](https://github.com/user-attachments/assets/c440fe34-1cba-4458-bec9-843761ff4097)

```
      fontFamily: {
        sans: [
          // "var(--font-sans)",
          "var(--font-geist-sans)",
          ...fontFamily.sans,
        ],
        serif: ["var(--font-serif)", ...fontFamily.serif],
      },
```

Became

```
  		fontFamily: {
  			sans: [\\n          // "var(--font-sans)",\\n          "var(--font-geist-sans)",\\n          ...fontFamily.sans,\\n        ],\n  			serif: ["var(--font-serif)", ...fontFamily.serif]
  		},
```

### Affected component/components

CLI

### How to reproduce

Install something with a comment at the top of the fontfamily in tailwind config:

```
npx shadcn@latest add sidebar-01 sidebar-02 sidebar-03 sidebar-04 sidebar-05 sidebar-06 sidebar-07 sidebar-08 sidebar-09 sidebar-10 sidebar-11 sidebar-12 sidebar-13 sidebar-14 sidebar-15
```

https://github.com/lacymorrow/juicy-stack/pull/2/files#diff-655dc9e3d0aa561e3fa164bf48bd89cb0f5da65e0a567f8ebbf9dd791a0e7f40

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
Latest CLI
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: svelte
Issue: Duplicate text on upcoming svelte omni site.
Labels: documentation

### Describe the bug

This text is duplicated on https://svelte-omnisite.vercel.app/docs/svelte/lifecycle-hooks
>
![image](https://github.com/user-attachments/assets/7d2df3c0-88f8-4ab8-8249-c07c28210b62)


### Reproduction

Go to https://svelte-omnisite.vercel.app/docs/svelte/lifecycle-hooks#onDestroy and read the docs.

### Logs

_No response_

### System Info

```shell
Not relevant
```


### Severity

annoyance
Repository: neovim
Issue: `:Man bash(1)` loads incorrect/old version of bash man page.
Labels: bug,plugin,runtime,complexity:low

### Problem

On my machine MacOS machine, 

### Using the command defaults

1. running `man bash` in the terminal, BOTH outside neovim and inside neovim's builtin terminal, loads man pages for bash v5.2.
The man page can be found at `man /usr/local/share/man/man1/bash.1`.

BUT (This is the bug)

2. Running `:Man bash(1)` command in neovim loads the manpage for the older bash version v3.2, which comes builtin on MacOS machines and can be found at `man /usr/share/man/man1/bash.1` (*).


---

### Manually loading the bash man page with `:Man /path/to/man/page`:

If I try to load v3.2 manually `:Man /usr/share/man/man1/bash.1`, then it sais "No manual entry found for ..." but I know it exists because it can be loaded manually in the terminal with (*).

AND trying to load v5.2 path manually literally loads v3.2, so it seems that it is impossible to even load version 5.2 with `:Man`.

---

This behavior manifests in both my full config and also with `nvim --clean`. I asked on matrix and we agreed that since this shows under both the configured and clean it makes sense to post as a bug. I looked at the lua code for `:Man` and conclude that this could maybe be my first patch for neovim but I want to first make sure that this really is a bug and not a feature.

### Steps to reproduce

Just install neovim on macos it seems.

### Expected behavior

I am expecting man page for bash 5.2 to be loaded with `:Man bash` but I am not sure. 

### Nvim version (nvim -v)

NVIM v0.11.0-dev-608+g9d74dc3ac AND nvim 0.10

### Vim (not Nvim) behaves the same?

`:Man` is not an editor command in vim

### Operating system/version

Macos 15.0

### Terminal name/version

alacritty 0.13.2 (bb8ea18)

### $TERM environment variable

xterm-256color

### Installation

bob-nvim for latest, and brew for nvim 0.10