sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: terminal
Issue: Sixel band with solid background color get transparent in some cases
Labels: Area-VT,Issue-Bug,Product-Terminal,In-PR

### Windows Terminal version

1.23.2611.0 (Canary)

### Windows build number

10.0.26100.1742 ARM64

### Steps to reproduce

This one is probably for @j4james 

When displaying a sixel image with solid background (`␛P1;1q"…` or default `␛Pq"…`), bands are properly created filled with the solid background color before pseudo-pixels get decoded into them, only if the band is already in the viewport.
When reaching the end of the viewport, new bands added that require scrolling or extending the buffer are created with a transparent background instead of the solid background:

![image](https://github.com/user-attachments/assets/d090ecdd-f534-4b00-8f2c-6971e973a796)
_(Solarized Light color scheme to make the background more visible, but happens with every color scheme)_

My test file has magenta as an unused color # 0, so the background is using black regardless of the VT palette, and then transparency for the bands scrolling the viewport or extending the buffer.
_Edit: Reading through #17887, I guess that's because I didn't set color # 256 and it defaulted to black_

Here's the test file: [test.zip](https://github.com/user-attachments/files/17084582/test.zip)

Is this the expected behavior to match old terminals and we need to explicitly draw all background pixels instead of relying on background fill, or is this a bug?

### Expected Behavior

Background should be reliably solid background color.

### Actual Behavior

In some cases, the background is transparent.
Repository: deno
Issue: Force kill Deno.serve http server
Labels: bug,ext/http

I am testing automatic websocket reconnection, and I've found the best way to do it is to start a real HTTP server inside the test and then close it.

Unfortunately there is only a `.shutdown()` method, which waits 30s for active websocket connections to close on their own before ending the server. I tried passing a `signal` into it too (and aborting it), but it has the same behavior as `.shutdown()`.

To work around this issue, I created a set of connections:

```ts
private connections = new Set<WebSocket>();
```

which I then manage when the socket opens and closes:

```ts
      const { response, socket } = Deno.upgradeWebSocket(req);

      socket.onopen = () => {
        this.connections.add(socket);
      };

      socket.onclose = () => {
        this.connections.delete(socket);
      };
```

finally, to close the server, I loop over the connections and call `.close()` on them, then I call `.shutdown()`:

```ts
  async close(): Promise<void> {
    this.connections.forEach((conn) => conn.close());
    this.connections = new Set<WebSocket>();

    await this.server.shutdown();
  }
```

This workaround is working good for me, but ideally there would be a `server.kill()` or `server.shutdown(force = true)` method that would do basically the same thing sigint does to the server.
Repository: rust
Issue: `bind` may incorrectly create a dual-stack socket on some platforms
Labels: C-bug,T-libs


`UdpSocket::bind` and `TcpListener::bind` can on some platforms incorrectly create a dual-stack socket. It seems very unlikely that these are intended to create dual-stack sockets as the API and documentation make no mention of it. There's also no alternate API that allow for the creation of IPv6 wildcard sockets. This means that if these API were intended to create dual-stack sockets, the standard library would be missing essential IPv6 functionality.

Additional there are good reasons to not have or add an API for dual-stack sockets in the standard library:
- Dual-stack sockets are not portable.
- They are unneccesary as you can use multiple sockets instead.
- They are limited in functionality as you cannot bind to a IPv4 / IPv6 pair.

Users not needing portability and wanting dual-stack sockets, may want to use a 3rd party crate (for example `socket2`) to create dual-stack sockets.

This bug have some rather bad consequences:
- This means that IPv4 may unexpectedly be accessible over the network which can be a security vulnerability. This is particularly bad if a  user tests on a correctly behaving platform, but deploys on another.
- It's not possible to create portable IPv6 wildcard servers with `std`.
- It's not possible to create portable dual-stack wildcard servers with `std`.

This affects (at least):
- Linux
- macOS

Not affected:
- Windows
- OpenBSD (does not support dual-stack sockets)
Repository: vscode
Issue: Feature request: setting to wrap absolute path Copy Path command with quotes
Labels: help wanted,feature-request,terminal-input

<!-- ⚠️⚠️ 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. -->

<!-- Describe the feature you'd like. -->

I use VSCode on Windows with git bash as the terminal. A problem I have is when I want to `cd` into a folder: I right click a folder, do Copy Path, focus the terminal and do `cd` and paste the folder. I end up with this:

```bash
$ cd C:\Github\forks\kit\packages\kit\test\apps\basics
bash: cd: C:Githubforkskitpackageskittestappsbasics: No such file or directory
```

The shell eats the `\` because they are not escaped and the path isn't quoted.

This feature request is for a setting to optionally wrap the path with single or double quotes:

`Explorer: Wrap absolute Copy Path file path with quotes`
`"No quotes (default)"`
`"Single"`
`"Double"`

Right now Copy Path gives `C:\Github\forks\kit\packages\kit\test\apps\basics` which would still be the default.

`Single` would give `'C:\Github\forks\kit\packages\kit\test\apps\basics'`
`Double` would give `"C:\Github\forks\kit\packages\kit\test\apps\basics"`

This feature would make it smoother to interact with absolute paths from the Copy Path command on Windows machines/shells.
Repository: vscode
Issue: On commit: Unknown variable: --vscode-inlineChat-regionHighlight
Labels: bug,debt,notebook

I saw this when trying to commit a merge commit just now which forced me to use `--no-verify` to unblock myself.

```
src\vs\workbench\contrib\notebook\browser\media\notebookCellChat.css(294,1): Unknown variable: --vscode-inlineChat-regionHighlight
src\vs\workbench\contrib\notebook\browser\media\notebookCellChat.css(309,1): Unknown variable: --vscode-inlineChat-regionHighlight
src\vs\workbench\contrib\notebook\browser\media\notebookCellChat.css(316,1): Unknown variable: --vscode-inlineChat-regionHighlight
All valid variable names are in `build/lib/stylelint/vscode-known-variables.json`
To update that file, run `./scripts/test-documentation.sh|bat.`
```
Repository: go
Issue: x/tools/go/gcexportdata: drop experimental bundle API
Labels: Proposal,Proposal-Accepted,Tools

The [gcexportdata](https://pkg.go.dev/golang.org/x/tools/go/gcexportdata)  package has two functions, WriteBundle and ReadBundle, that have always been marked as experimental and are not used within x/tools, nor, to my knowledge, anywhere else. The only [match in GitHub](https://github.com/search?q=gcexportdata.WriteBundle&type=code) was a single call from apidiff in the ~~obsolete~~ golang/exp repo (and forks thereof), which I have since updated.

```go
package gcexportdata

func ReadBundle(in io.Reader, fset *token.FileSet, imports map[string]*types.Package) ([]*types.Package, error)
func WriteBundle(out io.Writer, fset *token.FileSet, pkgs []*types.Package) error
```

We propose to drop bundle functionality by making both functions return an error unconditionally.

Related:
- https://github.com/golang/go/issues/69491
Repository: rust
Issue: Audit usages of `std::env::*_var` in the compiler
Labels: C-cleanup,T-compiler

We have a couple instances of `env::*_var` which are now unsafe in edition 2024. They're not necessarily obviously safe, so I've left them with a `FIXME(edition_2024)` -- we should fix them eventually.

https://github.com/rust-lang/rust/blob/28364822410af31bba5c8adac19cbbfcb9b48717/compiler/rustc_llvm/build.rs#L54

https://github.com/rust-lang/rust/blob/28364822410af31bba5c8adac19cbbfcb9b48717/compiler/rustc_feature/src/tests.rs#L6
Repository: deno
Issue: Web cache API expirenation is not work?
Labels: needs investigation

Version: Deno 1.46.3

It appears that the Web Cache API expiration date cannot be set.

Example

```ts
    export const cache = await caches.open("cache");
    
    const cached = await cache.match(req.url);
    if (cached) {
      console.log(`cache hit ${req.url}`);
      return cached;
    }

    const newResponse = new Response("text", {
      headers: { ...res.headers, "Expires": new Date(Date.now() + 10 * 1000).toUTCString(), },
    });

    await cache.put(req.url, newResponse.clone());

    return newResponse;
```

The cache does not disappear over time and hits forever.

Would cli and deploy work differently?

https://deno.com/blog/deploy-cache-api#:~:text=reference%20documentation.-,Cache%20Policy,-By%20default%2C%20cached
Repository: kubernetes
Issue: Pods Not Scaling Up with HPA Despite CPU Utilization Exceeding Target
Labels: kind/bug,sig/autoscaling,needs-triage

### What happened?

I'm using the HPA to scale my pods based on CPU usage. I've set the target CPU utilization at 50%, with a stabilization window of 0. However, my pods are not scaling up, even though the current CPU usage consistently exceeds 50%. This issue persists for over 30 minutes without any scaling activity.

### What did you expect to happen?

The HPA will trigger scale up immediately  

### How can we reproduce it (as minimally and precisely as possible)?

Create an OKE cluster and follow this [guide](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)

### Anything else we need to know?

_No response_

### Kubernetes version

<details>
Server Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.2", GitCommit:"b6943c3c67cd1e3b8a1269566e755e899ed25ce2", GitTreeState:"clean", BuildDate:"2023-06-23T15:16:54Z", GoVersion:"go1.20.4 4493 X:boringcrypto", Compiler:"gc", Platform:"linux/amd64"}

Server Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.12", GitCommit:"19d5e4ee03daf5e8fb55a88b1a52d94332435e7e", GitTreeState:"clean", BuildDate:"2023-07-26T10:00:24Z", GoVersion:"go1.20.6", Compiler:"gc", Platform:"linux/amd64"}

</details>


### Cloud provider

<details>
Oracle OKE
</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>
Repository: node
Issue: Could not report code coverage for file in sourcemap
Labels: confirmed-bug,coverage,source maps,test_runner

### Version

v22.9.0

### Platform

```text
N/A
```


### Subsystem

test_runner

### What steps will reproduce the bug?

Create `index.mjs`:
```mjs
export {}
//# sourceMappingURL=index.mjs.map
```

Create `index.mjs.map`:
```mjs
{"version":3,"file":"index.mjs","sourceRoot":"","sources":["index.mjs"],"names":[],"mappings":"AAEA"}
```

Run:
```bash
node --experimental-test-coverage --test index.mjs
```

### How often does it reproduce? Is there a required condition?

Every time.

### What is the expected behavior? Why is that the expected behavior?

Coverage should be reported, or an error explaining why it wasn't is displayed.

### What do you see instead?

```
ℹ Warning: Could not report code coverage. TypeError: Cannot read properties of undefined (reading 'startOffset')
```

### Additional information

CC @nodejs/test_runner
Repository: vscode
Issue: Auto-reload local workspace extensions when a file in the extension directory gets saved
Labels: feature-request,extensions

<!-- ⚠️⚠️ 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. -->

<!-- Describe the feature you'd like. -->
I am making ample use of the VS Code local workspace extensions feature shipped in v1.89:
https://code.visualstudio.com/updates/v1_89#_local-workspace-extensions

Whenever I make a chance to the extension's source, I have to use the Developer: Reload Window command to make it update.
I think the Reload Extensions button that is in the Extensions pane whenever I install or uninstall extension would also result in the same effect, but that button's underlying action is not exposed as a command that could be found via the command palette AFAIK.

I would like to propose a built-in file save monitor (only when saving a text editor in VS Code not a general file system watcher) that would detect whether the changed file belongs to a directory or a subdirectory of any local workspace extension (`extensionPath` in the `vscode.extensions` API) and reload the extension whenever such a file was changed.

I believe something like this could be also crudely done as an extension itself `vscode.commands.executeCommand` running the `workbench.action.restartExtensionHost` command based on `vscode.workspace.onDidSaveTextDocument` with the downside that it could only reload all extensions this way, not any particular one, so I think a built-in solution would be preferred.
Repository: rust
Issue: Tracking Issue for mergeable rustdoc cross-crate info
Labels: T-rustdoc,B-unstable,B-RFC-implemented,C-tracking-issue

<!--
NOTE: For library features, please use the "Library Tracking Issue" template instead.

Thank you for creating a tracking issue! 📜 Tracking issues are for tracking a
feature from implementation to stabilisation. Make sure to include the relevant
RFC for the feature if it has one. Otherwise provide a short summary of the
feature and link any relevant PRs or issues, and remove any sections that are
not relevant to the feature.

Remember to add team labels to the tracking issue.
For a language team feature, this would e.g., be `T-lang`.
Such a feature should also be labeled with e.g., `F-my_feature`.
This label is used to associate issues (e.g., bugs and design questions) to the feature.
-->

This is a tracking issue for the RFC "Mergeable rustdoc cross-crate info" (rust-lang/rfcs#3662).

### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

### Steps
<!--
Include each step required to complete the feature. Typically this is a PR
implementing a feature, followed by a PR that stabilises the feature. However
for larger features an implementation could be broken up into multiple PRs.
-->

- [x] Implement the RFC (#129337)
- [ ] Add documentation (to Rustdoc Book) -- cc @EtomicBomb
- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide])

[stabilization-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs
[nightly-style-procedure]: https://github.com/rust-lang/style-team/blob/master/nightly-style-procedure.md 
[Style Guide]: https://github.com/rust-lang/rust/tree/master/src/doc/style-guide

### Unresolved Questions
<!--
Include any open questions that need to be answered before the feature can be
stabilised.
-->

- [ ] Consider removing `--merge=shared` and only allow it by not providing a `--merge` flag. This would allow removing the implementation of shared CCI later, once Cargo uses mergeable CCI. https://github.com/rust-lang/rfcs/pull/3662#discussion_r1735147546

### Implementation history

<!--
Include a list of all the PRs that were involved in implementing the feature.
-->

- #129337
- #128252
- #128161
Repository: godot
Issue: Tileset Terrain peering to void cells is unreliable
Labels: needs testing,topic:2d

### Tested versions

Using 4.3 stable

### System information

Godot v4.3.stable - macOS 14.6.1 - GLES3 (Compatibility) - Apple M2 Pro - Apple M2 Pro (12 Threads)

### Issue description

When using terrains, I often find that when it has to peer with a void/empty cell, the results are unpredictable / poor.

In the examples below, I will be using https://seliel-the-shaper.itch.io/spring-forest.

Here, you can see it has decided that the water is peered with the "dirt" terrain when it meets the void edge of the map.
![image](https://github.com/user-attachments/assets/823eb119-5810-4ef8-899e-f6f53dd7a727)

As you can see in this, the Deep Water is peered with the Dirt terrain:
![image](https://github.com/user-attachments/assets/395dce58-9bf0-4a49-a18f-70b52ebf2518)

Now.. Dirt is the first terrain in the set, so I can kinda see why it might "fall back" to that for a void cell?

To me, it feels like it would be more sensible to preserve the "primary" tile for that terrain; in this case full water.

### Steps to reproduce

Seem to be fairly reliable once you have two+ terrains. The edge seems to always be the "first" terrain?

### Minimal reproduction project (MRP)

I cant really produce an MRP right now with this tilset as its copyright...

There is also a chance it might be a "Meat Based Problem" and I'm using Godot incorrectly...
Repository: godot
Issue: Memory leak and crash when creating custom shapes for ShapeCast
Labels: bug,topic:physics,needs testing

### Tested versions

Reproducible in 4.3 stable and 4.2.2 stable

### System information

Godot v4.3.stable - macOS 14.6.1 - GLES3 (Compatibility) - Apple M1 Pro - Apple M1 Pro (8 Threads)

### Issue description

Attempting to create a Convex or Concave PolygonShape2D makes Godot freeze, until a memory error appears when reaching 86 GB  of memory used for Godot, which keeps going up if the app is not forced to quit. 
This doesn't occur when selecting any of the premade shapes.

The only error I found on the logs that may be related are the following:

```
ERROR: 1 RID allocations of type 'P12GodotShape2D' were leaked at exit.
USER WARNING: 1 RID of type "CanvasItem" was leaked.
   at: _free_rids (servers/rendering/renderer_canvas_cull.cpp:2483)
USER WARNING: ObjectDB instances leaked at exit (run with --verbose for details).
   at: cleanup (core/object/object.cpp:2284)
USER ERROR: 1 resources still in use at exit (run with --verbose for details).
   at: clear (core/io/resource.cpp:604)
```

### Steps to reproduce

1. Create a ShapeCast2D
2. For the Shape field, click a Convex or Concave PolygonShape2D

I tested this on an empty project and was able to reproduce just as in my other projects 

### Minimal reproduction project (MRP)

N/A
Repository: godot
Issue: 4.3 Crashes when on preferred platform = wayland + forward plus renderer + Hyprland
Labels: bug,platform:linuxbsd,topic:rendering,crash

### Tested versions

Reproducable in: Godot v4.3.stable.nixpkgs

### System information

Godot v4.3.stable (77dcf97d8) - NixOS #1-NixOS SMP PREEMPT_DYNAMIC Sun Sep 15 14:57:56 UTC 2024 - Wayland - Vulkan (Forward+) - AMD Radeon 780M (radeonsi, gfx1103_r1, LLVM 18.1.8, DRM 3.58, 6.11.0) - AMD Ryzen 7 7840U w/ Radeon  780M Graphics (16 Threads)

### Issue description

When opening a Forward+ renderer project in Godot Editor 4.3.stable on Hyprland with the editor set to prefer wayland, the editor crashes immediately without showing a window. This doesn't happen on any other render mode, or in X11. 


Here's a text file containing the output of
```bash
DEBUG_WAYLAND=1 godot4 --editor --verbose . &> error.txt
```

[error.txt](https://github.com/user-attachments/files/17087831/error.txt)

The most relevant part of the error seems to be

```
Using present mode: Mailbox
ERROR: Wayland client error code 12.
   at: _poll_events_thread (platform/linuxbsd/wayland/wayland_thread.cpp:2747)
```

https://github.com/godotengine/godot/blob/6699ae7897658e44efc3cfb2cba91c11a8f5aa6a/platform/linuxbsd/wayland/wayland_thread.cpp#L2747

### Steps to reproduce

My home manager config (contains my install of Hyprland + Godot)

https://github.com/RegularTetragon/home-manager-vael
Commit 92f9245

My NixOS config (contains general drivers, should be unrelated)

https://github.com/RegularTetragon/nixos-config
Commit 925f827

Login to Hyprland

Create a new project in compatibility mode

Editor -> Editor Settings -> Platforms -> Linuxbsd -> Prefer Wayland = true

Restart the editor and open the project again

Change the project from Compatibility to Forward+

Restart the editor and open the project again

Project crashes immediately

### Minimal reproduction project (MRP)

[test-2.zip](https://github.com/user-attachments/files/17087833/test-2.zip)
Repository: rust
Issue: Does LLVM's quirk of counting in bits matter to us?
Labels: A-LLVM,T-compiler,A-docs

### Location

In a lot of different places we document an `isize::MAX` limit on object sizes, for example, see this: https://doc.rust-lang.org/std/slice/fn.from_raw_parts.html

### Summary

So, hypothetically, we "only" can have an object countable by LLVM within 64 bits:
https://github.com/rust-lang/rust/blob/55043f067dcf7067e7c6ebccf3639af94ff57bda/compiler/rustc_abi/src/lib.rs#L340-L350

However, hypothetically, we "should" be able to use an object that is `isize::MAX` bytes. These two facts contradict each other, since that suggests we should be able to have an object that is greater than 2^61 bytes. It is hard to validate whether or not LLVM miscompiles this, though, as most computers do not deal in greater than around 56 bits of address space.

Anyone working in HPC is encouraged to let us know?

Honestly, it's not even clear what we mean by "object" here. Allocation, probably?
Repository: godot
Issue: Editor freezes, when Control node edit (show/hide)
Labels: bug,topic:editor,topic:gui

### Tested versions

tested on 4.3 stable / 4.4 dev2

### System information

Windows 10

### Issue description

Editor freeze, when i hide this nodes
![image](https://github.com/user-attachments/assets/185e1528-afe7-4344-8406-bbd0eec65f21)
in console spam -
`Object was deleted while awaiting a callback.`
P.S. finally i can stable reproduce this bug. general issue - sometimes editor freezes, when UI "layout" changes in containers (i.e. show/hide)

### Steps to reproduce

open project, then hide first "PanelContainer" then second
![image](https://github.com/user-attachments/assets/d7519ffd-6751-4030-a4eb-2852cc2a5d79)


### Minimal reproduction project (MRP)

[srl.zip](https://github.com/user-attachments/files/17088175/srl.zip)