sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: type level debuginfo is duplicated across codegen units
Labels: A-debuginfo,T-compiler,C-bug,I-heavy

<!--
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
// inner.rs
  /// Byte order that is selectable at runtime.
  #[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
  pub enum RunTimeEndian {
      /// Little endian byte order.
      Little,
      /// Big endian byte order.
      Big,
  }

// main.rs
  use inner::RunTimeEndian;

  fn main() {
      use RunTimeEndian::*;
      println!("{:?}{:?}{:?}{:?}{:?}", Little, Big, Little, Big, Little);
  }
```

I expected to see this happen: `RunTimeEndian` only appears once in the debuginfo.

Instead, this happened: `RunTimeEndian` appears twice:
```
; dwarfdump -a /home/jyn/.local/lib/cargo/target/debug/example | rg '\sRunTimeEndian$' -B5
< 1><0x00000329>    DW_TAG_namespace
                      DW_AT_name                  inner
< 2><0x0000032e>      DW_TAG_enumeration_type
                        DW_AT_type                  <0x00000322>
                        DW_AT_enum_class            yes(1)
                        DW_AT_name                  RunTimeEndian
--
< 1><0x0000002a>    DW_TAG_namespace
                      DW_AT_name                  inner
< 2><0x0000002f>      DW_TAG_enumeration_type
                        DW_AT_type                  <0x00000088>
                        DW_AT_enum_class            yes(1)
                        DW_AT_name                  RunTimeEndian
```

Note that the original (non-minimized) example was much worse; the `correctness` integration test for `addr2line` has this duplicated 59 times.

cc https://github.com/rust-lang/rust/issues/129722, https://github.com/rust-lang/rust/issues/115455. this is not the same as either of those because it only appears across codegen units (AFAICT).

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.86.0-nightly (049355708 2025-01-18)
binary: rustc
commit-hash: 049355708383ab1b9a1046559b9d4230bdb3a5bc
commit-date: 2025-01-18
host: x86_64-unknown-linux-gnu
release: 1.86.0-nightly
LLVM version: 19.1.7
```
Repository: rust
Issue: Dropped non-Send incorrectly reported as living, resulting in non-Send Future
Labels: C-bug,needs-triage

This:

```rust
struct NonSend(*const ());

impl NonSend {
	fn noop(&self) {}
}

fn main() {
	assert_send(async {
		let x = NonSend(core::ptr::null());
		x.noop();
		drop(x);
		async {}.await;
	});
}

fn assert_send(_: impl Send) {}
```

[Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=660c2df413763c4e2fd007962e3dfae8)

Errors with:
```
error: future cannot be sent between threads safely
  --> src/main.rs:8:2
   |
8  | /     assert_send(async {
9  | |         let x = NonSend(core::ptr::null());
10 | |         x.noop();
11 | |         drop(x);
12 | |         async {}.await;
13 | |     });
   | |______^ future created by async block is not `Send`
   |
   = help: within `{async block@src/main.rs:8:14: 8:19}`, the trait `Send` is not implemented for `*const ()`
note: future is not `Send` as this value is used across an await
  --> src/main.rs:12:12
   |
9  |         let x = NonSend(core::ptr::null());
   |             - has type `NonSend` which is not `Send`
...
12 |         async {}.await;
   |                  ^^^^^ await occurs here, with `x` maybe used later
note: required by a bound in `assert_send`
  --> src/main.rs:16:24
   |
16 | fn assert_send(_: impl Send) {}
   |                        ^^^^ required by this bound in `assert_send`

error: could not compile `playground` (bin "playground") due to 1 previous error
```
It states that the non-Send `x` might be used across the await; however, this is not possible, as it has been dropped.
Repository: puppeteer
Issue: [Feature]: Reducing dependencies
Labels: feature

### Feature description

In the `@puppeteer/browsers` package, there are some dependencies for unpacking archive files: `extract-zip` for `.zip`, `tar-fs` for `.tar`, and `unbzip2-stream` for `.bz2`.

https://github.com/puppeteer/puppeteer/blob/bbf75db85352e245bfc1ee59b5ef06b1eb3cf18b/packages/browsers/src/fileUtil.ts#L70-L71

However, when uncompressing a '.xz' file, it seems to call the OS's native command instead of relying on node_modules dependencies.

If so, wouldn't it be possible to do the same in other formats?

I have a concern about the licensing of the `unbzip2-stream` package. https://github.com/regular/unbzip2-stream/issues/41

And from the perspective of someone who only uses `puppeteer-core` to manipulate Chrome that is already installed, the dependencies on unpacking is useless, so the fewer dependencies the better.
Repository: ant-design
Issue: Menu component in dark mode makes selected parent item background the same color as its text
Labels: 🐛 Bug

### Reproduction link

[https://ant.design/~demos/menu-demo-horizontal-dark](https://ant.design/~demos/menu-demo-horizontal-dark)

### Steps to reproduce

Select a sub-item from the menu. See that the selected parent item background is the same as the text color.

### What is expected?

Text color should be contrasting in dark-mode

### What is actually happening?

Text color is the same as background, making it unreadable.

| Environment | Info |
| --- | --- |
| antd | 5.23.2 |
| React | 18.3.1 |
| System | macOS Ventura 13.2.1 |
| Browser | Chrome 131.0.6778.265 |

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: godot
Issue: MeshTexture does not render correctly on GPUparticles2D, CPUparticles2D or Polygon2D
Labels: enhancement,discussion,topic:2d

### Tested versions

- Reproducible in the 4.4 beta.
- Reproducible in 4.1.1 stable. 

Honestly i doubt it ever worked given its relatively niche so its feasible it was never brought up ( seems to be the case from an issue search) 

### System information

Godot v4.4.beta.mono (d004aed08) - Pop!_OS 22.04 LTS on X11 - X11 display driver, Multi-window, 1 monitor - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4060 Laptop GPU - 12th Gen Intel(R) Core(TM) i7-12650H (16 threads)  (this is the branch from this PR : https://github.com/godotengine/godot/pull/102028 but the issues are present on other versions too

### Issue description

The MeshTexture 2D doesn't display on most the aforementioned nodes. There may be good reasons for this internally but if so it shouldn't show up in the dropdowns imo, or at least throw some sort of error upon attempted assignment

### Steps to reproduce

Create a one of the aforementioned nodes, add a MeshTexture to it with it's corresponding mesh and texture. You will be greeted by a blank canvas,

I highly recommend anyone testing this issue test it on https://github.com/godotengine/godot/pull/102028 since meshtexture has a plethora of other bugs previous to that that will harm evaluation of this one potentially



### Minimal reproduction project (MRP)

[MeshParticlesPolygonTest.zip](https://github.com/user-attachments/files/18547252/MeshParticlesPolygonTest.zip)
Repository: vscode
Issue: Run code button is missing
Labels: info-needed


Type: <b>Feature Request</b>

Run code  button is missing from top right

VS Code version: Code 1.96.0 (138f619c86f1199955d53b4166bef66ef252935c, 2024-12-11T02:29:09.626Z)
OS version: Windows_NT x64 10.0.22621
Modes:


<!-- generated by issue reporter -->
Repository: vscode
Issue: paste option is disable
Labels: info-needed


Type: <b>Bug</b>

i cant able to paste my code 

VS Code version: Code - Insiders 1.97.0-insider (f5782f528629d4200a964cc652055a4da43a7eb1, 2025-01-24T05:04:36.365Z)
OS version: Windows_NT x64 10.0.22631
Modes:

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

|Item|Value|
|---|---|
|CPUs|12th Gen Intel(R) Core(TM) i5-12450H (12 x 2496)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: enabled_on<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>skia_graphite: disabled_off<br>video_decode: enabled<br>video_encode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: enabled<br>webnn: disabled_off|
|Load (avg)|undefined|
|Memory (System)|15.63GB (1.98GB free)|
|Process Argv|--crash-reporter-id 97cbdd43-7eb8-488a-ada8-910ba7d28e20|
|Screen Reader|no|
|VM|0%|
</details><details><summary>Extensions (35)</summary>

Extension|Author (truncated)|Version
---|---|---
react-hooks-snippets|AlD|1.2.0
vscode-tailwindcss|bra|0.14.1
npm-intellisense|chr|1.4.5
postcss|css|1.0.9
c-cpp-compile-run|dan|1.0.60
vscode-eslint|dba|3.0.10
es7-react-js-snippets|dsz|4.4.3
prettier-vscode|esb|11.0.0
code-runner|for|0.12.2
codespaces|Git|1.17.3
copilot|Git|1.259.1335
copilot-chat|Git|0.24.2025012402
vsc-python-indent|Kev|1.19.0
vscode-docker|ms-|1.29.4
debugpy|ms-|2024.15.2025012301
python|ms-|2024.23.2025012401
vscode-pylance|ms-|2025.1.101
jupyter|ms-|2025.1.2025012301
jupyter-hub|ms-|2024.10.1002831100
jupyter-keymap|ms-|1.1.2
jupyter-renderers|ms-|1.0.2025011401
vscode-jupyter-cell-tags|ms-|0.1.9
vscode-jupyter-powertoys|ms-|0.1.1
vscode-jupyter-slideshow|ms-|0.1.6
cmake-tools|ms-|1.19.52
cpptools|ms-|1.23.4
cpptools-extension-pack|ms-|1.3.0
remote-explorer|ms-|0.4.3
remote-server|ms-|1.5.2
vscode-speech|ms-|0.12.1
postman-for-vscode|Pos|1.6.1
LiveServer|rit|5.7.9
markdown-preview-enhanced|shd|0.8.15
cmake|twx|0.0.17
tailwind-snippets|Zar|1.0.2

(1 theme extensions excluded)

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

```
vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
vsc_aacf:30263846
pythonvspyt551:31179976
vscod805cf:30301675
vsaa593cf:30376535
py29gd2263:31024238
c4g48928:30535728
vscrp:30624060
962ge761:30841072
pythonnoceb:30776497
dsvsc014:30777825
dsvsc015:30821418
pythonmypyd1:30859725
h48ei257:31000450
pythontbext0:30879054
cppperfnew:30980852
pythonait:30973460
dvdeprecation:31040973
dwnewjupyter:31046869
nativerepl1:31134653
pythonrstrctxt:31093868
nativeloc1:31118317
cf971741:31144450
e80f6927:31120813
iacca1:31150324
notype1:31143044
dwcopilot:31158714
h409b430:31177054
c3hdf307:31184662
6074i472:31201624
dwoutputs:31217127
6e63a538:31218797
9064b325:31222308
copilot_t_ci:31222730
ecdi0152:31224757

```

</details>

<!-- generated by issue reporter -->
Repository: ollama
Issue: Error: "not authorized to push"
Labels: bug

### What is the issue?

Hi,

At first i have pull a model using ollama (ollama pull qwen:0.5b) then i wanted to push this model and using this command ```ollama push qwen:0.5b``` but i got this error:

pushing fad2a06e4cc7... 100% ▕█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████▏ 394 MB                         
pushing 41c2cf8c272f... 100% ▕█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████▏ 7.3 KB                         
pushing 1da0581fd4ce... 100% ▕█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████▏  130 B                         
pushing f02dd72bb242... 100% ▕█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████▏   59 B                         
pushing ea0a531a015b... 100% ▕█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████▏  485 B                         
pushing manifest 
Error: you are not authorized to push to this namespace, create the model under a namespace you own


is there anyone that have encountered with this issue?!

### OS

_No response_

### GPU

_No response_

### CPU

_No response_

### Ollama version

_No response_
Repository: rust
Issue: Confusing error message when returning impl Trait where the concrete type contains itself.
Labels: A-diagnostics,T-compiler

### Code

```Rust
#[derive(Debug)]
enum MyTreeNode {
    Leaf,
    VecNode(Vec<Self>),
}

impl MyTreeNode {
    pub fn iter(&self) -> impl Iterator<Item = &Self> + '_ {
        [self]
            .into_iter()
            .chain(self.nonrecursive_iter().flat_map(|e| e.iter()))
    }

    fn nonrecursive_iter(&self) -> Box<dyn Iterator<Item = &Self> + '_> {
        match self {
            Self::Leaf => Box::new([].into_iter()),
            Self::VecNode(v) => Box::new(v.iter()),
        }
    }
}

fn main() {
    let tree = MyTreeNode::VecNode(vec![
        MyTreeNode::Leaf,
        MyTreeNode::VecNode(vec![MyTreeNode::Leaf, MyTreeNode::Leaf]),
    ]);

    for node in tree.iter() {
        dbg!(node);
    }
}
```

### Current output

```Shell
Compiling playground v0.0.1 (/playground)
error: concrete type differs from previous defining opaque type use
  --> src/main.rs:9:9
   |
9  | /         [self]
10 | |             .into_iter()
11 | |             .chain(self.nonrecursive_iter().flat_map(|e| e.iter()))
   | |                                                                   ^
   | |                                                                   |
   | |___________________________________________________________________expected `std::iter::Chain<std::array::IntoIter<&MyTreeNode, 1>, FlatMap<Box<dyn Iterator<Item = &MyTreeNode>>, impl Iterator<Item = &MyTreeNode> + '_, {closure@src/main.rs:11:54: 11:57}>>`, got `impl Iterator<Item = &MyTreeNode> + '_`
   |                                                                     this expression supplies two conflicting concrete types for the same opaque type

error: could not compile `playground` (bin "playground") due to 1 previous error
```

### Desired output

```Shell
```

### Rationale and extra context

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

I believe the issue here is not that the expression returns two different types, but that it returns a single recursive type. Changing the `iter()` function signature to return a boxed iterator makes the code compile. If I'm right, then I think some wording about boxing the output of recursive function calls makes sense (similar to the message you see if you recurse async function calls).

### Other cases

```Rust

```

### Rust Version

```Shell
rustc 1.84.0 (9fc6b4312 2025-01-07)
binary: rustc
commit-hash: 9fc6b43126469e3858e2fe86cafb4f0fd5068869
commit-date: 2025-01-07
host: aarch64-apple-darwin
release: 1.84.0
LLVM version: 19.1.5
```

### Anything else?

_No response_
Repository: next.js
Issue: Unexpected Rendering Behavior When Using a 'pages' Folder Outside the App Directory in App Router
Labels: Navigation

### Link to the code that reproduces this issue

https://github.com/eteen12/Isreal

### To Reproduce

## To reproduce

1. Add a pages directory containing components into the project ( in this example a footer )

![Image](https://github.com/user-attachments/assets/e614b191-a5eb-450e-a85d-62c13142c7c0)

2. Add the component to the root layout or include it in the page.js` file as the main renderer for the homepage.

```export default function RootLayout({ children }) {
  return (
    <html lang="en">
      <body
        className={`${geistSans.variable} ${geistMono.variable} antialiased`}
      >
        {children}
        <Footer />
      </body>
    </html>
  );
}
```
3. Run the project locally using localhost, then navigate to /footer (or the corresponding route for your component).

### Current vs. Expected behavior

## Current behavior

When using the App Router, placing a file or folder named pages in the root of the project causes unexpected behavior. The components inside this pages folder will render when navigating to their corresponding component names, or in this example case /footer. 

![Image](https://github.com/user-attachments/assets/6883b388-7057-4915-b1e0-604522a4180f)

## Expected behavior

When using the App Router, the Pages Router should be completely removed and should no longer be referenced for rendering. The behavior should be similar to using a components folder for placing components, where the folder cannot render individual pages. The 'pages' folder should not be treated as a route.



### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #52-Ubuntu SMP PREEMPT_DYNAMIC Thu Dec  5 13:09:44 UTC 2024
  Available memory (MB): 15929
  Available CPU cores: 12
Binaries:
  Node: 22.12.0
  npm: 10.9.0
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 15.1.4 // There is a newer version (15.1.6) available, upgrade recommended! 
  eslint-config-next: 15.1.4
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.7.3
Next.js Config:
  output: export
```

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

Navigation

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

next dev (local), next build (local), Other (Deployed)

### Additional context

I understand that naming a components folder 'pages' is unconventional, but this was for a micro meme site I made, and I thought I’d report the issue.

It is available locally and in the cloud flare pages environment, when the site was indexed I noticed that so were the pages component routes.
Repository: ui
Issue: [bug]: Doesn't select dates using calendar component
Labels: bug

### Describe the bug

there is a css property pointer-event:none that's why we could not select any date

### Affected component/components

Doesnot select date

### How to reproduce

remove the pointer-event:none property

### Codesandbox/StackBlitz link

_No response_

### Logs

```bash

```

### System Info

```bash
Browser
```

### Before submitting

- [x] I've made research efforts and searched the documentation
- [x] I've searched for existing issues
Repository: PowerToys
Issue: Add a feature to prevent accidental pointer movement during mouse clicks with adjustable offset for intentional dragging
Labels: Needs-Triage

### Description of the new feature / enhancement

I have a computer mouse that's very sensitive to movement, and I want to keep that sensitivity. The problem is that when I click the left button, the mouse sometimes slips slightly, resulting in accidental dragging.  

I’d like a feature that does something simple: when the left button is pressed, the computer's mouse pointer shouldn’t move, even if I physically move the mouse slightly by mistake (due to slipping).  

Since there can be legitimate cases of dragging a file or something similar, I suggest having an offset—if small mouse movements are detected while the button is pressed, they should be ignored, and the pointer won’t move.  

However, if a large movement is detected, it’s likely intentional, so it shouldn’t be ignored. This way, the feature would block most cases of accidental pointer slipping while still allowing legitimate actions like dragging a file.

### Scenario when this would be used?

I wrote:

> The problem is that when I click the left button, the mouse sometimes slips slightly, resulting in accidental dragging.  

This should handle this issue


### Supporting information

I can develop it myself. I know that it is possible to develop because I am very expert in Win32 API.
But this is not the kind of things that I ever going to spent time myself.
Repository: vscode
Issue: Display Image Previews in Path Autocomplete
Labels: feature-request,javascript

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

It would be incredibly helpful if image previews could be displayed alongside their file paths in the autocomplete suggestions when navigating through image paths.
This feature would improve the developer experience by allowing users to visually identify images without needing to open or hover over the files. It would be particularly useful for projects that involve managing many image assets, such as web development, game development, or content-heavy applications.
Thank you for considering this enhancement!

<img width="955" alt="Image" src="https://github.com/user-attachments/assets/3101785a-33e9-401b-9d2f-e9ca9f8482ce" />

<!-- Describe the feature you'd like. -->
Repository: electron
Issue: /dev/shm fills up when using net.request
Labels: platform/linux,bug :beetle:,component/net,memory leak,34-x-y,35-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

34.0.1

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

Ubuntu, Other Linux

### Operating System Version

Ubuntu 6.8.0-51

### What arch are you using?

x64

### Last Known Working Electron version

Unknown

### Expected Behavior

Memory usage to remain normal

### Actual Behavior

I was using `net.request` to perform an availability check, this appears to run normally on MacOS and Windows, however on Linux when using the default mechanism `/dev/shm`, it continually fills up. Using the flag `app.commandLine.appendSwitch('disable-dev-shm-usage', true);` appears to resolve it (though is just pushing the cache to disk). 

I found a reference to this [here](https://github.com/electron/electron/issues/40711) but it seems it was closed. I have resolved it by using a different module but just for your awareness. 

### Testcase Gist URL

_No response_

### Additional Information

_No response_
Repository: godot
Issue: Navigation map synchronization error
Labels: needs testing,topic:navigation

### Tested versions

- Reproductible with Godot 4.3 and all 4.4 rc/beta versions

### System information

macOS 15.2 - Apple M3 PRO

### Issue description

I'm using navigation on a 2D game
When baking navigation and launching game, error log produces the following error message but navigation agents work correctly
```
E 0:00:01:0730   _build_step_find_edge_connection_pairs: Navigation map synchronization error. Attempted to merge a navigation mesh polygon edge with another already-merged edge. This is usually caused by crossing edges, overlapping polygons, or a mismatch of the NavigationMesh / NavigationPolygon baked 'cell_size' and navigation map 'cell_size'. If you're certain none of above is the case, change 'navigation/3d/merge_rasterizer_cell_scale' to 0.001.
  <C++ Source>   modules/navigation/3d/nav_map_builder_3d.cpp:151 @ _build_step_find_edge_connection_pairs()
```

![Image](https://github.com/user-attachments/assets/0fb22885-3da2-4242-8ed9-d867abcb8622)

The error disappears if I remove the big tree alone on the map.
Trees are on a dedicated tilemaplayer
 It seems the collision shape of some tileset tiles influence the error (the small trees do not trigger the error)

What I checked:
- navigation server polygon cell size = 1, same value as NavigationServer2D.map_get_cell_size(navigation_agent.get_navigation_map())
- enable/disable "Use Edge Connections"
- error code refers to method void NavMapBuilder3D::_build_step_find_edge_connection_pairs on GitHub related to 3D (?)

I did not find any issue or help somewhere concerning this error.

### Steps to reproduce

I cannot give more information

### Minimal reproduction project (MRP)

I don't have a minimal project, I don't know if the error is related to my game (I guess so, but I have no clue where to look after all the tests I did)