sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: neovim
Issue: vim.snippet.expand : support nested placeholders
Labels: enhancement,snippet

### Problem

`vim.snippet.expand` does not support snippets such as `${1:$TM_FILENAME}`, `${1:${TM_FILENAME}}` and  `${1:${TM_FILENAME:placeholder}}`. (Looking at [the roadmap](https://github.com/neovim/neovim/issues/25696), I think that these should be supported under "nested placeholders.")

### Steps to reproduce

```
nvim --clean foo.txt
:lua vim.snippet.expand("$TM_FILENAME: ${1:$TM_FILENAME}")
```

This yields `foo.txt: |` (where `|` is the cursor), but it should yield `foo.txt: foo.txt` (with the second `foo.txt` selected).

```
nvim --clean foo.txt
:lua vim.snippet.expand("$TM_FILENAME: ${1:${TM_SELECTED_BASE}}")
```

This yields `foo.txt: |` (where `|` is the cursor), but it should yield `foo.txt: foo` (with `foo` selected). (This one also seems to get neovim confused about when to consider the snippet finished. There's wonky behavior with tabbing.)


```
nvim --clean
:lua vim.snippet.expand("$TM_FILENAME: ${1:${TM_FILENAME:placeholder}}")
```

This yields `: |` (where `|` is the cursor), but it should yield `: placeholder` (with `placeholder` selected). (This one has the same problem with tabbing as the second example.)


### Expected behavior

See above in the steps to reproduce. (It seemed easier to interleave the examples and expectations.)

### Neovim version (nvim -v)

0.11.0-dev-165+g054a287db

### Vim (not Nvim) behaves the same?

No such thing in vim

### Operating system/version

macOS 14.5

### Terminal name/version

Ghostty 237343f4

### $TERM environment variable

xterm-ghostty

### Installation

Build from repo
Repository: flutter
Issue: [flutter_tools] Consider using `--reporter=failures-only` in flutter tool CI tests that use package:test
Labels: P2,team-tool,triaged-tool

See title. This reporter (recently made available by https://github.com/flutter/flutter/pull/148739) might be useful to reducing noise in logs from CI tests.
Repository: ui
Issue: [bug]: No accordion animation when `value` is controlled via state
Labels: bug

### Describe the bug

When making the accordion controlled, the opening/closing animation doesn't seem to occur.

### Affected component/components

Accordion

### How to reproduce

1. Add an accordion component
2. Make the type `multiple`
3. Add state to control the `value` prop of the accordion
4. Set `value={state}` and `onValueChange={setState}`
5. Create a function to modify the value (ex. collapseAll and expandAll)
6. Add a button to trigger the function from step 5
7. Click on the button

On my end, the `accordion-up` and `accordion-down` animations are not longer taking place when making the accordion controlled via state.

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
Chrome/Arc
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: pytorch
Issue: torch.floor_divide throws floating point exception
Labels: triaged,module: NaNs and Infs,module: edge cases

### 🐛 Describe the bug

When the devisor is `-1` and `input` is a large negative integer, `torch.floor_divide` will throw a floating point exception.
```
import torch
input = torch.tensor([[-9223372036854775808]])
other = torch.tensor([-1])
torch.floor_divide(input,other)
```
This issue may be similar to my previous issue: https://github.com/pytorch/pytorch/issues/124644

### Versions

Versions of relevant libraries:
[pip3] numpy==1.26.4
[pip3] optree==0.11.0
[pip3] torch==2.3.0
[pip3] triton==2.3.0
[conda] numpy                     1.26.4                   pypi_0    pypi
[conda] optree                    0.11.0                   pypi_0    pypi
[conda] torch                     2.3.0                    pypi_0    pypi
[conda] triton                    2.3.0                    pypi_0    pypi
Repository: rust
Issue: `Vec::into_boxed_slice` no-excess guarantee regressed in 1.77.0
Labels: T-libs-api,E-help-wanted,A-docs,C-bug,A-box

#36284 asked for clarity about how to use `Box<[T]>::into_raw`. The core issue was that the documentation for `Vec::into_boxed_slice` said it reduced excess capacity in a way that was equivalent to calling `Vec::shrink_to_fit`. However, the latter makes no guarantees about there being no excess capacity afterwards. The resolution of #36284 (specifically in https://github.com/rust-lang/rust/issues/36284#issuecomment-297116448) was for `Vec::into_boxed_slice` to itself guarantee that it results in an exact allocation with no excess capacity, and to decouple it from `Vec::shrink_to_fit`. The documentation was updated to reflect this guarantee in #44960.

#120110 reintroduced the equivalence to `Vec::shrink_to_fit`, and removed the guarantee by removing this language:
```rust
    /// If `v` has excess capacity, its items will be moved into a
    /// newly-allocated buffer with exactly the right capacity.
```

I note however that the PR did not update the example, which still appears to encode the intention of the guarantee (it checks the post-shrinking capacity is exactly the length, vs the corresponding example in `Vec::shrink_to_fit` which checks the post-shrinking capacity is at least the length).

As such, it is unclear whether this guarantee regression was intentional or not. But as things currently stand, we are back in a position where `Box<[T]>::into_raw` is functionally useless.

### Version with regression

#120110 was merged during the 1.77.0 cycle.
Repository: flutter
Issue: Tool implementation doesn't handle `ParallelWaitError`
Labels: P2,c: tech-debt,team-tool,triaged-tool

The new [`Iterable<Future>.wait`](https://api.dart.dev/stable/3.4.2/dart-async/FutureIterable/wait.html) and [`Record<Future, ...>.wait`](https://api.dart.dev/stable/3.4.2/dart-async/FutureRecord2/wait.html) extensions are really great, particularly records allowing you to maintain type safety when waiting to resolve different types at once.

They can't be used across some of the Flutter tool's implementation though, as the tool's error handling doesn't account for the [`ParallelWaitError`](https://api.dart.dev/stable/3.4.2/dart-async/ParallelWaitError-class.html) awaiting them can throw.

I expect/hope these methods to eventually completely supersede `Future.wait`, so it would be good to add support to the tool's error handling.
Repository: PowerToys
Issue: PowerToys Run includes "Commands" on full filename match despite relevant plugins being disabled
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.81.1

### Installation method

GitHub, PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

PowerToys Run

### Steps to reproduce

1. Enable the PowerToys Run module
2. Uncheck all of the plugins for PowerToys run except for the "Program" plugin
3. Type in the full name of a program (i.e. "Arc", "git")
4. Observe that despite only having the "Program" plugin enabled PowerToys Run includes and prioritizes the command to run the .exe file instead of the packaged application

### ✔️ Expected Behavior

When plugins in settings are disabled, their actions should not be included in the search results.

### ❌ Actual Behavior

The command to run the .exe is found and prioritized over the packaged application.

### Other Software

_No response_
Repository: flutter
Issue: [DisplayList] Inconsistencies with how opacity peephole compatibility is tracked
Labels: engine,P3,team-engine,triaged-engine

The compatibility of a layer or DisplayList with opacity peephole optimizations is tracked in 2 separate mechanisms.

The bounds accumulator checks for overlapping primitives which interferes with opacity optimizations.
The compatibility of the current rendering attributes is checked on each rendering operation and recorded as a flag.

A couple of the rendering options in the DisplayListBuilder (drawAtlas, drawVertices, drawDisplayList, drawText*) sometimes pass along a "we can't tell if our operations overlap so we need to disable opacity optimization" but they do so through the mechanism that tracks rendering attributes rather than through the bounds accumulator which would be a more accurate assessment of their conditions. This does not appear to introduce any bugs, but these cases should be tracked consistently in case we come up with a more sophisticated way to evaluate the opacity peephole conditions in the future.
Repository: terminal
Issue: Persistence: Consider replacing concealed text with spaces
Labels: Area-Output,Product-Terminal,Issue-Task

Ideally no one should use SGR 8 (concealed text) to hide sensitive information in the output, but just to be safe we should probably not dump it into an unencrypted text file on the disk anyway.

The best option for us may be to just replace such chunks of text with a corresponding number of whitespaces.
Repository: pytorch
Issue: W0603 torch/fx/experimental/symbolic_shapes.py:1325] [1/18] RecursionError 
Labels: needs reproduction,triaged,oncall: pt2,module: dynamic shapes

### 🐛 Describe the bug

```python
in sympy.expand(Eq(Mod(256*evaluate_static_shape_1 + 512, 256*(evaluate_static_shape_0 + 1)*(evaluate_static_shape_2 + 1)), 0))
```

is there any action item for this?

### Versions

pytorch-nigthly

cc @ezyang @msaroufim @bdhirsh @anijain2305 @chauhang
Repository: ollama
Issue: Surface the embedding dimension of a model in docs/api
Labels: documentation,feature request,api

Currently, the embedding dimension isn't listed on the ollama docs or on the model card from ollama.
Repository: material-ui
Issue: [material-ui] Composing a theme with multiple `experimental_extendTheme` calls throws error
Labels: docs,support: question,package: system,customization: theme

### Steps to reproduce

Link to live example: https://codesandbox.io/p/sandbox/mui-extendtheme-chaining-bug-6j9mps

Steps:
1. create any new react project & install MUI
2. call `experimental_extendTheme` more than once, and passing in a `Theme` object for any of the calls


### Current behavior

Chaining calls to `experimental_extendTheme` results in the following error:

```
MUI: `vars` is a private field used for CSS variables support. Please use another name.
```

### Expected behavior

Should work without throwing an error. Matching `createTheme` functionality.

### Context

Chaining calls to "compose" a theme object as described in the 2nd example [here](https://mui.com/material-ui/customization/theming/#api) (but with the new `extendTheme` experimental feature instead) 

### Your environment

I just copied the codesandbox files to my machine to get these specs, not sure if that matters. Error still shows up when running it on my machine instead of codesandbox. 

 System:
    OS: macOS 14.5
  Binaries:
    Node: 20.9.0 - ~/.nvm/versions/node/v20.9.0/bin/node
    npm: 10.1.0 - ~/.nvm/versions/node/v20.9.0/bin/npm
    pnpm: 8.5.0 - /usr/local/bin/pnpm
  Browsers:
    Chrome: 125.0.6422.113
    Edge: Not Found
    Safari: 17.5
  npmPackages:
    @emotion/react: 11.11.4 => 11.11.4 
    @emotion/styled: 11.11.5 => 11.11.5 
    @mui/base:  5.0.0-beta.40 
    @mui/core-downloads-tracker:  5.15.19 
    @mui/material: 5.15.19 => 5.15.19 
    @mui/private-theming:  5.15.14 
    @mui/styled-engine:  5.15.14 
    @mui/system:  5.15.15 
    @mui/types:  7.2.14 
    @mui/utils: 5.15.14 => 5.15.14 
    @types/react: 18.2.38 => 18.2.38 
    react: 18.2.0 => 18.2.0 
    react-dom: 18.2.0 => 18.2.0 
    typescript: 4.4.4 => 4.4.4 

**Search keywords**: cssvars experimental_extendTheme extendtheme css variables experimental
Repository: vscode
Issue: SCM - Allow SCM extension to opt out of `SourceControl.statusBarCommands` also appearing in SCM views
Labels: feature-request,scm

<!-- ⚠️⚠️ 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. -->
The name and the documentation for the `statusBarCommands` property of the [SourceControl](https://code.visualstudio.com/api/references/vscode-api#SourceControl) API object indicates that it contributes commands to the status bar. In fact the commands are also prepended to the toolbar of the object's row in the Source Control Repositories view, and when there are multiple SourceControl instances their `statusBarCommands` also get prepended to their rows in the Source Control view.

This screenshot shows it happening for the built-in Git extension, with a multiroot workspace involving two repos.

![image](https://github.com/microsoft/vscode/assets/6726799/9cc56b54-8310-4e7c-9981-eb38d8648157)

And this with a workspace involving only one git repo:

![image](https://github.com/microsoft/vscode/assets/6726799/92dc8c3e-78b1-4276-8adf-e86f4f90b0dc)


My source control extension wants to add commands to the status bar that are superfluous / confusing / space-wasteful in the views' toolbars.

I would like to be able to suppress that behaviour so my statusBarCommands only appear on the status bar.

For the Source Control view of a workspace with multiple repositories, this seems to be the current prepend logic:

https://github.com/microsoft/vscode/blob/2b7f9e2fff1286227db33e8ca31b4dfac29eb067/src/vs/workbench/contrib/scm/browser/scmRepositoryRenderer.ts#L108-L120
Repository: godot
Issue: FileSystem dock not showing any files, and resource files not editable in Inspector
Labels: bug,topic:editor,needs testing

### Tested versions

Reproducible in:

- Godot v4.2.2.stable
- Godot v4.3.beta1
- Godot v4.2.1.stable

### System information

Godot v4.2.2.stable - Windows 10.0.22631 - GLES3 (Compatibility) - NVIDIA GeForce RTX 3060 (NVIDIA; 31.0.15.4601) - 13th Gen Intel(R) Core(TM) i9-13900K (32 Threads)

### Issue description

I was working on a very small project (following a tutorial) and noticed at one point that the FileSystem dock was no longer showing any files at all:

![image](https://github.com/godotengine/godot/assets/35798/173bf675-299b-4818-8bf6-82f4a139bb26)

I then noticed that I was unable to edit custom resources in the Inspector. I believe these issues are linked because they showed up at the same time. I could be wrong.

![image](https://github.com/godotengine/godot/assets/35798/b7818400-87f6-4830-b74c-b487d850c09d)

In other views in the FileSystem dock, the files do show up:

![image](https://github.com/godotengine/godot/assets/35798/516acd76-0cda-4de1-8a93-16ca7b61c7f5)

![image](https://github.com/godotengine/godot/assets/35798/27465a4b-d343-4767-a46b-0a8bcc73a297)

My project is still able to build and run though:

![image](https://github.com/godotengine/godot/assets/35798/36983200-166b-4c58-aac4-14e0a351ccea)

I have tried closing and reopening Godot, and I've tried loading up other projects. I'm having the same issue in all projects across restarts. I thought it might be some kind of editor settings, but I couldn't find anything.

I also tried deleting my entire `~\AppData\Local\Godot` folder but that didn't help either.

### Steps to reproduce

I have no idea how I got in this state and no idea how to get out.


### Minimal reproduction project (MRP)

I'm having the same problem in all projects, so I believe it's not an issue with any one of them in particular. I'm happy to upload a project if that would help though.
Repository: go
Issue: cmd/go/internal/work, cmd/cgo: duplicate libobjc library with 2 or more cgo packages with Objective-C
Labels: OS-Darwin,NeedsInvestigation,GoCommand,compiler/runtime

### Go version

go version go1.22.3 darwin/arm64

### Output of `go env` in your module/workspace

<details>

```shell
GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/gopher/Library/Caches/go-build'
GOENV='/Users/gopher/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/gopher/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/gopher/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.22.3'
GCCGO='gccgo'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/var/folders/_0/h0671fcn4rgb5pn9c745dx2h0000gn/T/tmp.ElsgkzNn19/go.mod'
GOWORK=''
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/_0/h0671fcn4rgb5pn9c745dx2h0000gn/T/go-build1736924935=/tmp/go-build -gno-record-gcc-switches -fno-common'
```

</details>

### What did you do?

Consider a minimal program that involves at least two cgo packages, both of which with Objective-C code:

```
cd $(mktemp -d)
go mod init test
mkdir p1 p2
echo 'package p1; import "C"' > p1/p1.go
echo 'package p2; import "C"' > p2/p2.go
touch p1/p1.m p2/p2.m
echo 'package main; import (_ "test/p1"; _ "test/p2"); func main() {}' > main.go
```

I tried to build it on macOS Sonoma 14.5 with Xcode 15.4 without custom flags:

```
go build
```

### What did you see happen?

A warning is printed:

```
# test
ld: warning: ignoring duplicate libraries: '-lobjc'
```

### What did you expect to see?

No warning printed.

---

I believe this is a minified reproduce for an issue like https://github.com/fyne-io/fyne/issues/4502.

The duplicate library outcome for 2+ cgo packages with Objective-C has likely been happening [for a while](https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/work/exec.go;l=2746-2749;drc=6cd066f8b22290a1737a19d25f5dd899f720180a), but what's changed recently is that the new linker in Xcode 15 causes the duplicate library to be printed as a warning unless `-ldflags=-extldflags=-Wl,-no_warn_duplicate_libraries` is used to disable duplicate library warnings. See \[1\], \[2\].

\[1\]: issue #61229 ("cmd/link: issues with Apple's new linker in Xcode 15 beta")
\[2\]: https://indiestack.com/2023/10/xcode-15-duplicate-library-linker-warnings/

CC @matloob, @cherrymui.
Repository: vscode
Issue: editor.find.autoFindInSelection does not treat block selection as multiline
Labels: editor-find,under-discussion

Does this issue occur when all extensions are disabled?: Yes

- VS Code Version: 1.89.1
- OS Version: Ubuntu Linux 22.04

Steps to Reproduce:

1. Set editor.find.autoFindInSelection to multiline
2. Use Alt-Shift-Leftclick to select a rectangular block of text that spans multiple lines
3. Press Ctrl-H

You will notice that "Find in Selection" is not enabled.  Since the block of text technically spans multiple lines of code, it should be.
Repository: go
Issue: cmd/cgo/internal/testsanitizers: TestTSAN/tsan14 failures
Labels: NeedsInvestigation

```
#!watchflakes
default <- pkg == "cmd/cgo/internal/testsanitizers" && test ~ `TestTSAN/tsan\d+`
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8750213702501358961)):

    === RUN   TestTSAN/tsan14
    === PAUSE TestTSAN/tsan14
    === CONT  TestTSAN/tsan14
        tsan_test.go:77: /home/swarming/.swarming/w/ir/x/t/TestTSAN1360052067/tsan14 exited with exit status 66
            ==================
            WARNING: ThreadSanitizer: signal handler spoils errno (pid=36513)
                #0 runtime.cgoSigtramp /home/swarming/.swarming/w/ir/x/w/goroot/src/runtime/sys_linux_amd64.s:388 (tsan14+0x513060)
                #1 _cgo_get_context_function <null> (tsan14+0x51a602)
                #2 _cgo_release_context <null> (tsan14+0x51a010)
                #3 go_callback <null> (tsan14+0x519d43)
            
            SUMMARY: ThreadSanitizer: signal handler spoils errno /home/swarming/.swarming/w/ir/x/w/goroot/src/runtime/sys_linux_amd64.s:388 in runtime.cgoSigtramp
            ==================
    --- FAIL: TestTSAN/tsan14 (3.50s)


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: go
Issue: x/net/http2: TestServerWritesTrailers_WithFlush failures
Labels: NeedsInvestigation

```
#!watchflakes
default <- pkg == "golang.org/x/net/http2" && test == "TestServerWritesTrailers_WithFlush"
```

Issue created automatically to collect these failures.

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

    === RUN   TestServerWritesTrailers_WithFlush
        http2_test.go:66: 2024/05/30 19:58:01 ignoring invalid trailer "Transfer-Encoding"
        http2_test.go:66: 2024/05/30 19:58:01 ignoring invalid trailer "Content-Length"
        http2_test.go:66: 2024/05/30 19:58:01 ignoring invalid trailer "Trailer"
        server_test.go:2794: got no frame, want frame *http2.HeadersFrame
        http2_test.go:66: 2024/05/30 19:58:01 ignoring invalid trailer "Range"
    --- FAIL: TestServerWritesTrailers_WithFlush (0.02s)


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: next.js
Issue: Nextjs reloads page when i go to not-found page
Labels: bug,Navigation,Pages Router

### Link to the code that reproduces this issue

https://stackblitz.com/edit/stackblitz-starters-heagtm

### To Reproduce

click button "Plus 1"
click button "go to not found"
page will be reloaded
after reloaded page loose context state

### Current vs. Expected behavior

Current behavior: reloads page 
Expected:  just rendering it without reload page 

```
'use client';
import { useContext } from './Context';
import { useRouter } from 'next/navigation';
import Link from 'next/link';
export default function Page() {
  const router = useRouter();
  const { id, setId } = useContext();
  return (
    <>
      <Link href="/page-not-found">page-not-found</Link> /
      <button type="button" onClick={() => router.push('/page-not-found')}>
        Go to not found
      </button>{' '}
      /
      <button type="button" onClick={() => setId(id + 1)}>
        Plus 1
      </button>
      <div>id: {id}</div>
    </>
  );
}
```

### Provide environment information

```bash
stackblitz.com:
node: 18.20.3 
next: 13.5.1

my host:
node: 20.11.0
next: 14.2.3
```


### Which area(s) are affected? (Select all that apply)

Navigation, Pages Router

### Which stage(s) are affected? (Select all that apply)

next dev (local), next start (local),

### Additional context

_No response_
Repository: vscode
Issue: I am trying to find the resize handle in diff editor every time
Labels: bug,ux,diff-editor,papercut :drop_of_blood:

I am a big fan of the explicit actions in the diff editor to stage or undo a change, but I find myself constantly trying to find the location where I can grab and resize:

![Recording 2024-06-04 at 07 13 18](https://github.com/microsoft/vscode/assets/900690/020c6f48-4cda-46b4-a0b6-f3c455bf2e55)

As you can see, its inconsistent: the first sash is somewhere in the middle (but not exactly!) and the second sash is exactly on the right where the shadow is.

I would love if we could go back to just 1 sash but make the hit area clearly visible by showing a vertical line when you hover anywhere in between the 2 diff editors.
Repository: godot
Issue: Pick tool on Atlas editor closes the editor without choosing the tile
Labels: discussion,topic:editor,documentation,topic:2d

### Tested versions

- Reproducible in: 4.3-dev (current git)

### System information

Windows 11

### Issue description

In Paint Property window (when TileSet selected), using picker tool closes the editor, instead of choosing the right tile. It works on TileMap window.

### Steps to reproduce

1) Choose a TileMapLayer,
2) Open TileSet editor
3) Choose Paint tool
4) Choose Picker tool
5) Choose a tile from the map

https://github.com/godotengine/godot/assets/231068/0609f498-5293-4cab-a15e-8b44b5677eda



### Minimal reproduction project (MRP)

[tilebug.zip](https://github.com/user-attachments/files/15543139/tilebug.zip)