sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Incorrect TerminalShellExecution exit code
Labels: bug,help wanted,terminal-shell-bash

<!-- ⚠️⚠️ 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.94.0
- OS Version: macOS Sonoma 14.4

Steps to Reproduce:

1. Listen for `onDidEndTerminalShellExecution` events
2. Run a command that returns some exit code
3. Type the same command and interrupt with ^C (i.e. interrupt without actually running the command)
4. The exit code reported by the `TerminalShellExecution` event for the second execution (expected to be `undefined` since the command didn't actually run) will be the same as the previous command's exit code

For example:
```bash
$ echo test^C
-> exit code undefined
$ echo test
-> exit code 0
$ echo test^C
-> exit code 0
$ echo test^C
-> exit code 0
$ echo not test^C
-> exit code undefined
$ echo test^C
-> exit code undefined
```

From a quick look, this seems like caused by this code (marked as a hack): https://github.com/microsoft/vscode/blob/3b30f94f4f129e67be9b6c677aac582923da1fab/src/vs/platform/terminal/common/capabilities/commandDetectionCapability.ts#L360-L370
Repository: go
Issue: runtime:cpu1: TestPreemptionAfterSyscall/1ms failures
Labels: help wanted,NeedsInvestigation,compiler/runtime

```
#!watchflakes
default <- pkg == "runtime:cpu1" && test == "TestPreemptionAfterSyscall/1ms"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8726340078513899489)):

    === RUN   TestPreemptionAfterSyscall/1ms
        proc_test.go:1082: timeout exceeded: 5.044309084s (5s)
    --- FAIL: TestPreemptionAfterSyscall/1ms (5.10s)


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: go
Issue: proposal: spec: permit conversion of []A to []B if A and B have same underlying type modulo struct tags
Labels: LanguageChange,Proposal,LanguageChangeReview,LanguageProposal

**Background:** It is not uncommon to need to convert a value of slice type []A to type []B, where A and B have the same representation (e.g. string). Unfortunately, one must allocate a copy.

**Proposal:** We propose to relax the restrictions so that, given `var ( a A; aa []A; b B; bb []B)`, the conversion `([]B)(aa)` is legal so long as ~~both `B(a)` and `A(b)` are legal~~ A and B have the same underlying type, ignoring struct tags. The result would be a slice of the same len, cap, and pointer, but a different type. In other words, the operation creates an alias, it does not allocate an array.

The requirement for the ~~mutual assignability~~ same underlying type is that if aa aliases bb, then assigning to aa[0] and reading from bb[0] effects a conversion from A to B, and vice versa. Therefore both conversions had better be legal. Consequently, the two types must have the same memory layout (among other requirements).

[Edited: I mistakenly  started with "mutually convertible" but this is not sufficient for e.g. A=float32 B=float64.]

Prior art:
- https://github.com/golang/go/issues/3756 - closed because it allowed []X->[]Y if X assignable to Y (which may change repr + allocate)
- https://github.com/golang/go/issues/19778 - similar but requires "same memory layout", which is not a spec concept
- https://github.com/golang/go/issues/29864 - closed by fiat

Loosely related:
- https://github.com/golang/go/issues/64742: generic slice conversion, requires a func(X)Y operator though.
- https://github.com/golang/go/issues/15209: generalize append/copy to permit assignment conversions

@ianlancetaylor @griesemer
Repository: godot
Issue: GDScript completion eats the word the caret is on
Labels: discussion,topic:editor,usability

### Tested versions

v4.4.dev7.official [46c8f8c5c]

### System information

windows 11

### Issue description

I can't find if this was introduced willingly, but I find it annoying, maybe because of habit.

in recent dev builds, autocompletion now erases the word the caret is on:

|4.4dev7|4.3|
|-|-|
|<video src="https://github.com/user-attachments/assets/50941d50-923c-4bc3-a076-8fadf9d16ada"></video>|<video src="https://github.com/user-attachments/assets/af9d47b7-b65a-4618-8879-fcccbc183e67"></video>|

Is that a bug?

### Steps to reproduce

- place the caret before a word
- begin typing
- select an autocompletion

### Minimal reproduction project (MRP)

any
Repository: kubernetes
Issue: [FG:InPlacePodVerticalScaling] Inconsistency between scheduler & kubelet admission logic
Labels: priority/important-soon,sig/node,triage/accepted

The scheduler uses `max(spec...resources, status...resources)` to determine the resources requested by a pod, but when the Kubelet is making internal fit decisions it just uses the allocated resources.

In most cases, disagreement between these two approaches would be due to a pending upsize, where the spec...resources are higher than the allocated resources (desired > allocated == actual). This case is working as intended: the scheduler should not schedule over a pending resize, but the Kubelet needs to be able to admit resizes when there are 2 competing resizes.

This is only problematic if there is a case where the scheduler thinks there are _more_ available resources than the Kubelet does, which could lead to a pod being rejected with `OutOf{CPU,Memory}` . In other words, if `max(spec...resources, status...resources) < allocated resources`. This can only happen if both of the following are true:
1. There is a pending (or deferred) downsize (spec...resources < allocated)
2. There is an in-progress upsize (actual resources < allocated)

**Repro steps:**
This repro hits the above conditions for CPU requests, and manipulates memory requests & limits to make the condition persistent.

1. Create a pod with memory & cpu requests & limits
2. In a single resize request, shrink the memory limit below usage, and increase the CPU request
    - Setting the memory limit below the usage will cause the resize to be stuck in progress, without the memory or CPU changes having been actuated.
    - Allocated CPU requests are now higher than the actual CPU requests (shares)
3. In a single resize request, shrink the CPU request back to the original amount, and increase memory requests & limits to more than the available memory (but below the allocatable capacity).
    - The resize will be deferred since there is insufficient available memory for the request
    - The desired CPU is now below the allocated amount
    - For CPU requests, desired == actual < allocated
4. Create a burstable pod with a CPU request, such that the CPU request is `allocatable cpu - sum(desired cpu)`
    - The scheduler will see this pod as fitting, but the kubelet will reject it with OutOfCPU

Moving the memory usage > limit check to allocation time (option 3 in [Handling Memory Limit Decreases for In-Place Pod Resize](https://docs.google.com/document/d/1cEFLXKwNOSNLAkzyhoJUgkBW0OiX-9bXB_aJV7OAypw/edit?tab=t.0#heading=h.y6xkh6jc1iat)) will mitigate this by making a persistent in-progress resize (step 2 above) less likely, but it doesn't entirely eliminate the issue.

/sig node
/priority important-soon
Repository: go
Issue: cmd/compile: ICE on slice of array pointer returned by a generic function
Labels: NeedsInvestigation,compiler/runtime,BugReport

### Go version

go version go1.23.0 darwin/arm64

### Output of `go env` in your module/workspace:

```shell
GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/mcyoung/Library/Caches/go-build'
GOENV='/Users/mcyoung/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/mcyoung/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/mcyoung/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.23.0/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.23.0/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.23.0'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/mcyoung/Library/Application Support/go/telemetry'
GCCGO='gccgo'
GOARM64='v8.0'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/Users/mcyoung/code/protocompile/go.mod'
GOWORK='/Users/mcyoung/code/protocompile/go.work'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/5l/2_ns6hbx1gj92vv9pkrl_jdc0000gn/T/go-build656695524=/tmp/go-build -gno-record-gcc-switches -fno-common'
```


### What did you do?

The following program crashes the compiler:

```go
package x

func F[T int32]() {
	_ = G[*[0]T]()[:]
}

func G[T any]() (v T) {
	return
}

var _ = F[int32]
```

I have not been able to reduce this program further: everything, except the body of `G`, is essential to triggering the bug. `F` must be stenciled, G must return a generic type, not `*T` or `*[0]T`, and the type constraint on `F[T]` seems to be irrelevant.

### What did you see happen?

ICE.

```go
./prog.go:3:6: internal compiler error: 'F[int32]': bad ptr to array in slice go.shape.*uint8


Please file a bug report including a short program that triggers the error.
https://go.dev/issue/new
```

### What did you expect to see?

Not an ICE.
Repository: godot
Issue: Embedded Game can freeze Editor
Labels: bug,topic:editor

### Tested versions

- Reproducible in Godot v4.4.dev (a65954894) master, since https://github.com/godotengine/godot/pull/99010

### System information

 Windows 11 (build 22631) - Multi-window, 1 monitor - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2070 (NVIDIA; 32.0.15.6614) - Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz (12 threads)

### Issue description

When the game is embedded the editor process is tied to the game process, so whenever the game is frozen the editor is as well.
If the game calls `OS.delay_msec(2000)` the editor cannot be interacted with during that time.
If the game gets stuck in an infinite loop the editor will be completely frozen.

It was known that this happens on startup, but it couldn't really be fixed, see https://github.com/godotengine/godot/pull/99010#issuecomment-2507979072

### Steps to reproduce

1. Make sure "Embed Game on Next Play" is checked in the game editor.
2. Add the following code, or any code that will take a while to process:
```gdscript
func _ready() -> void:
	while true:
		pass
```
3. Run the game.
4. The Editor is unresponsive.

### Minimal reproduction project (MRP)

N/A
Repository: next.js
Issue: `cacheLife` with `revalidate` < 1 causes error in production only
Labels: dynamicIO

### Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/wonderful-heyrovsky-r4d52k

### To Reproduce

1. Visit the reproduction app.
2. In the app preview (dev mode), notice everything is working (`/` page content is "OK").
3. Build the app (e.g. `pnpm run build`), and notice there are no errors.
4. Run the app in production mode (e.g. `pnpm run start`), visit `/`, and see a 500 error:
    > Error: Invalid revalidate configuration provided: 0.999 < 1

### Current vs. Expected behavior

Current behavior: an error is thrown in production only.

Expected behavior: in my opinion, the error check should be changed to `< 0`, and should be enforced at least during build time, if not also in dev mode.


### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
  Available memory (MB): 4102
  Available CPU cores: 2
Binaries:
  Node: 20.9.0
  npm: 9.8.1
  Yarn: 1.22.19
  pnpm: 8.10.2
Relevant Packages:
  next: 15.2.0-canary.1 // Latest available version is detected (15.2.0-canary.1).
  eslint-config-next: N/A
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.3.3
Next.js Config:
  output: N/A
```


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

dynamicIO

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

next dev (local), next build (local), next start (local)

### Additional context

_No response_
Repository: go
Issue: runtime: GODEBUG=profstackdepth=N not usable with //go:debug
Labels: NeedsDecision,compiler/runtime,BugReport

Go 1.23 increased the default profiling stack depth from 32 to 128 (https://go.dev/cl/572396). It also introduced `GODEBUG=profstackdepth=32` as a way to revert back to the old default (https://go.dev/cl/581917).

However, that new GODEBUG doesn't appear in the `internal/godebugs` [table](https://cs.opensource.google/go/go/+/master:src/internal/godebugs/table.go;bpv=1), which means it is not eligible for use in `go.mod` `godebug` blocks or `//go:debug` directives (https://go.dev/doc/godebug).

Given that the main purpose of this GODEBUG is for compatibility, it seems like it should be eligible for use there, and perhaps this should be backported to 1.23.

This came up in https://github.com/golang/go/issues/69590#issuecomment-2578362721, where a user would like the old behavior.

One thing that is a bit unclear to me: I think if we add this as an "official" compatibility GODEBUG, then we will tie it to the version in `go.mod`. i.e., modules with `go 1.22.0` will use `profstackdepth=32`, even if built with 1.23. They must set `go 1.23.0` to get the new behavior. That is probably the right thing to do, but might be a bit odd to change in a minor release.

cc @felixge @golang/runtime
Repository: flutter
Issue: Do not schedule resources for PRs that haven't sign the CLA
Labels: team-infra

We should be more conservative with our resources and have some minimum bar met before scheduling infra resources.
Repository: godot
Issue: When editing custom resources in the Inspector Tab, Dictionarys do not save other custom resources
Labels: bug,topic:editor,needs testing

### Tested versions

Godot v4.3.stable

### System information

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

### Issue description

Pretty much what the title says. I've created a custom resource called World that has a dictionary of World nodes [String, WorldNode]. World node is also a resource. When I'm in the inspector trying to create new world nodes and add them to the dictionary, they disappear as soon as I close the inspector window. I tried this with an array instead, and the new WorldNodes are correctly saved to the array. I'd like to use a dictionary so I don't have to search for the ID of the world node. 

I also tested this with other data types and it seems like only dictionaries of custom resources have this problem. 

### Steps to reproduce

Create a resource, give it a dictionary data type.
Create a second custom resource. Give it some data fields.

Create a  instance of your first custom resource in the heirarcy, and in the inspector, stuff some instances of your second resource in the dictionary.

Open another node or resource in the inspector. Then go back to the custom resource.

Notice that the dictionary didn't save any of the data you entered.



### Minimal reproduction project (MRP)

[dictionarytroubleshootproject.zip](https://github.com/user-attachments/files/18353075/dictionarytroubleshootproject.zip)
Repository: react
Issue: Bug: state update from a rAF in useLayoutEffect not batched when using createRoot
Labels: Status: Unconfirmed

_Recreating #28457, which was closed due to staleness._

Maybe a weird edge case, but this caused an unexpected visual change in our app when migrating a root from `ReactDOM.render`.

React version: 18.2.0

## Steps To Reproduce

1. Define a component that has some state, and a `useLayoutEffect` that modifies the state in a `requestAnimationFrame` callback. like: 

```jsx
function App() {
  const [message, setMessage] = React.useState("Loading...");

  React.useLayoutEffect(() => {
    requestAnimationFrame(() => {
      setMessage("Ready");
    });
  });
  return <p>{message}</p>;
}
```
2. Mount the component using `ReactDOM.render`, and you will never observe the component with its initial state ("Loading..."). Only the updated state ("Ready").
3. Mount the component with `createRoot` and `root.render`, and you will observe the component render twice. Once with the initial state ("Loading..."), then with the updated state ("Ready").

<!--
  Your bug will get fixed much faster if we can run your code and it doesn't
  have dependencies other than React. Issues without reproduction steps or
  code examples may be immediately closed as not actionable.
-->

Link to code example: https://codepen.io/mxmul/pen/abMexLe

[react-batching.webm](https://github.com/facebook/react/assets/3022244/5a1e3238-5b30-4b74-b796-01024dae07b5)

## The current behavior

Two renders - once with the initial state, and a second with the updated state.

## The expected behavior

A single render with the updated state. This seems to be the behavior before React 18.
Repository: ui
Issue: [bug]: when sidebar is collapsible icon view, SidebarGroupLabel flickers
Labels: bug

### Describe the bug

when the Sidebar component is set to collapsible = icon, the group label flickers

```
<Sidebar collapsible="icon">
      <SidebarContent>
        <SidebarGroup>
          <SidebarGroupLabel>On Point Mobile Bartending</SidebarGroupLabel>
          <SidebarGroupContent></SidebarGroupContent>
        </SidebarGroup>
      </SidebarContent>
      <SidebarFooter>
        <UserButton showName />
      </SidebarFooter>
</Sidebar>

### Affected component/components

Sidebar

### How to reproduce

1.  add a sidebar
2. set collapsible to icon
3. add a SidebarGroup with a SidebarGroupLabel
Notice the label flickers

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
Nextjs 15
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: vscode
Issue: editor tab decoration/hover info is not discoverable for screen reader users
Labels: feature-request,accessibility

On hover of an editor tab, one can learn information about the editor, for example: `~/Repos/vscode/src/vs/workbench/contrib/chat/browser/chatEditing/chatEditingActions.ts • 3 problems in this file • Modified`

It appears this info is included on the tab's aria-label but is never read by the screen reader as the editor gets focus.

<img width="911" alt="Image" src="https://github.com/user-attachments/assets/cd333c0e-1ce8-45b9-bf98-6a72a1916a4b" />

I believe including this in the editor's aria label would be annoying and too verbose. We should make this information readable/triggerable. I'm wondering about a new `window.title` variable as I know screen reader users focus the window title for other info.

Thoughts @jooyoungseo and @rperez030?

I realized this because for files that have copilot edits, we include the following: `~/Repos/vscode-extension-samples/terminal-sample/src/extension.ts • Pending changes from chat • 6 problems in this file` but it's not screen reader discoverable at the moment.

cc @joyceerhl, @jrieken, @isidorn
Repository: godot
Issue: Race Condition in NavigationServer3D
Labels: bug,topic:core,topic:navigation

### Tested versions

- Reproducible in: 4.3-stable, 4.4-dev1.
- Not reproducible in: 4.2-stable, 4.4-dev2 and higher.

### System information

Godot v4.3.stable - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4070 Ti (NVIDIA; 32.0.15.6636) - AMD Ryzen 7 7800X3D 8-Core Processor (16 Threads)

### Issue description

`NavigationServer3D` contains a data race in all methods that query navigation map. The result is a complete freeze of the **main** thread. Might be related to [this](https://github.com/godotengine/godot/pull/90804).
Seems to be fixed in 4.4-dev2. Maybe we want to port it to 4.3?

`NavigationServer3D.set_active(false` seems to fix the issue as well.

### Steps to reproduce

Just run the minimal project attached, it will freeze instantly.

But overall idea is to run for example `NavigationServer3D.map_get_closest_point` with any params enough times to trigger the race condition **on a separate thread**.

### Minimal reproduction project (MRP)

Here is the main script. You can attach it to a Node3D scene with some dummy navigation region. Minimal project [attached](https://github.com/user-attachments/files/18353618/test.zip).

```gdscript
extends Node3D

var _task_id: int

var _map: RID
var _thread := Thread.new()

func _ready() -> void:
	_map = await NavigationServer3D.map_changed
	_thread.start(_test)

func _test() -> void:
	while true:
		NavigationServer3D.map_get_closest_point(_map, Vector3.ZERO)

# Join the threads just because it's correct, but it doesn't make any difference.
func _exit_tree() -> void:
	_thread.wait_to_finish()
```
Repository: rust
Issue: compiletest: error emitter pretty svg tests don't normalize color differences between Windows and Unixes
Labels: A-testsuite,O-windows,A-diagnostics,T-compiler,T-bootstrap,C-bug,D-diagnostic-infra,A-compiletest

![Image](https://github.com/user-attachments/assets/9d60a301-302b-4529-8331-b9bdd185e580)
![Image](https://github.com/user-attachments/assets/d920a5db-80f8-4f50-9c85-474fa54ef5dd)

This is the svg snapshots of the same test `test/ui/error-emitter/multiline-removal-suggestion.rs` (the former is the reference Unix-blessed snapshot, the latter is generated on Windows with `//@ only-linux` removed), but I believe this fails on Windows because the exact colors chosen are different. I believe this is because there are certain cmd.exe default bright colors which are very hard to read, so we actually pick different colors on purpose.

cc @estebank for FYI: I reasoned about the failure in #134664 incorrectly, I found out today after revisiting #132752, which is a *different* bug.
Repository: go
Issue: internal/trace: TestTraceCPUProfile/Default failures
Labels: NeedsInvestigation,compiler/runtime

```
#!watchflakes
default <- pkg == "internal/trace" && test == "TestTraceCPUProfile/Default"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8726805723477811937)):

    === RUN   TestTraceCPUProfile/Default
        reader_test.go:112: unexpected error while reading the trace: inconsistent status for proc 1: old Syscall vs. new Running
        trace_test.go:627: found bad trace; dumping to test log...
        trace_test.go:638: Trace Go1.23
            EventBatch gen=1 m=28747 time=2687627497990 size=65459
            ProcStart dt=365 p=2 p_seq=1
            GoStart dt=223 g=1 g_seq=1
            HeapAlloc dt=839 heapalloc_value=4194304
            GoStop dt=301 reason_string=16 stack=8
            ProcStop dt=54
    ...
            String id=138
            	data="runtime.traceStartReadCPU.func1"
            String id=139
            	data="/home/swarming/.swarming/w/ir/x/w/goroot/src/runtime/tracecpu.go"
            String id=140
            	data="runtime.traceLocker.ProcStart"
            String id=141
            	data="runtime.acquirep"
            
    --- FAIL: TestTraceCPUProfile/Default (18.13s)


— [watchflakes](https://go.dev/wiki/Watchflakes)