sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: [Rename symbol command] Remove unnecessary named import
Labels: Suggestion,Help Wanted,Experience Enhancement,Effort: Casual

<!-- ⚠️⚠️ 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. -->

<!-- 🪓 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.84.2 (1a5daa3a0231a0fbba4f14db7ec463cf99d7768e)
- OS Version: macOS Sonoma 14.1.1

Steps to Reproduce:

1. Create 2 JS files:
> ```js
> // utils.js
> export const foo = () => console.log('Hello world!');
> ```
> ```js
> // index.js
> import { foo as bar } from "./utils.js";
> 
> bar();
> ```
2. Put your cursor in the word "foo" in utils.js and use the "Rename Symbol" command (`F2` by default) to rename the function to `bar`.
3. Observe the import in index.js has changed to `import { bar as bar } from "./utils.js"`. Since the names import is no longer necessary, the command should instead change the import to `import { bar } from "./utils.js"`.
Repository: flutter
Issue: NativeAsset build system target not guarded by feature flag
Labels: P2,team-tool,triaged-tool

https://github.com/flutter/flutter/pull/130494 introduced the `NativeAssets` build system target, declared as dependency of the `KernelSnapshot` target.

It also introduced an `enable-native-assets` feature flag. This feature flag is also not available on beta and stable branches.

The build system dependency between KernelSnapshot and NativeAssets was *not* guarded by a feature flag. This means that:

1. it is not currently possible to enable native assets on release branches
2. the NativeAssets build target is unconditionally built

Although not the underlying issue of https://github.com/flutter/flutter/issues/136547, hotfixing this to the 3.16 stable would effectively prevent it.
Repository: ollama
Issue: Support text to speech (TTS) models such as Suno AI Bark
Labels: feature request

Is it possible to have a native support for Bark TTS or langchain version of it?
Repository: tauri
Issue: [feat] How to switch app language dynamically
Labels: type: feature request

### Describe the problem

<img width="430" alt="image" src="https://github.com/tauri-apps/tauri/assets/75017711/91282a51-7fa9-42a8-b2a5-d83ad6482e2b">

I want to change the default language of the app and then dynamically switch the language of the app, how should I do it?

### Describe the solution you'd like

I hope this solves my confusion!

### Alternatives considered

_No response_

### Additional context

_No response_
Repository: rust
Issue: Cannot link `dylib` crate to `staticlib` crate
Labels: A-linkage,T-compiler,A-docs,C-bug

### Problem

If you have a `dylib`-kind crate and try to use it from a `staticlib`-kind crate, you get this error: 

```
error: crate `dylib` required to be available in rlib format, but was not found in this form
```

### Steps

1. Checkout https://github.com/russelltg/link-dylib-to-staticlib
2. `cargo build`

### Possible Solution(s)

Ideally metadata in the `.lib` would be generated to make the eventual target link to the shared library, I assume through the `native-static-libs`. It would be fine without this though, I'm fine with manually linking it. 

Alternatively, if this is not a valid configuration, a better error message would be appreciated

### Notes

My usecase is something I think should be supported--I'm writing a static library to be consumed from a C++ application, and it needs a tokio runtime that will be shared with other static libraries. So I've put the tokio runtime in the dynamic library.

My workaround for now is to make it a `cdylib` and not to mangle the function, and import it with an `extern` section. 

Maybe there's a better way to do what I'm trying to do?

### Version

```text
cargo 1.73.0 (9c4383fb5 2023-08-26)
release: 1.73.0
commit-hash: 9c4383fb55986096b414d98125421ab87b5fd642
commit-date: 2023-08-26
host: x86_64-pc-windows-msvc
libgit2: 1.6.4 (sys:0.17.2 vendored)
libcurl: 8.2.1-DEV (sys:0.4.65+curl-8.2.1 vendored ssl:Schannel)
os: Windows 10.0.19045 (Windows 10 Pro) [64-bit]
```
Repository: rust
Issue: Infinite loop in compiler
Labels: A-trait-system,T-compiler,C-bug,I-hang

<!--
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.
-->

Minimal example code which causes infinite compile times:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=13fec5b370c8046012770d2e2470c934

```rust
trait Bound { type Assoc; }

struct Recursive<'a, A: Bound> {
  value: A,
  rest: &'a Option<Recursive<'a, A::Assoc>>
}
```

I expected to see: the compiler finish executing.

Instead, this happened: the compiler hangs with modest CPU usage, seemingly indefinitely.

As an aside, the lack of a bound on the `Assoc` type should raise an error (otherwise the declaration is self-contradictory), but we never even get that far. So I have removed the bound in favor of making the example as minimal as possible. To be clear, the version with the correct bound hangs as well.

### 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.
-->

I have not done a thorough search over which versions hang.

The bug exists in stable: `1.73.0`, `1.74.0`, and possibly more versions of stable compiler.
The bug exists in beta `1.75.0-beta.3`, and nightly `1.76.0-nightly`, and possibly more versions of these compilers.

`rustc --version --verbose`:
```
rustc 1.73.0 (cc66ad468 2023-10-03)
binary: rustc
commit-hash: cc66ad468955717ab92600c770da8c1601a4ff33
commit-date: 2023-10-03
host: aarch64-apple-darwin
release: 1.73.0
LLVM version: 17.0.2
```


<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"veera-sivarajan"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: terminal
Issue: Warning message displayed is not proper when a non-monospaced font is selected
Labels: Help Wanted,Issue-Bug,Product-Terminal,Area-SettingsUI

### Windows Terminal version

1.18.2822.0

### Windows build number

10.0.22621.0

### Other Software

https://monaspace.githubnext.com

### Steps to reproduce

Select a non-monospaced font like one of the fonts from [Monsaspace fonts](https://monaspace.githubnext.com) (Monaspace Neon)

### Expected Behavior

The warning message displayed should be contained like the other UI elements in the page like Color scheme, Font face, etc.. 

### Actual Behavior

But the width of the warning message goes beyond the width of the other UI elements
Repository: rust
Issue: Tracking Issue for MaybeDangling
Labels: B-RFC-approved,T-lang,C-tracking-issue,S-tracking-unimplemented

This is a tracking issue for the experimental MaybeDangling type (as per the T-lang [experimental feature](https://github.com/rust-lang/lang-team/blob/master/src/how_to/experiment.md) process). The type is described by [this RFC](https://github.com/rust-lang/rfcs/pull/3336), but we can experiment with adding the type unstably (and even using it in `ManuallyDrop`) before the RFC gets accepted.

### 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.

### 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.
-->

- [ ] Implement the RFC (looking for someone who's willing to do this :)
- [ ] Finish the RFC, have it accepted
- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide])
- [ ] Formatting for new syntax has been added to the [Style Guide] ([nightly-style-procedure])
- [ ] 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.
-->
- [What are the exact validity requirements of `MaybeDangling` references?](https://github.com/rust-lang/rust/issues/118166#issuecomment-2391653383)


(see RFC)

### Implementation history

<!--
Include a list of all the PRs that were involved in implementing the feature.
-->
Repository: ollama
Issue: GPTQ / ExLlamaV2 (EXL2) quantisation
Labels: feature request

# Feature Description

Please provide a detailed written description of what you were trying to do, and what you expected `llama.cpp` to do as an enhancement.

# Motivation

It sounds like it's a fast/useful quantisation method:

- https://towardsdatascience.com/exllamav2-the-fastest-library-to-run-llms-32aeda294d26
  - https://github.com/mlabonne/llm-course/blob/main/Quantize_models_with_ExLlamaV2.ipynb
- https://towardsdatascience.com/4-bit-quantization-with-gptq-36b0f4f02c34
- https://huggingface.co/blog/gptq-integration
- https://oobabooga.github.io/blog/posts/gptq-awq-exl2-llamacpp/
  - > A detailed comparison between GPTQ, AWQ, EXL2, q4_K_M, q4_K_S, and load_in_4bit: perplexity, VRAM, speed, model size, and loading time.

## See Also

- https://github.com/ggerganov/llama.cpp/issues/4165
Repository: next.js
Issue: Non-NextJS Error Boundary doesn't catch errors originating from server components.
Labels: bug

### Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/nextjs-error-boundary-catches-server-throws-mmvlsd

### To Reproduce

- Create your own [`ErrorBoundary` component](https://react.dev/reference/react/Component#catching-rendering-errors-with-an-error-boundary)
- Render a Server component which throws as a child of a `<ErrorBoundary />` with some arbitrary fallback UI
- run the dev server

### Current vs. Expected behavior

Current Behavior:
any custom `<ErrorBoundary />` component will not catch an error that is thrown from a descendent server component, instead it will be uncaught, unless a `error.tsx` file is defined somewhere for the given route.

Expected Behavior:
`<ErrorBoundary />`-like components should catch server errors without needing to be implemented as Route Segment `error.tsx` files.

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
Binaries:
  Node: 20.9.0
  npm: 10.1.0
  Yarn: 1.22.19
  pnpm: N/A
Relevant Packages:
  next: 14.0.4-canary.9
  eslint-config-next: 14.0.2
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.2.2
Next.js Config:
  output: N/A
```


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

App Router

### Additional context

In the linked sandbox, adding `"use client";` to the `<BadComponent />` resolves the issue, proving the gap in functionality between Next's proprietary error boundary and how "native" error boundaries behave. I also don't believe this discrepancy has always been the case.
Repository: go
Issue: cmd/compile: unexpected benchmark results
Labels: Performance,NeedsInvestigation,compiler/runtime

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.21.4 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on go.dev/play is best.
-->

```go
package main

import "testing"

var n = 1024 * 1024 * 16

type Large = int
var r1 []Large
var r2 []Large

func Benchmark_CompactFunc(b *testing.B) {
	ss1 := make([]Large, n)
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		r1 = CompactFunc(ss1, func(a, b Large) bool {return a == b})
	}
}

func Benchmark_CompactFunc_2(b *testing.B) {
	ss1 := make([]Large, n)
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		r2 = CompactFunc_2(ss1, func(a, b Large) bool {return a == b})
	}
}


func CompactFunc[S ~[]E, E any](s S, eq func(E, E) bool) S {
	if len(s) < 2 {
		return s
	}
	i := 1
	for k := 1; k < len(s); k++ {
		if !eq(s[k], s[k-1]) {
			if i != k {
				s[i] = s[k]
			}
			i++
		}
	}
	clear(s[i:]) // zero/nil out the obsolete elements, for GC
	return s[:i]
}

var global bool

func CompactFunc_2[S ~[]E, E any](s S, eq func(E, E) bool) S {
	global = true // This is the only difference

	if len(s) < 2 {
		return s
	}
	i := 1
	for k := 1; k < len(s); k++ {
		if !eq(s[k], s[k-1]) {
			if i != k {
				s[i] = s[k]
			}
			i++
		}
	}
	clear(s[i:]) // zero/nil out the obsolete elements, for GC
	return s[:i]
}
```

### What did you expect to see?

Similar performance for the specified test case.

### What did you see instead?

Benchmark result shows `CompactFunc_2` is (about 15%) slower, which is quite confusing.

```
goos: linux
goarch: amd64
pkg: example.com
cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
Benchmark_CompactFunc-4     	      19	  66914978 ns/op
Benchmark_CompactFunc_2-4   	      18	  75483657 ns/op
```
Repository: rust
Issue: Tracking Issue for WebAssembly exception handling
Labels: C-tracking-issue

This is a tracking issue for wasm native exception handling, which would allow `panic=unwind` to function properly for code targeting wasm.

### 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.

### Steps

- [x] Initial compiler support (#111322)
- [x] Standard library support (#121438)
- [ ] LLVM support for newest iteration of try/catch instructions (see WebAssembly/exception-handling#280, WebAssembly/exception-handling#296)
- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide])
- [ ] 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

- [x] `-C target-feature=+exception-handling` vs `-C panic=unwind` -- does one imply the other, or is one of them redundant?
  - panic=unwind should enable exception-handling
- [x] Should `-C llvm-args=-wasm-enable-eh` be passed by default on all wasm targets, to be stripped out if the `exception-handling` target feature is disabled?
  - yes: afaict `-wasm-enable-eh` does not affect codegen in general, only isel for the wasm.throw instruction.
- [ ] Should exception-handling instructions (e.g. from prebuilt libstd) be stripped out if `panic=abort`? If so, by whom? `wasm-ld`? `wasm-opt` does currently implement a `--strip-eh` pass; maybe that's good enough if users want to target wasm MVP?
  - this problem is similar to the one that `atomics` (#77839) faces, of a single prebuilt libstd coming into conflict with some users needing backwards compatibility with wasm-MVP and others wanting to use more recently stabilized features

### Implementation history

- #111322
- #121438
Repository: PowerToys
Issue: Add param for Release yml to bypass signing for testing
Labels: Area-Build

### Description of the new feature / enhancement

Signing can add a lot of time and isn't needed if we are testing.  

The Signing param should be on by default.

IMO the build should still fail and no artifacts created.

### Scenario when this would be used?

testing builds and saving about 30+ minutes

### Supporting information

_No response_
Repository: PowerToys
Issue: Chrome new window fails with Always on top
Labels: Issue-Bug,Product-Always On Top,Priority-3,Status-Reproducible

### Microsoft PowerToys version

0.75.1

### Installation method

PowerToys auto-update

### Running as admin

No

### Area(s) with issue?

Always on Top

### Steps to reproduce

Open a Chrome window, fix it with Always on top and open a new window from the fixed window

### ✔️ Expected Behavior

The fixed window remains fixed and appears a new window, not fixed

### ❌ Actual Behavior

The new window appears just below the fixed window, unaccesible until you disable Always on top

### Other Software

_No response_
Repository: create-react-app
Issue: Empty page when running `npm start`
Labels: needs triage,issue: bug report

### Describe the bug

When running `npm start`, the browser shows an empty page but the console show no errors or warnings. Using the page analyser with F12 shows a totally empty page, even the warning under `<noscript>' is absent.

### Did you try recovering your dependencies?

I runned `npm start` on a freshly created app with `npx create-react-app`, and I runned the start command without modifying anything. Even setting `homepage: '.'` or `homepage: './'` in `package.json` didn't work.

### Environment

```
  System:
    OS: Windows 11 10.0.22631
    CPU: (16) x64 AMD Ryzen 7 6800H with Radeon Graphics
  Binaries:
    Node: 20.9.0 - C:\Program Files\nodejs\node.EXE
    Yarn: Not Found
    npm: 10.2.3 - C:\Program Files\nodejs\npm.CMD
```

### Steps to reproduce

1. run `npx create-react-app <folder>`
2. input `y` when prompt the installation of `create-react-app`
3. after completed run these commands
```bash
cd <folder>
npm start
```

### Expected behavior

The expected behiavour is to see the React logo spinning

### Actual behavior

The actual behiavour is a complete blank page
Repository: kubernetes
Issue: contextual logging: move key/value args into WithValues
Labels: kind/feature,sig/instrumentation,lifecycle/frozen,triage/accepted,wg/structured-logging

### What would you like to be added?

There are several areas in the code where all log calls include the same set of key/value pairs. The code can be simplified by moving those log call parameters into a single `WithValues` if:

- https://github.com/kubernetes/enhancements/issues/3077 is GA - contextual logging might still get turned off before that.
- The modified logger is long-lived enough that the overhead for `WithValues` doesn't matter.

This issue is a meta issue for collecting TODOs. Add links to individual packages or files in the comments and I'll update the task list accordingly from time to time.

/lifecycle frozen
/sig instrumentation
/wg structured-logging

### Why is this needed?

- simpler code
- log entries further down the call chain will also have those key/value pairs


```[tasklist]
### Tasks
- [ ] https://github.com/kubernetes/kubernetes/blob/bacac2547997d432fd6a93d7cef4aa64644544df/pkg/scheduler/schedule_one.go#L80-L83
- [ ] https://github.com/kubernetes/kubernetes/blob/bacac2547997d432fd6a93d7cef4aa64644544df/staging/src/k8s.io/client-go/tools/cache/reflector.go#L425
```
Repository: go
Issue: slices: more explicit doc for Delete, DeleteFunc, Replace
Labels: Documentation,NeedsInvestigation

This a minor documentation proposal.

I've witnessed many variations of these two incorrect idioms:
```
    slices.Delete(s, i, i+1)
```

```
    u := slices.Delete(t, i, i+1)
    // keep using t and u...
```

- In the first one, the caller is ignoring the returned value, because they assume Delete works in-place.
- In the second one, the caller is assigning the returned value to a different variable, because they assume Delete creates a new slice.

Delete does operate in-place, but because of the nature of slice headers, it also returns a new slice header. This API is similar to `append`.

- A mitigation against ignoring the returned slice is a vet warning: #62729.
- Static analysis is however mostly powerless about "the caller is reusing the original slice header".

The documentation for functions Delete, DeleteFunc, Replace are already correct. But depending on how the user understands the words "remove" and "modified", they may still end up using one of the incorrect idioms, relying on the wrong assumption that the API must be either 100% in-place or 100% by copy.

Here is (in bold) my suggested addition to the docs:

func Delete

> Delete removes the elements s[i:j] from s, returning the modified slice.
> **Delete operates in place, which is destructive for the contents of the original slice.**
> Delete panics if j > len(s) or s[i:j] is not a valid slice of s.
> Delete is O(len(s)-i), so if many items must be deleted, it is better to
> make a single call deleting them all together than to delete one at a time.
> Delete zeroes the elements s[len(s)-(j-i):len(s)].

func DeleteFunc

> DeleteFunc removes any elements from s for which del returns true, returning the modified slice.
> **DeleteFunc operates in place, which is destructive for the contents of the original slice.**
> DeleteFunc zeroes the elements between the new length and the original length.

func Replace

> Replace replaces the elements s[i:j] by the given v, and returns the
> modified slice.
> **Replace operates in place, which is destructive for the contents of the original slice.**
> Replace panics if j > len(s) or s[i:j] is not a valid slice of s.
> When len(v) < (j-i), Replace zeroes the elements between the new length and the original length.
Repository: go
Issue: x/net/html: self closing tags with unquoted attributes mistake trailing slashes as attribute values
Labels: NeedsInvestigation

Hi there,

[here](https://go.dev/play/p/OFquT-CCNAK) is a playground link, but I can summarize:

This piece of HTML:
```html
<img src=/foo/>
```
Gets correctly parsed by the tokenizer as being a self-closing tag.

This means that the last slash is part of the tag, not of the `src` attribute.

But if you run the playground code, you get this:
```
SelfClosingTag "<img src=/foo/>"
↳ TagName: "img" Type: SelfClosingTag
↳ Attr: key:"src" val:"/foo/"
```

So the trailing slash is both interpreted as the closing tag and as the attribute value.

The correct parsing should be to have the attribute value to be "/foo", not "/foo/".

# EDIT
This also affect "Parse", so parsing and rendering the above example renders it as

```
<html><head></head><body><img src="/foo/"/></body></html>
```

[playground](https://go.dev/play/p/Ili7BD3v9jR)