sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Case mismatch in setBreakpoints requests in a single session
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

<!-- 🪓 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
- OS Version: Windows 11

**Issue:**
In some cases, the `setBreakpoints` requests sent in the same session sends the path with different cases. Especially on case-insensitive file systems. This causes broken breakpoint experience on some debugger. Currently tested with [CodeLLDB](https://marketplace.visualstudio.com/items?itemName=vadimcn.vscode-lldb) and [android-debug](https://marketplace.visualstudio.com/items?itemName=nisargjhaveri.android-debug) on Windows. Issue is fairly easy to repro and affects across machines and projects.

**Debugging details:**
After some debugging, here is what I gathered.

The issue boils down to the two different paths taken by `getRawSource`. For a local file, if `this.sources` contains an entry for that URI, it directly returns `source.raw`. Otherwise, it returns name and path using canonical URI.
https://github.com/microsoft/vscode/blob/45a9f8902795ca9a10f411db90f690f67843d88d/src/vs/workbench/contrib/debug/browser/debugSession.ts#L1507-L1515

Form what I saw `this.sources` is populated when resolving frames on a breakpoint hit. The debugger sends frames with raw source info. That info is stored and used as is once available.

The issue arises when the canonical path and the raw source from debugger doesn't match. e.g. canonical path is `<path>/Native-Lib.cpp` but the debugger reported `<path>/native-lib.cpp`. This means that until the `this.sources` was populated for this Uri, we sent `<path>/Native-Lib.cpp` when setting breakpoints. And later, we send `<path>/native-lib.cpp`. This mismatch causes lldb to treat the paths differently and duplicate breakpoints.

**Potential solution:**
- Instead of using the sources.raw as is as reported by the debugger, should we always use canonical path when setting breakpoints?
- Anything else can be done to prevent this?
Repository: flutter
Issue: [display_list] high overhead on DL paint conversion for very long picture scrolling.
Labels: P3,team-engine,triaged-engine

Low priority, as I think this is an edge case. A large chunk of CPU time on the Ui thread is spent ferrying Paint data. Seems like we could probably make this faster?

See: https://gist.github.com/jonahwilliams/ab8ae105a8950635502434434b891bd9
Repository: material-ui
Issue: [Select] calling `.focus()` on the ref does not focus the component
Labels: component: select

### Steps to reproduce

https://mui.com/material-ui/react-select/
document.getElementById('demo-simple-select').focus()

### Current behavior

If you call .focus() on any of the elments that are rendered by MuiSelect or on the refs element it will not focus the select or it will only visually focus it, but pressing space to open the menu will not work (and instead scrolls the page down).

### Expected behavior

That I can call .focus on the ref or an element to focus the select or that **there is an alternative way documented / implemented** 
There is nothing document about this behavior in the docs.

### Context

Having a way to programmatically focus an select 

### Your environment

Mui@6, Chrome

**Search keywords**: MuiSelect
Repository: pytorch
Issue: Cleanup the scaling logic in runtime.triton_heuristics.triton_config
Labels: triaged,oncall: pt2,module: inductor

### 🐛 Describe the bug

In runtime.triton_heuristics.triton_config , we will scale the passed in XBLOCK, YBLOCK, ZBLOCK value according to various rules
- cap them with xnumel, ynumel, znumel
- scaling block size up when numel are large
- scaling XBLOCK up when the `min_elem_per_thread` requries so
- etc.

These scaling rules may cause issues. Here is one example: https://github.com/pytorch/pytorch/pull/138730

We should find time to clean them up.

### Error logs

_No response_

### Minified repro

_No response_

### Versions

.

cc @ezyang @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire @aakhundov
Repository: kubernetes
Issue: Tracking: archive cloud-provider-sample repository and remove references
Labels: kind/cleanup,sig/cloud-provider,triage/accepted

This issue is being created to help track the archiving of the github.com/kubernetes/cloud-provider-sample repository. During discussion at the [23 October SIG Cloud Provider office hours](https://www.youtube.com/watch?v=aXFkqfRMqd0), we decided that we would like to move forward with archiving this repository to reduce confusion about external cloud controller manager development.

The cloud-provider-sample repository was created 6 years ago with the intention of containing a sample implementation of the external cloud controller manager. Since then, the repository has not received any updates and a new sample has been created in the cloud-provider repository (see https://github.com/kubernetes/kubernetes/tree/master/staging/src/k8s.io/cloud-provider/sample)

As we would like to close the sample repository, and we do not feel it is appropriate to carry this issue on the cloud-provider repository, we are opening this issue to help us track the progress.

TODO
- [x] Update the cloud-provider-sample readme to indicate archive status (https://github.com/kubernetes/cloud-provider-sample/pull/15)
- [ ] Issue created on kubernetes/org to archive the repository
- [ ] Update readme in new sample directory to indicate relationship with staging repository
- [ ] Update readme in cloud-provider repository to highlight the sample location
- [ ] cloud-provider-sample archived
- [ ] Email sent to kubernetes-dev mailing list

/sig cloud-provider
/kind cleanup
Repository: flutter
Issue: There should be clarity and guidance on to address disposal of objects in exceptional situations.
Labels: framework,P3,team-framework,triaged-framework,a: leak tracking

Exceptional code paths should be finalized properly and should not result in leaking objects.

Some flutter tests are opted out from leak tracking because of exceptions.
And it is not clear if it is valid opt out.
Leak tracker may be can detect if exception happened and skip flagging not disposed objects for valid stories.

Search for `// leaking by design because of exception` in code of flutter framework.
Repository: next.js
Issue: Dynamic segments which contain dashes seem to be buggy (vercel only?)
Labels: bug,Navigation

### Link to the code that reproduces this issue

https://github.com/julianbenegas/nextjs-dynamic-segments-bug

### To Reproduce

1. Deploy the project with Vercel, OR try it out in my deployment: https://rewrite-bug.vercel.app
2. Navigate to /blog/some-slug (i'm just json stringifying the awaited params and rendering them)
3. See that `some-slug` is not what's shown, but rather `[doesnt-work]` encoded

### Current vs. Expected behavior

I expect the page to show `{"doesnt-work":"some-slug"}` but instead it shows `{"doesnt-work":"%5Bdoesnt-work%5D"}`

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.0.0: Tue Sep 24 23:37:25 PDT 2024; root:xnu-11215.1.12~1/RELEASE_ARM64_T6030
  Available memory (MB): 36864
  Available CPU cores: 12
Binaries:
  Node: 20.12.2
  npm: 10.5.0
  Yarn: 4.1.1
  pnpm: 8.14.1
Relevant Packages:
  next: 15.0.1 // Latest available version is detected (15.0.1).
  eslint-config-next: 15.0.1
  react: 19.0.0-rc-69d4b800-20241021
  react-dom: 19.0.0-rc-69d4b800-20241021
  typescript: 5.6.3
Next.js Config:
  output: N/A
```


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

Navigation

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

Vercel (Deployed)

### Additional context

if i rename the folder to `[slug]` or anything that doesn't contain a dash, this seems to be resolved. So, the issue seems to be related to dashes within dynamic segments.

if i pre-generate static params, those will work; for example: `https://rewrite-bug.vercel.app/blog/pregenerated`
Repository: react
Issue: [Compiler Bug]: False positive calling WebGLContext.useProgram
Labels: Type: Bug,Status: Unconfirmed,Component: Optimizing Compiler

### What kind of issue is this?

- [ ] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
- [ ] babel-plugin-react-compiler (build issue installing or using the Babel plugin)
- [X] eslint-plugin-react-compiler (build issue installing or using the eslint plugin)
- [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script)

### Link to repro

https://playground.react.dev/#N4Igzg9grgTgxgUxALhAgHgBwjALgAgBMEAzAQygBsCSoA7OXASwjvwFkBPAQU0wAoAlPmAAdNvihgEAURIkEjfkPwBeAHwjx+HfjiswBAOaU1RCHCgBbBHVwA6IwlwzKCG3YBCnAJKF+AORWnAC0cGR0AG5kYAGCjs4Awqy4GLiBAO4IAEYmAExxANzauvp0hvjBAAowEEYwZFZmJvZwMAhkqTV1DVZCxRI6LVII3fWN-NW141aCAzoAvgA0+ADaALpz4gviIAtAA

### Repro steps

Call `gl.useProgram` within an effect:

```ts
export default function MyApp() {
  useEffect(() => {
    const gl = document.getElementById('my-canvas').getContext('webgl2');
    const myProgram = gl.createProgram();
    gl.useProgram(myProgram); // this should not error; useProgram is not a React hook
  }, []);
}
```

`WebGLRenderingContext.useProgram` is not a hook, and is part of a built-in Web API


### How often does this bug happen?

Every time

### What version of React are you using?

19.0.0-rc-65a56d0e-20241020

### What version of React Compiler are you using?

19.0.0-rc-65a56d0e-20241020
Repository: pytorch
Issue: CI/CD: Figure out what to do with split build
Labels: module: ci,triaged

### 🐛 Describe the bug

If we don't plan to ship it to PyPI, it should be disabled.
Disabling workflows for now

### Versions

CI

cc @seemethere @pytorch/pytorch-dev-infra
Repository: godot
Issue: Xcode iOS Export godot_path returning Invalid project path specified: "project_name", aborting.
Labels: bug,platform:ios,needs testing,topic:export

### Tested versions

Reproducible in 4.3.Stable.Official

### System information

macOS Sonoma, M2 Pro 16gb Ram

### Issue description

Followed the tutorial outlined here: https://docs.godotengine.org/en/stable/tutorials/export/exporting_for_ios.html and Build succeeds but then I get this error:

```
Invalid project path specified: "project_name", aborting.
```

### Steps to reproduce

Use Godot 4.3 Stable on MacOS Sonoma with Xcode 16

Followed the tutorial outlined here: https://docs.godotengine.org/en/stable/tutorials/export/exporting_for_ios.html.

In `Supporting Files`> `export_project.info-plist` added `godot_path` as key and the exact name of the referenced folder as the value in i.e. `project_name`.
Aware that the project name should different than the exported project file/folder

### Minimal reproduction project (MRP)

N/A
Repository: godot
Issue: Extreme jitter and drift in moving tilemap platform
Labels: bug,topic:physics,topic:2d

### Tested versions

- Reproducible in 4.3.stable

### System information

Debian GNU/Linux 12.7

### Issue description

A CharacterBody2D over a TilemapLayer moved by a Path2D/PathFollow2D results in movement jitter. It also drifts from the platform if the scene is repeatedly paused/resumed.

I've used stretch mode viewport and snap transforms to pixel because I want to use it for a pixel perfect game but using stretch mode none and disabling snap transforms to pixel gives the same result.

### Steps to reproduce

Load the MRP and start it. Press repeatedly space or intro to pause/unpause the scene. The jitter will become drifting until the CharacterBody2D falls from the platform.

### Minimal reproduction project (MRP)

[testplatform.zip](https://github.com/user-attachments/files/17498701/testplatform.zip)
Repository: rust
Issue: Support for const string interpolation into inline assembly
Labels: C-enhancement,A-inline-assembly,T-lang,T-compiler

Related to [this comment](https://github.com/rust-lang/rust/issues/128464#issuecomment-2417528415).

Maybe related to #93332

This feature request targets the inline assembly macro `asm!` and globally scope assembly `global_asm!` to support direct string interpolation into the assembly template.

The semantic works very much like a `format!` in a narrower sense, that only constant string is supported. The proposed macro word is `interpolate $expr` where `$expr` is a const-evaluatable expression that yields a `&'static str` constant value.

An example of how it would work is as follows.

```rust
trait Helper {
    const SRC: &'static str;
}

fn make_it_work<H: Helper>(h: &H, x: i64) {
    asm!(
        "mov {0}, {1}",
        in(reg) x,
        interpolate H::SRC
    );
}

struct H;
impl Helper for H {
    const SRC: &'static str = "MAGIC";
}

fn invoke() {
    make_it_work(&H, 42);
}
```

The one and only instantiation of `asm!` macro, when completely expanded through codegen, might have yield the following assembly line.

```
    mov rcx, MAGIC
```

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: go
Issue: proposal: testing: ability to tell if test is running in parallel
Labels: Proposal

### Proposal Details

Unit tests can indicate their ability to be run in parallel by making the opt-in call `t.Parallel()`.

However sometimes a test might opt in but then mistakenly change some global state which could race with something else.  In this case, the parallel test should actually be a serial one.  In a large codebase it can be tricky to protect against this happening.

For example,

```go
func TestShouldNotBeParallel(t *testing.T) {
    t.Parallel()
    // ...
    changeGlobalState(t) // a mistake, given above t.Parallel()
    // ...
}

func changeGlobalState(t *testing.T) {
    // proposal: could we check `t` here to determine that we're running in parallel when we shouldn't be, and error out?
    if t.IsRunningInParallel() {
        t.Fatal("changeGlobalState called from test with t.Parallel()")
    }

    // ...
}
```

The proposal here is a function like `t.IsRunningInParallel()` that could return true in the case that the current test is running in a parallel context.  I don't **think** there's a way to check this currently?
Repository: PowerToys
Issue: Shift Key is blocked randomly
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.85.1

### Installation method

Scoop

### Running as admin

None

### Area(s) with issue?

General

### Steps to reproduce

For some reason, I can no longer use the Shift key normally when PowerToys is open. Please note that this does not happen right after PowerToys is up and running, but occurs after a while.

I cannot use any shortcuts that include the Shift key (like <kbd>Ctrl + Shift + T</kbd>), nor can I type uppercase letters via <kbd>Shift + \<Letter\></kbd>. However, pressing the Shift key five times in a row, will open up the Sticky Keys dialog, which means that the key isn't fully unresponsive, but is being rendered with limited functionality.

I have no re-mappings in the PowerToys' Keyboard Manager that includes the Shift key.

This has not occurred to me before v0.85.1. It was working fine until I upgraded from v0.83.0 to 0.85.1 via Scoop.

I came to the conclusion that it was PowerToys that was causing this unusual behaviour, because when I manually quit PowerToys, everything went back to normal and the Shift key was working fine.

I have no clue why this would happen. Perhaps some element of PowerToys is interfering with a Windows keyboard setting?

### ✔️ Expected Behavior

_No response_

### ❌ Actual Behavior

_No response_

### Other Software

_No response_
Repository: godot
Issue: Keys that may have lengths in the Animataion editor are not well displayed if the length is too short
Labels: discussion,topic:editor,topic:animation

### Tested versions

- Reproducible in: 4.3.stable, v4.4.dev3

### System information

Debian Linux/X11 12.7, xfwm4 4.18.0 with built-in compositor, AMD RX 550, Compatibility renderer

### Issue description

when animating the property ``AudioStreamPlayer:playing``, the checkboxes are only visible when the value is set to ``false``. if the value is ``true``, the checkbox is invisible &mdash; and it cannot be clicked: it must be drag&#x2011;selected

> ![](https://github.com/user-attachments/assets/6972ddb2-9a6f-41d9-9dad-654949df62cd)
> Animation panel showing an animation with the tracks ``AudioStreamPlayer:playing`` and ``ColorRect:visible`` being animated identically.
> the checkboxes on the ``ColorRect:visible`` track look and act normally,
> only the checkboxes on the ``AudioStreamPlayer:playing`` track are bugged

### Steps to reproduce

1. create a new Godot project
2. create a scene with an AnimationPlayer and an AudioStreamPlayer
3. add a sample to the AudioStreamPlayer
4. animate the proprety ``AudioStreamPlayer:playing`` using the AnimationPlayer

### Minimal reproduction project (MRP)

[2024-10-24_music-animation-bug.zip](https://github.com/user-attachments/files/17499031/2024-10-24_music-animation-bug.zip) (5.4&#x202f;KiB before extracting and opening in Godot, 4.1&#x202f;MiB after)

(credit: sample is located under ``shapes/micro.wav`` in [LMMS](https://lmms.io) built&#x2011;in samples)
Repository: node
Issue: Coverage workflows fail on v22.x/v22.x-staging
Labels: meta,release-agenda,coverage,v22.x

Starting with Node.js 22.8.0 (https://github.com/nodejs/node/commit/78ee90e5d90f4cd3d1921bd96cbac829fee3d7f0) the "without intl" coverage workflow started failing due to ["does not meet the global threshold"](https://github.com/nodejs/node/actions/runs/10675930420/job/29588689452).

From Node.js 22.9.0 (https://github.com/nodejs/node/commit/4631be0311fbde7b77723757e15d025727399e63) both coverage workflows (with and without intl) fail due to the same reason (not meeting the global threshold). The situation persists through Node.js 22.10.0 and for the [proposal for Node.js 22.11.0](https://github.com/nodejs/node/pull/55504#issuecomment-2433757600). (I'm going to ignore this for Node.js 22.11.0 as the release is intentionally not including changes beyond the metadata updates to mark the release as LTS.)

AFAIK the coverage workflows are passing on Node.js 23 and `main` and were passing on Node.js 22.7.0 (https://github.com/nodejs/node/commit/65eff1eb19a6d8e17435bbc4147ac4535e81abb4), so the question is what has/hasn't landed on v22.x-staging to cause the discrepancy? If there isn't an easy way to get the workflow passing again, can we lower the threshold for Node.js 22 only, or even disable the coverage workflows for 22?

cc @nodejs/releasers
Repository: pytorch
Issue: [Inductor] Regression in test_comprehensive_nn_functional_max_pool2d_cuda from triton
Labels: triaged,oncall: pt2,upstream triton

### 🐛 Describe the bug

```
root@3b81e04520e3:/workspace# python /opt/pytorch/pytorch/test/inductor/test_torchinductor_opinfo.py -v -k test_comprehensive_nn_functional_max_pool2d_cuda  test_comprehensive_nn_functional_max_pool2d_cuda_float16 (__main__.TestInductorOpInfoCUDA.test_comprehensive_nn_functional_max_pool2d_cuda_float16) ... ERROR
test_comprehensive_nn_functional_max_pool2d_cuda_float32 (__main__.TestInductorOpInfoCUDA.test_comprehensive_nn_functional_max_pool2d_cuda_float32) ... ERROR
test_comprehensive_nn_functional_max_pool2d_cuda_float64 (__main__.TestInductorOpInfoCUDA.test_comprehensive_nn_functional_max_pool2d_cuda_float64) ... ERROR  
...
Mismatched elements: 4 / 36 (11.1%)
Greatest absolute difference: 0.372314453125 at index (0, 0, 2, 5) (up to 1e-05 allowed)
Greatest relative difference: 1.0 at index (0, 0, 0, 5) (up to 0.001 allowed)
...
Mismatched elements: 4 / 36 (11.1%)
Greatest absolute difference: 0.37210461497306824 at index (0, 0, 2, 5) (up to 1.5e-05 allowed)
Greatest relative difference: 1.0 at index (0, 0, 0, 5) (up to 1.3e-05 allowed)
...
Mismatched elements: 4 / 36 (11.1%)                                                                                                                          
Greatest absolute difference: 0.37626347335627985 at index (0, 1, 0, 5) (up to 1e-07 allowed)      
Greatest relative difference: 1.0 at index (0, 0, 1, 5) (up to 1e-07 allowed)       
```


Regression to numerical mismatches in test_comprehensive_nn_functional_max_pool2d_cuda from https://github.com/pytorch/pytorch/issues/131072 with PyTorch built with the current pinned triton commit [cf34004b8a67d290a962da166f5aa2fc66751326](https://github.com/triton-lang/triton/commits/cf34004b8a67d290a962da166f5aa2fc66751326) from Sep 24. Manually rebuilding triton wheel with triton commit [72734f086b3a70a0399b7e9d21b83d5d8dc7e1d5](https://github.com/triton-lang/triton/commits/72734f086b3a70a0399b7e9d21b83d5d8dc7e1d5) from Jul 30 as mentioned in https://github.com/pytorch/pytorch/issues/131072#issuecomment-2261665136 fixes the issue. 

cc @ezyang @chauhang @penguinwu @bertmaher @int3 @davidberard98 @nmacchioni @chenyang78 @embg @peterbell10 @aakhundov @eqy @nWEIdia 

### Versions

torch: https://github.com/pytorch/pytorch/commit/df5bbc09d191fff3bdb592c184176e84669a7157
triton: https://github.com/triton-lang/triton/commits/cf34004b8a67d290a962da166f5aa2fc66751326
Repository: next.js
Issue: Playwright could not find tests with Nextjs 15 experimental testmode 
Labels: bug,Testing

### Link to the code that reproduces this issue

https://github.com/KagamiChan/next15-playwright-test-not-found

### To Reproduce

1. run `npm run build`
2. run `npx playwright test`
3. playwright reports "No tests found"
```
next15-playwright-test-not-found> npx playwright test
Error: No tests found

To open last HTML report run:

  npx playwright show-report
```

### Current vs. Expected behavior

playwright should detect the test cases and run it.

### Provide environment information

```bash
Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Pro
  Available memory (MB): 64618
  Available CPU cores: 32
Binaries:
  Node: 21.7.1
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 15.0.1 // Latest available version is detected (15.0.1).
  eslint-config-next: 15.0.1
  react: 19.0.0-rc-69d4b800-20241021
  react-dom: 19.0.0-rc-69d4b800-20241021
  typescript: 5.6.3
Next.js Config:
  output: N/A
```


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

Testing

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

next start (local)

### Additional context

I also tried with pnpm and the result is the same, so it might not be an issue of package manager

The setup is following the instructions here: https://github.com/vercel/next.js/blob/canary/packages/next/src/experimental/testmode/playwright/README.md

This used to work with v14