sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: DISABLED test_graph_break_inside_ctx_with_side_effects (__main__.ContextlibContextManagerTests)
Labels: triaged,module: flaky-tests,skipped,oncall: pt2,module: dynamo

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_graph_break_inside_ctx_with_side_effects&suite=ContextlibContextManagerTests&limit=100) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/35960839362).

Over the past 3 hours, it has been determined flaky in 3 workflow(s) with 3 failures and 3 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_graph_break_inside_ctx_with_side_effects`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.



<details><summary>Sample error message</summary>

```
Traceback (most recent call last):
  File "/var/lib/jenkins/workspace/test/dynamo/test_ctx_manager.py", line 2051, in test_graph_break_inside_ctx_with_side_effects
    self.assertEqual(len(eager.graphs), 0)
  File "/opt/conda/envs/py_3.10/lib/python3.10/site-packages/torch/testing/_internal/common_utils.py", line 4028, in assertEqual
    raise error_metas.pop()[0].to_error(  # type: ignore[index]
AssertionError: Scalars are not equal!

Expected 0 but got 1.
Absolute difference: 1
Relative difference: inf

To execute this test, run the following from the base repo dir:
    python test/dynamo/test_ctx_manager.py ContextlibContextManagerTests.test_graph_break_inside_ctx_with_side_effects

This message can be suppressed by setting PYTORCH_PRINT_REPRO_ON_FAILURE=0
```

</details>


Test file path: `dynamo/test_ctx_manager.py`

cc @clee2000 @wdvr @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @chauhang @amjames
Repository: vscode
Issue: Explorer not showing files
Labels: info-needed


Type: <b>Bug</b>

Not showing project file on the explorer

VS Code version: Code 1.96.4 (cd4ee3b1c348a13bafd8f9ad8060705f6d4b9cba, 2025-01-16T00:16:19.038Z)
OS version: Linux x64 6.8.0-51-generic snap
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz (4 x 3192)|
|GPU Status|2d_canvas: unavailable_software<br>canvas_oop_rasterization: disabled_off<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: disabled_software<br>multiple_raster_threads: enabled_on<br>opengl: disabled_off<br>rasterization: disabled_software<br>raw_draw: disabled_off_ok<br>skia_graphite: disabled_off<br>video_decode: disabled_software<br>video_encode: disabled_software<br>vulkan: disabled_off<br>webgl: unavailable_software<br>webgl2: unavailable_software<br>webgpu: disabled_off<br>webnn: unavailable_software|
|Load (avg)|2, 2, 2|
|Memory (System)|11.40GB (6.16GB free)|
|Process Argv|--no-sandbox . --crash-reporter-id f85a8924-9ea9-4f52-bbad-e71cf3fdc9d8|
|Screen Reader|no|
|VM|0%|
|DESKTOP_SESSION|ubuntu-xorg|
|XDG_CURRENT_DESKTOP|Unity|
|XDG_SESSION_DESKTOP|ubuntu-xorg|
|XDG_SESSION_TYPE|x11|
</details><details><summary>Extensions (35)</summary>

Extension|Author (truncated)|Version
---|---|---
dscodegpt|Dan|3.7.16
dart-code|Dar|3.102.0
flutter|Dar|3.102.0
vscode-eslint|dba|3.0.10
es7-react-js-snippets|dsz|4.4.3
react-native-react-redux|EQu|2.0.6
prettier-vscode|esb|11.0.0
classroom|git|0.0.4
codespaces|Git|1.17.3
copilot|Git|1.257.0
copilot-chat|Git|0.23.2
vscode-github-actions|git|0.27.0
vscode-pull-request-github|Git|0.102.0
vsc-python-indent|Kev|1.19.0
rainbow-csv|mec|3.14.0
vscode-html-format|moh|0.1.6
vscode-docker|ms-|1.29.4
debugpy|ms-|2024.14.0
python|ms-|2024.22.2
vscode-pylance|ms-|2024.12.1
jupyter|ms-|2024.11.0
jupyter-keymap|ms-|1.1.2
jupyter-renderers|ms-|1.0.21
vscode-jupyter-cell-tags|ms-|0.1.9
vscode-jupyter-slideshow|ms-|0.1.6
remote-containers|ms-|0.394.0
live-server|ms-|0.4.15
makefile-tools|ms-|0.11.13
vscode-speech|ms-|0.12.1
vsliveshare|ms-|1.0.5948
vscode-thunder-client|ran|2.33.2
LiveServer|rit|5.7.9
vs-code-prettier-eslint|rve|6.0.0
vscode-wakatime|Wak|25.0.0
markdown-all-in-one|yzh|3.6.2

(1 theme extensions excluded)

</details><details>
<summary>A/B Experiments</summary>

```
vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492:30256859
vscod805:30301674
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
962ge761:30959799
pythonnoceb:30805159
pythonmypyd1:30879173
2e7ec940:31000449
pythontbext0:30879054
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
dsvsc021:30996838
dvdeprecation:31068756
dwnewjupyter:31046869
nativerepl2:31139839
pythonrstrctxt:31112756
nativeloc2:31192216
cf971741:31144450
iacca1:31171482
notype1:31157159
5fd0e150:31155592
dwcopilot:31170013
stablechunks:31184530
6074i472:31201624
dwoutputs:31217127
9064b325:31222308
copilot_t_ci:31222730

```

</details>

<!-- generated by issue reporter -->
Repository: rust
Issue: Detect missing `else` in block with `return`
Labels: A-diagnostics,A-parser,P-low,T-compiler,F-let_else

```
error: expected identifier, found keyword `return`
   --> /home/gh-estebank/rust/compiler/rustc_lint/src/default_could_be_derived.rs:249:13
    |
248 |         let hir::VariantData::Struct { fields, recovered: Recovered::No } = data {
    |                                                                             ---- while parsing this struct
249 |             return;
    |             ^^^^^^ expected identifier, found keyword
    |
help: escape `return` to use it as an identifier
    |
249 |             r#return;
    |             ++
```

This should detect that there's a missing `else`: `= data else {`.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: ollama
Issue: feat: OpenAI reasoning_content compatibility
Labels: feature request

The current thinking model outputs XML tags to distinguish between thinking and answering, and we need a new feature to make the `reasoning_content` of the OpenAI SDK work normally
Repository: godot
Issue: [Bug] Open project with rendering method Mobile cause crash entire MacOS on MacOS Sequoia
Labels: bug,platform:macos,needs testing,crash

### Tested versions

- Godot 4.2.2

### System information

Godot 4.2.2, MacBook pro 2020, MacOS Sequoia 15.1.1, Intel Iris plus graphics

### Issue description

1.  Occurred with project create not on Mac
- I created a project on Windows first, with rendering method Mobile
- Then I pull git from github and open project on Macbook
- Godot stuck a while an I can't even click or use mouse
- Then mac system crash and auto restart
2. Also occurred with project create on Mac
- Create a project on Mac, with rendering method Mobile
- Editor stuck a while and cause crash whole OS

### Steps to reproduce

1.  Occurred with project create not on Mac
- I created a project on Windows first, with rendering method Mobile
- Then I pull git from github and open project on Macbook
- Godot stuck a while an I can't even click or use mouse
- Then mac system crash and auto restart
2. Also occurred with project create on Mac
- Create a project on Mac, with rendering method Mobile
- Editor stuck a while and cause crash whole OS

### Minimal reproduction project (MRP)

[demo.zip](https://github.com/user-attachments/files/18499730/demo.zip)

### Work around
If someone face this issue like me, you still can work around by change rendering method to Compatibility
Set manual by edit project.godot:
```
renderer/rendering_method="gl_compatibility"
renderer/rendering_method.mobile="gl_compatibility"
```
Repository: ollama
Issue: ollama pull hangs at ~90% completion
Labels: bug

### What is the issue?

<img width="1266" alt="Image" src="https://github.com/user-attachments/assets/821bda2a-f119-4c46-b72d-c00305072cc4" />


Seems to work fine after a couple retries... Very strange 

### OS

Linux

### GPU

Nvidia

### CPU

Intel

### Ollama version

0.5.7
Repository: ui
Issue: [bug]:
Labels: bug

### Describe the bug

Can not get `toaster.tsx` when using "manual" method on the shadcn/ui site.

https://ui.shadcn.com/docs/components/toast

It appear `toast.tsx` and `toaster.tsx` are the same file and the actual `toaster.tsx` file is not present. I'm forced to use the manual method because I can't figure out how to get the shadcn CLI to work inside an electron app after significant time investment so I have no way to download it using the CLI.

![Image](https://github.com/user-attachments/assets/5a9fff9b-1bbc-4e40-b530-0711a58b8d52)

### Affected component/components

toaster.tsx

### How to reproduce

1. Visit https://ui.shadcn.com/docs/components/toast
2. Click `Manual`
3. Try to get the source for `toaster.tsx`

It gives you the source for `toast.tsx` instead.

### Codesandbox/StackBlitz link

_No response_

### Logs

```bash

```

### System Info

```bash
n/a
```

### Before submitting

- [x] I've made research efforts and searched the documentation
- [x] I've searched for existing issues
Repository: next.js
Issue: Sitemap rendering broken on NextJS 15 with edge runtime
Labels: Output (export/standalone)

### Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/cranky-https-7mqs67

### To Reproduce

Error:

```
15:44:40.872 | ▲  ⚠ Using edge runtime on a page currently disables static generation for that page
15:44:41.910 | ▲  [Error: Failed to collect configuration for /sitemap/sitemap/[__metadata_id__]] {
15:44:41.910 | ▲  [cause]: [Error: Edge runtime is not supported with `generateStaticParams`.]
15:44:41.911 | ▲  }
15:44:41.914 | ▲  > Build error occurred
15:44:41.919 | ▲  [Error: Failed to collect page data for /sitemap/sitemap/[__metadata_id__]] {
15:44:41.920 | ▲  type: 'Error'
15:44:41.920 | ▲  }
15:44:42.040 | ▲  Error: Command "npm run vercel-build" exited with 1
```

The sitemap MUST be edge-based - I don't want to statically-generate all my existing content.

### Current vs. Expected behavior

I expect to run all my sitemaps as dynamic edge functions as I could in NextJS 14. At the moment I can't even get past the build stage - this is the only thing remaining to bring me from Nextjs 14 to 15.

### Provide environment information

Cloudflare Next on Pages


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

Output (export/standalone)

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

Other (Deployed), next build (local)

### Additional context

This build error occurs locally also. For now I've tried to use static generation but cloudflare pages also fails on this step as the database url isn't provided from the environment on build to the build step. Weird. Still, this is a regression IMHO.
Repository: rust
Issue: Result type inference breaks in 2024 edition, while working correctly in 2021 edition
Labels: A-inference,C-bug,A-coercions,F-never_type,T-types

I tried this code:

```rust
fn foo() -> Result<(), u8> {
    Ok(())
}

fn test() -> Result<(), u8> {
    let f: fn() -> _ = foo as _;

    f()?;

    Ok(())
}
```

I expected to see this happen:

Type inference on `f` should work correctly.

Instead, this happened:

When switching to 2024 edition something odd is happening and inference results in confusing compilation error:
```
error[E0271]: type mismatch resolving `<Result<(), u8> as Try>::Output == !`
 --> src/lib.rs:7:5
  |
7 |     f()?;
  |     ^^^^ expected `!`, found `()`
  |
  = note:   expected type `!`
          found unit type `()`
```

The same code works fine on 2021 edition and I don't understand why 2024 breaks.

Replacing `-> _` with explicit `-> Result<(), u8>` helps, but it is too verbose and hurts readability.

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=7f1158511f3560d231db70cb839340c4

### Meta
`rustc --version --verbose`:
```
1.86.0-nightly

(2025-01-21 ed43cbcb882e7c06870a)
```
Repository: pytorch
Issue: DISABLED test_extern (__main__.NumBytesMetricTests)
Labels: module: rocm,triaged,module: flaky-tests,skipped,oncall: pt2,module: inductor

Platforms: rocm

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_extern&suite=NumBytesMetricTests&limit=100) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/35959227973).

Over the past 3 hours, it has been determined flaky in 3 workflow(s) with 3 failures and 3 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_extern`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.



<details><summary>Sample error message</summary>

```
Traceback (most recent call last):
  File "/var/lib/jenkins/pytorch/test/inductor/test_perf.py", line 152, in test_extern
    self.assertExpectedInline(count_numel(f, *inp), """200""")
  File "/opt/conda/envs/py_3.10/lib/python3.10/site-packages/torch/testing/_internal/common_utils.py", line 3066, in assertExpectedInline
    return super().assertExpectedInline(actual if isinstance(actual, str) else str(actual), expect, skip + 1)
  File "/opt/conda/envs/py_3.10/lib/python3.10/site-packages/expecttest/__init__.py", line 413, in assertExpectedInline
    assert_expected_inline(
  File "/opt/conda/envs/py_3.10/lib/python3.10/site-packages/expecttest/__init__.py", line 378, in assert_expected_inline
    assert_eq(expect, actual, msg=help_text)
  File "/opt/conda/envs/py_3.10/lib/python3.10/site-packages/expecttest/__init__.py", line 450, in assertMultiLineEqualMaybeCppStack
    self.assertMultiLineEqual(expect, actual, *args, **kwargs)
  File "/opt/conda/envs/py_3.10/lib/python3.10/unittest/case.py", line 1226, in assertMultiLineEqual
    self.fail(self._formatMessage(msg, standardMsg))
  File "/opt/conda/envs/py_3.10/lib/python3.10/unittest/case.py", line 675, in fail
    raise self.failureException(msg)
AssertionError: '200' != '820'
- 200
?   -
+ 820
? +
 : To accept the new output, re-run test with envvar EXPECTTEST_ACCEPT=1 (we recommend staging/committing your changes before doing this)

To execute this test, run the following from the base repo dir:
    PYTORCH_TEST_WITH_ROCM=1 python test/inductor/test_perf.py NumBytesMetricTests.test_extern

This message can be suppressed by setting PYTORCH_PRINT_REPRO_ON_FAILURE=0
```

</details>


Test file path: `inductor/test_perf.py`

cc @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang @naromero77amd @clee2000 @wdvr @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire @chauhang @aakhundov
Repository: ollama
Issue: Ollama Truncates Beginning of User Messages and System Prompt When Exceeding Context Window
Labels: bug

### What is the issue?

**Description:**

I am encountering an issue with Ollama where, upon sending a message that exceeds the context window, the model truncates the beginning of the message, including the system prompt. This is particularly frustrating as it leads to the loss of crucial context that is essential for the model's behavior. 

**Steps to Reproduce:**

1. Compose a message exceeding the context window limit.
2. Send the message to Ollama.
3. Observe that the beginning of the message, including the system prompt, is truncated.

**Expected Behavior:**

When a message exceeds the context window, Ollama should prioritize retaining the beginning of the message, especially the system prompt, to maintain context and ensure the model behaves as intended.

**Request for Assistance:**

Could you please advise if there are parameters that can be adjusted to modify this behavior? Allowing the retention of the message's beginning would significantly enhance the user experience. Thank you for your consideration and assistance.

### OS

Windows

### GPU

Nvidia

### CPU

AMD

### Ollama version

v0.5.7
Repository: godot
Issue: Exporting embeded pck potential fix?
Labels: feature proposal,platform:windows,topic:export

### Tested versions

4.3 Stable But have seen tones of people having same issues all the way back to Godot 3

### System information

Windows-10 Nitro 5 Laptop

### Issue description

Recently was trying to export my game to windows-10 embeded pck but got frustrated as while the game would export perfectly fine but the custom icon would not... After searching for a while I discovered my issue was with windows folder cache in some way. As if I exported to a brand new sub folder each export it would work perfectly. But would only be "corrupted" by exporting to that folder again with the same name. After exporting into new subfolder I noticed it would work perfectly in every other directory except if you dragged it back into the corrupted folder... I think this isolates the problem and shows windows is guilty here. My proposal if possible is to flag windows to refresh the cache each time a project is exported with embeded pck if that is possible? Or atleast update the documentation to advise people to create a new subfolder each time. https://www.youtube.com/watch?v=J7T0ZVfz5ZU Video where comments show this would help a lot of people) ![Image](https://github.com/user-attachments/assets/92280fe4-3552-4bfd-a0fb-0ac3765ed454)

### Steps to reproduce

Try to export a game with embedded pck with no icon (default icon)
Export again with same name and same folder in that corrupted cache space but with a new icon and notice how its still default
Create a new subfolder and export there and it has the new one but dragging it into corrupted folder will bring back old one

### Minimal reproduction project (MRP)

https://github.com/JonathanHaws/Wrath repo this is happening with. relatively small game jam game I am working on...
Repository: vscode
Issue: SCM Working Sets: Creating a new branch restores old working set if identically named branch existed in the past
Labels: feature-request,scm

<!-- ⚠️⚠️ 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.96.3
- OS Version: Mac & Linux

Steps to Reproduce:

In the settings, set `scm.workingSets.enabled` to `true` and `sc.workingSets.default` to `"current"`. Then

```
git switch main  # close all editors
git checkout -b abc  # now open a file
git switch main  # VScode closes editors if SCM>Working Sets is enabled
git branch -D abc
# <time passes>
git checkout -b abc  # Unexpected behavior: Restores editor from step 2!
```

Expected behavior:

I would have expected to restore state only when *switching* branches, not when creating new branches. It seems VScode erroneously detects `git checkout -b` as a branch *switch* instead of a new branch creation if a branch of the same name existed in the past?
Repository: ui
Issue: [bug]: npm error Unsupported URL Type "workspace:": workspace:* using npx shadcn@canary init
Labels: bug

### Describe the bug

When creating a new project and running `npx shadcn@canary init`, selecting the next.js(monorepo) version results in an `EUNSUPPORTEDPROTOCOL` error.

In my opinion, The reason for this is likely that Shadcn defaults to npm when it cannot detect a package manager, then attempts to run the npm install command. However, the monorepo template files are based on pnpm, which causes compatibility issues and results in the error

### Affected component/components

CLI init(monorepo)

### How to reproduce

1. make empty project
2. execute `npx shadcn@canary init`
3. Would you like to start a new project? › Next.js (Monorepo)

### Codesandbox/StackBlitz link

_No response_

### Logs

```bash
shadcn-mono-test git:(main) npx shadcn@canary init                            

✔ The path /Users/jh/shadcn-mono-test does not contain a package.json file.
  Would you like to start a new project? › Next.js (Monorepo)
✔ What is your project named? … my-app
✖ Something went wrong creating a new Next.js monorepo.
Something went wrong. Please check the error below for more details.
If the problem persists, please open an issue on GitHub.

Command failed with exit code 1: npm install
npm error code EUNSUPPORTEDPROTOCOL
npm error Unsupported URL Type "workspace:": workspace:*
npm error A complete log of this run can be found in: /Users/jh/.npm/_logs/2025-01-22T06_59_21_296Z-debug-0.log
```

### System Info

```bash
mac
```

### Before submitting

- [x] I've made research efforts and searched the documentation
- [x] I've searched for existing issues