sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Bad suggestion for macro_rules macros generated from a proc-macro
Labels: A-lints,A-diagnostics,T-compiler,C-bug,A-suggestion-diagnostics,D-invalid-suggestion,D-edition,A-edition-2024,L-unsafe_op_in_unsafe_fn,I-edition-triaged

In a proc-macro that generates a macro_rules macro that triggers lints like `unsafe_op_in_unsafe_fn`, or `unsafe_attr_outside_unsafe`, the suggestion ends up suggesting that the `unsafe` should go around the attribute, which is invalid syntax.


```rust
// proc-macro `pm`
use proc_macro::TokenStream;

#[proc_macro_attribute]
pub fn pm(_attr: TokenStream, _item: TokenStream) -> TokenStream {
    "macro_rules! foo {
        () => {pub unsafe fn foo() { let _ = std::mem::zeroed::<i32>(); } };
    }"
    .parse()
    .unwrap()
}
```

```rust
#![warn(unsafe_op_in_unsafe_fn)]

#[pm::pm]
struct S;

foo! {}
```

Gives a suggestion that ends up being:

```rust
{ unsafe #[pm::pm]}
```

which is invalid syntax.

Seen with the [`vtable`](https://crates.io/crates/vtable) crate.

This is a bit of curious case, as I would have expected the tokens of the macro_rules definition to be 2021 edition, and that the tokens it in turns generates also be 2021. Offhand I don't know how macro_rules determine which edition the tokens it emits should be (I'm guessing it is using the edition of the local crate, instead of the edition of the generated macro_rules definition).

### Meta

`rustc --version --verbose`:
```
rustc 1.84.0-nightly (143ce0920 2024-11-10)
binary: rustc
commit-hash: 143ce0920a2307b19831160a01f06f107610f1b2
commit-date: 2024-11-10
host: aarch64-unknown-linux-gnu
release: 1.84.0-nightly
LLVM version: 19.1.3
```
Repository: electron
Issue: Native Wayland is completely BROKEN in Electron
Labels: platform/linux,bug :beetle:,wayland,32-x-y

### 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 bug report that matches the one I want to file, without success.

### Electron Version

32.2.1

### What operating system(s) are you using?

Ubuntu

### Operating System Version

Ubuntu 24.04.1

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

The flags ``--enable-features=UseOzonePlatform --ozone-platform=wayland`` or ``--ozone-platform-hint=wayland --enable-features=WaylandWindowDecorations`` should open the Electron application in a native wayland window without any issues.

### Actual Behavior

The application does not open **at all**, it will only open in XWayland only. Forcing Native Wayland with any flags such as ``--enable-features=UseOzonePlatform --ozone-platform=wayland`` or ``--ozone-platform-hint=wayland --enable-features=WaylandWindowDecorations`` will prevent the application from opening.

### Testcase Gist URL

_No response_

### Additional Information

Native Wayland is simply not supported in Electron, this has been tested on GNOME Shell 46, if the results are different on other wayland compositor shells or operating systems, please list them below. To test it out, please use the ``--enable-features=UseOzonePlatform --ozone-platform=wayland`` or ``--ozone-platform-hint=wayland --enable-features=WaylandWindowDecorations`` flags.

This is also why other Electron applications such as VS Code have these issues:
https://github.com/microsoft/vscode/issues/207033
https://github.com/microsoft/vscode/issues/231955
Repository: kubernetes
Issue: not increment pInfo.Attempts when the scheduling fails with Error status
Labels: sig/scheduling,kind/feature,needs-triage

The current `pInfo.Attempts` is simple; when the scheduler `Pop()` the pod, it increments `pInfo.Attempts`.
And, also this `pInfo.Attempts` is used to calculate the backoff time.

There are basically two failures that the scheduling cycle could make; Unschedulable or Error.
- Unschedulable: the Pod is unschedulable; e.g., no node has enough resource, nodeaffinity, etc.
- Error: the Pod cannot be scheduled because of unexpected errors;  e.g., kube-apiserver is unstable, network issue, etc.

Given [the backoff is a penalty of wasting the scheduling cycle](https://github.com/kubernetes/kubernetes/blob/8fe10dc378b7cc3b077b83aef86622e1019302d5/pkg/scheduler/framework/interface.go#L205-L207), we shouldn't increment `Attempts` when the Pod comes back to queue with Error status
so that the backoff time doesn't get longer by those errors.

As the actual example, what could happen now is:
1. The scheduler fails to schedule all the pods because the cluster is under the networking issue.
2. `pInfo.Attempts` in all the Pods gets bigger and bigger meanwhile. 
3. The network issue is resolved and some Pods go scheduled.
4. But, then if some Pods fail, they have a large `pInfo.Attempts`, and hence gets super long backoff time, which is unfair because the most of their `Attempts` are failed not by the scheduling reason, but by the network issue.

/kind feature
/assign
/sig scheduling
Repository: terminal
Issue: Ctrl+clicking URLs partially out of viewport not working as expected
Labels: Area-Interaction,Issue-Bug,Product-Terminal

### Windows Terminal version

1.22.2912.0

### Windows build number

10.0.22635.4445

### Other Software

_No response_

### Steps to reproduce

1. Open Windows Terminal
2. Resize Terminal window to a small size
3. Press 'Enter' key until the active command prompt (with blinking cursor) reaches the last visible row in the window:
    ![Image](https://github.com/user-attachments/assets/a31ca24d-989f-44a4-bbba-7f412dc02c4e)

4. Run a command with a long URL, like: `echo 'https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalCore/lib/terminalcore-lib.vcxproj'`
5. Ensure the URL wraps to span 2 or more lines. If not, resize the window to reduce the width.
    ![Image](https://github.com/user-attachments/assets/a72f1bf7-6968-4a59-a3a7-80323603369a)

6. Scroll up one line so that only the first line of the wrapped URL is visible:    ![Image](https://github.com/user-attachments/assets/f0a34880-9e9d-4a8e-90c1-21f6fecf0845)
7. Ctrl+click the visible part of the URL


### Expected Behavior

It should navigate to the full URL (https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalCore/lib/terminalcore-lib.vcxproj)

### Actual Behavior

It navigates to the part of the URL that's visible (https://github.com/microsoft/terminal/bl), which is often invalid
Repository: rust
Issue: Compiler fails to see an existing trait implementation for an indirectly referred type
Labels: A-trait-system,A-associated-items,C-bug,T-types,fixed-by-next-solver

I get compilation errors for a `typenum`-based code which can be minimized to this snippet ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2bf0adba26b2b4ef8f5a9412684edfbf)):
```rust
use core::ops::Add;
use typenum::{Sum, Unsigned, U8};

pub type TagSize = U8;

pub type TagSizePlus1 = typenum::Add1<TagSize>; // does not work
// pub type TagSizePlus1 = typenum::U9; // works

pub fn foo<N>()
where
    N: Add<TagSizePlus1>,
    Sum<N, TagSizePlus1>: Unsigned,
{
    // code
}

```

`Add1<A>` is an [alias](https://docs.rs/typenum/latest/typenum/operator_aliases/type.Add1.html) for `<A as Add<B1>>::Output;` and `Sum<A, B>` is an [alias](https://docs.rs/typenum/latest/typenum/operator_aliases/type.Sum.html) for `<A as Add<B>>::Output`;

The snippet results in the following compilation error:
```text
error[E0277]: cannot add `UInt<UInt<UInt<UInt<UTerm, B1>, B0>, B0>, B1>` to `N`
  --> src/lib.rs:10:1
   |
10 | / pub fn foo<N>()
11 | | where
12 | |     N: Add<TagSizePlus1>,
13 | |     Sum<N, TagSizePlus1>: Unsigned,
   | |___________________________________^ no implementation for `N + UInt<UInt<UInt<UInt<UTerm, B1>, B0>, B0>, B1>`
```

But replacing `Sub1<SomeSize>` with `U9` (an [alias](https://docs.rs/typenum/latest/typenum/consts/type.U9.html) for `UInt<UInt<UInt<UInt<UTerm, B1>, B0>, B0>, B1>`) works just fine!

It looks like the compiler successfully resolves `Add1<SomeSize>` to `UInt<UInt<UInt<UInt<UTerm, B1>, B0>, B0>, B1>`, but then for some reason gets tripped while resolving the bounds and is unable to see that the bound on `N` which allows the addition.

Potentially relevant issue: https://github.com/rust-lang/rust/issues/79629
Repository: pytorch
Issue: torch.norm produces wrong results 
Labels: needs reproduction,triaged,module: linear algebra

### 🐛 Describe the bug

```python
import torch
import numpy as np

TV = torch.load("/home/dsq/NIPS/opt/siren/experiment_scripts/TV_e.pth").cpu()

print(TV.shape)

print(torch.linalg.norm(TV).item())

print(torch.linalg.norm(torch.linalg.norm(TV, dim=-1, keepdim=True)).item())

print(np.linalg.norm(TV.cpu().detach().numpy()).item())

print(torch.linalg.norm(torch.sqrt(TV[:, 0] ** 2 + TV[:, 1] ** 2)).item())

print(torch.sqrt((torch.sqrt(TV[:, 0] ** 2 + TV[:, 1] ** 2) ** 2).sum()).item())

```


2.5.1+cu12.4, numpy 1.26.4 results: 
torch.Size([38000, 2])
141.7647705078125
141.76475524902344
141.7647705078125
141.76475524902344
141.76475524902344

2.4.1+cu12.4, numpy 1.24.4 results:
torch.Size([38000, 2])
141.7647705078125
141.76475524902344
141.76475524902344
141.76475524902344
141.76475524902344


Expected results:
141.76475524902344

### Versions

2.5.1+cu12.4, 2.4.1+cu12.4, and 1.13.1+cu11.7

cc @jianyuh @nikitaved @pearu @mruberry @walterddr @xwang233 @Lezcano
Repository: vscode
Issue: Terminal: Run Recent Command shows up when there are no terminals
Labels: bug,help wanted,terminal-shell-integration

Repro:

1. Close all terminals
2. Run the command, 🐛 nothing happens

![Image](https://github.com/user-attachments/assets/3b6037be-c882-4f0c-84b6-4eed6189758d)

We should either hide it or implement it when there isn't a terminal.
Repository: godot
Issue: float `rotate_toward()` behaves incorrectly with negative delta
Labels: bug,topic:core

### Tested versions

4.3

### System information

Any

### Issue description

`rotate_toward()` is implemented by https://github.com/godotengine/godot/pull/80225, but set the incorrect target when delta is negative.

`move_toward()` when delta is negative, does not reach the original target and goes infinitely negative. It is correct.
`rotate_toward()` can still reach the original target even if delta is negative, but it will erroneously reach the inversed target.

It makes complete no sense to reach the inverted target. If you wanted to do that, you could simply invert the to instead of delta when passing the argument in the first place. Also, if using negative delta result is reaching the inverted target, it means that you cannot use negative delta for rotating turrets with fixed rotation direction and the like.

```gdscript
extends Node2D

func _ready() -> void:
	var scl_pos = 0
	var scl_neg = 0
	var scr_to = 10

	var rad_pos = 0
	var rad_neg = 0
	var rad_to = PI * 0.5

	print("scl src: " + str(0))
	print("scl target: " + str(scr_to))
	print("rad src: " + str(0))
	print("rad target: " + str(rad_to))

	rad_pos = rotate_toward(rad_pos, rad_to, PI * 0.1)
	rad_neg = rotate_toward(rad_neg, rad_to, PI * -0.1)
	scl_pos = move_toward(scl_pos, scr_to, 1)
	scl_neg = move_toward(scl_neg, scr_to, -1)

	print(("scl pos by %s x1: " % str(1)) + str(scl_pos))
	print(("scl neg by %s x1: " % str(-1)) + str(scl_neg))
	print(("rad pos by %s x1: " % str(PI * 0.1)) + str(rad_pos))
	print(("rad neg by %s x1: " % str(PI * -0.1)) + str(rad_neg))

	for i in range(99):
		rad_pos = rotate_toward(rad_pos, rad_to, PI * 0.1)
		rad_neg = rotate_toward(rad_neg, rad_to, PI * -0.1)
		scl_pos = move_toward(scl_pos, scr_to, 1)
		scl_neg = move_toward(scl_neg, scr_to, -1)

	print(("scl pos by %s x100: " % str(1)) + str(scl_pos))
	print(("scl neg by %s x100: " % str(-1)) + str(scl_neg))
	print(("rad pos by %s x100: " % str(PI * 0.1)) + str(rad_pos))
	print(("rad neg by %s x100: " % str(PI * -0.1)) + str(rad_neg))
```

Output:
```
scl src: 0
scl target: 10
rad src: 0
rad target: 1.5707963267949
scl pos by 1 x1: 1
scl neg by -1 x1: -1
rad pos by 0.31415926535898 x1: 0.31415926535898
rad neg by -0.31415926535898 x1: -0.31415926535898
scl pos by 1 x100: 10
scl neg by -1 x100: -100
rad pos by 0.31415926535898 x100: 1.5707963267949
rad neg by -0.31415926535898 x100: -1.5707963267949
```
`rad neg by -0.31415926535898 x1` is `-0.31415926535898`, not `0.31415926535898` it is correct.
But `rad neg by -0.31415926535898 x100` must be `1.5707963267949`, not `-1.5707963267949`. cc @ettiSurreal 

### Steps to reproduce

Use `rotate_toward()` with negative delta to reach the original target.

### Minimal reproduction project (MRP)

[wrong_rotate_toward_calc.zip](https://github.com/user-attachments/files/17707012/wrong_rotate_toward_calc.zip)
Repository: TypeScript
Issue: moduleResolution Bundler and importModuleSpecifierEnding
Labels: Needs Investigation

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

<!-- 🪓 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. -->

Version: 1.95.1 (Universal)
Commit: 65edc4939843c90c34d61f4ce11704f09d3e5cb6
Date: 2024-10-31T05:14:54.222Z
Electron: 32.2.1
ElectronBuildId: 10427718
Chromium: 128.0.6613.186
Node.js: 20.18.0
V8: 12.8.374.38-electron.0
OS: Darwin arm64 23.4.0

## My project is Node/Fastify written in typescript. 

Steps to Reproduce:

1. Set the compiler compiler options in a tsconfig:

```json
{
    "module": "ESNext",
    "target": "ESNext",
    "moduleResolution": "Bundler"
}
```

The suggested paths to import, for example, are:

![Image](https://github.com/user-attachments/assets/b08b5ad7-3862-4b47-a138-354f39dd1fc0)

2. Change to "moduleResolution": "Node" and then reload VSCode. 

The suggested paths to import are now:

![Image](https://github.com/user-attachments/assets/51a8ff9f-6cf4-42a5-9045-55521a7ac733)

I want the QuickFix Suggestions from 2. while using "moduleResolution": "Bundler"


I have these settings:

```json
{
    "javascript.preferences.importModuleSpecifierEnding": "minimal",
    "javascript.preferences.importModuleSpecifier": "non-relative"

    "typescript.preferences.importModuleSpecifierEnding": "minimal",
    "typescript.preferences.importModuleSpecifier": "non-relative",
}
```
Repository: kubernetes
Issue: Add statusz endpoint for kube-scheduler
Labels: kind/feature,sig/instrumentation,needs-triage

### What would you like to be added?

Part of 
- https://github.com/kubernetes/enhancements/issues/4827

Add the `/statuz` endpoint for kube-scheduler.

Sample response:
```
Started: Fri Sep  6 06:19:51 UTC 2024
Up: 0 hr 00 min 30 sec
Go version: go1.23.0
Binary version: 1.31.0-beta.0.981&#43;c6be932655a03b-dirty
Emulation version: 1.31.0-beta.0.981
Minimum Compatibility version: 1.30.0

List of useful endpoints
--------------
configz:/configz
healthz:/healthz
livez:/livez
metrics:/metrics
readyz:/readyz
sli metrics:/metrics/slis
```

/sig instrumentation

### Why is this needed?

Refer to [Motivation setcion](https://github.com/kubernetes/enhancements/blob/master/keps/sig-instrumentation/4827-component-statusz/README.md#motivation) in KEP.

```[tasklist]
### Tasks
```
Repository: opencv
Issue: Documentation states that cvtColor() supports CV_16U, but seems to actually only support CV_8U and CV_32F.
Labels: category: documentation

### Describe the doc issue

The cvtColor documentation:

https://docs.opencv.org/4.x/d8/d01/group__imgproc__color__conversions.html#gaf86c09fe702ed037c03c2bc603ceab14 

states:

"src	input image: 8-bit unsigned, 16-bit unsigned ( CV_16UC... ), or single-precision floating-point. "

but it looks like only  CV_8U and CV_32F are actually supported: 

```
terminate called after throwing an instance of 'cv::Exception'
  what():  OpenCV(4.1.1) /home/bbogart/src/opencv-4.1.1/modules/imgproc/src/color.simd_helpers.hpp:94: error: (-2:Unspecified error) in function 'cv::impl::{anonymous}::CvtHelper<VScn, VDcn, VDepth, sizePolicy>::CvtHelper(cv::InputArray, cv::OutputArray, int) [with VScn = cv::impl::{anonymous}::Set<3, 4>; VDcn = cv::impl::{anonymous}::Set<3>; VDepth = cv::impl::{anonymous}::**Set<0, 5>**; cv::impl::{anonymous}::SizePolicy sizePolicy = (cv::impl::<unnamed>::SizePolicy)2; cv::InputArray = const cv::_InputArray&; cv::OutputArray = const cv::_OutputArray&]'
> Unsupported depth of input image:
>     'VDepth::contains(depth)'
> where
>     **'depth' is 2 (CV_16U)**
```


### Fix suggestion

Strike any references to CV_16U in cvtColor docs. 
I don't know when this change happened, but I found it in using OpenCV 4.1.1, so changes should be made retroactively.
Repository: pytorch
Issue: asynchronous copies from accelerator to cpu: what should be the expected behaviour?
Labels: module: docs,triaged,module: python frontend

### 🐛 Describe the bug

## Problem

If you run

```python
import torch
x = torch.arange(1000, device="cuda")
y = torch.arange(1000, device="cuda")
x = x.to("cpu", non_blocking=True)
y = y.to("cpu", non_blocking=True)
# torch.cuda.synchronize()
assert (x == y).all()
```
you'll need to comment out the  `torch.cuda.synchronize()` call for this test to pass.
The same goes with tensors on MPS device (ie, replace "cuda" with "mps" in the script).

However, sending cpu tensors to cuda and performing a blocking operation like this will (should?) require a synchronization (see #139550 for context in the mps case): 
```python
import torch
x = torch.arange(1000, device="cpu")
y = torch.arange(1000, device="cpu")
x = x.to("cuda", non_blocking=True)
y = y.to("cuda", non_blocking=True)
# no need to sync!
assert (x == y).all()
```

## Solutions

My personal take here is that we should have either that
a. in all cases  (cpu -> cuda, cuda -> cpu, cpu -> mps, mps -> cpu, cuda -> cuda...) using `non_blocking` is safe, or
b. it is only safe in the case of <whatever> -> cuda. Then we should document in `torch.Tensor.to` that `non_blocking` may lead to corrupted data if no sync is called.

Now, there is no concept of a _cpu_ stream but we kinda expect that there is only one type of accelerator per machine AFAICT, so there is only one synchronization method to be called per machine (it could even just be `torch.synchronize()` and work across all H2D / D2H transfers?) That doesn't hold if we plan on supporting multiple accelerators / machine ofc.

I can also see that sending to cpu is a bit more special so we could fix the H2D transfers first and then deal with D2H but IMO for a consistent UX we should have the maximum uniformity across async data transfers behaviors.

cc @svekars @brycebortree @sekyondaMeta @AlannaBurke @albanD @malfet 

### Versions

nightlies
Repository: next.js
Issue: Bug/inconsistency with `dynamicIO` and dynamic imports
Labels: bug,linear: next,dynamicIO

### Link to the code that reproduces this issue

https://github.com/amannn/nextjs-bug-repro-json-import-turbo/commit/011dc47eddfb59aaea7e5461dcde85139b908c2c

### To Reproduce

1. Clone https://github.com/amannn/nextjs-bug-repro-json-import-turbo/
2. `pnpm i`
3. `pnpm dev --turbo`
4. See error

### Current vs. Expected behavior

When running with Turbo, this error message is printed:

![Screenshot 2024-11-11 at 20 07 56](https://github.com/user-attachments/assets/d52150f0-85ef-46e4-963f-47d2499ef5cc)

When running with webpack, there's no error.

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: x64
  Version: Darwin Kernel Version 23.6.0: Mon Jul 29 21:13:00 PDT 2024; root:xnu-10063.141.2~1/RELEASE_X86_64
  Available memory (MB): 16384
  Available CPU cores: 12
Binaries:
  Node: 20.11.1
  npm: 10.2.4
  Yarn: 1.22.22
  pnpm: 9.12.3
Relevant Packages:
  next: 15.0.4-canary.5 // Latest available version is detected (15.0.4-canary.5).
  eslint-config-next: 15.0.4-canary.5
  react: 19.0.0-rc-66855b96-20241106
  react-dom: 19.0.0-rc-66855b96-20241106
  typescript: 5.6.3
Next.js Config:
  output: N/A
```


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

dynamicIO

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

next dev (local)

### Additional context

_No response_
Repository: vscode
Issue: pytest parametrize test results are hard to read
Labels: bug,polish,testing


Type: <b>Bug</b>

<!-- Please fill in all XXX markers -->
# Behaviour

With parametrized tests, the results are hard to read in the "running tests for ..." right side window of test results.  
For non-parametrized tests, the test name is listed.  
For parametrized tests, the parameters are listed without the test name.  
I think it would be easier to read if it was "test_name[param_value]", similar to how `pytest -v` shows the results.

## Steps to reproduce:

Run a test with parametrizations.  
Here's a small example: 
```python
import pytest

def test_a_1():
    ...

def test_a_2():
    ...

@pytest.mark.parametrize('x', [1, 2])
def test_b(x):
    ...
```

I'm attaching a screen shot of the output to demo the issue. 
In this example I think "test_b[1]" and "test_b[2]" would be easier to read than "[1]" and "[2]".
![Image](https://github.com/user-attachments/assets/6e0cb73c-fe25-4076-8d32-eeb381829f7a)


The problem is more pronounced with a parametrized fixture.  
Example: 
```python
import pytest

@pytest.fixture(params=[1, 2])
def x(request):
    return request.param

def test_a(x):
    ...

def test_b(x):
    ...
```

Results in: 
![Image](https://github.com/user-attachments/assets/4685e68f-9319-463b-b9a3-bfcdd55303a4)


<!--
**After** creating the issue on GitHub, you can add screenshots and GIFs of what is happening. Consider tools like https://www.cockos.com/licecap/, https://github.com/phw/peek or https://www.screentogif.com/ for GIF creation.
-->

<!-- **NOTE**: Please do provide logs from Python Output panel. -->
# Diagnostic data

<details>

<summary>Output for <code>Python</code> in the <code>Output</code> panel (<code>View</code>→<code>Output</code>, change the drop-down the upper-right of the <code>Output</code> panel to <code>Python</code>)
</summary>

<p>

```
XXX
```

</p>
</details>


Extension version: 2024.18.0
VS Code version: Code 1.95.1 (65edc4939843c90c34d61f4ce11704f09d3e5cb6, 2024-10-31T05:14:54.222Z)
OS version: Windows_NT x64 10.0.22631
Modes:


<!-- generated by issue reporter -->