sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Tracking Issue for `const_array_as_mut_slice`
Labels: T-libs-api,C-tracking-issue

Add the `const` specifier to `<[T; N]>::as_mut_slice`.

### Public API

```rust
impl<T, const N: usize> {
    pub const fn as_mut_slice(&mut self) -> &mut [T];
}
```

### Steps / History


- [x] Implementation: #133332 
- [ ] Final comment period (FCP)
- [ ] Stabilization PR

### Unresolved Questions

- None yet.
Repository: flutter
Issue: [asset_transformers] Provide the current target platform in the asset transformer
Labels: c: new feature,tool,a: assets,c: proposal,a: build,P2,team-tool,triaged-tool

### Use case

Developers wanting to transform assets, based on the current target platform (i.e. `flutter build web` -> web; `flutter build apk` -> android), currently cannot infer the target platform during the asset transformation.

### Proposal

I propose that the target platform of the `flutter build` invocation is provided as either an argument, or in `Platform.environment`. I initially tried checking what is inside `Platform.environment` and the `FLUTTER_BUILD_MODE` seems to be there already?

Then I think the easiest thing to do is to also add something like `FLUTTER_BUILD_TARGET_PLATFORM` to `Platform.environment` or the args that are passed to the asset transformer, whichever makes more sense / is cleaner from a tool perspective.  

Context: I was initially exploring if I could work around the absence of https://github.com/flutter/flutter/issues/141371 using an asset transformer
Repository: deno
Issue: fmt(svelte): formatter error on dynamic style in svelte
Labels: bug,upstream,deno fmt

Version: Deno 2.1.1

```svelte
<script lang="ts">
  const { color }: { color: string | null } = $props();
</script>

<div
  style="background-color: {color || 'blueviolet'};"
>
</div>
```
```txt
deno fmt --unstable-component
Error formatting: C:\temp\deno-init\test.svelte
   syntax error at line 6, col 28: expect token `<ident>`, but found `{`
Checked 4 files
```
Repository: ollama
Issue: LLM(vision) GGUF Recommendation: Is there any LLM(vision) with great performance in GGUF format?
Labels: bug

### Disappointing Performance
It's really strange that I have tried many **LLMs with vision** in `GGUF` format, listed in the official website, such as `Llama3.2-vision`, `llava`, `llava-llama3`, `llava-phi3`. However, all of their performance is disappointing in **vision** aspect, even a simple task like recognizing an image of an apple.
### GGUF format
By the way, to be quickly start, I tried all LLMs in `GGUF` format. I don't know whether it is a hinder for good performance.
### Help 
So, I post this issue for your help and a good LLM with vision in `GGUF` format recommendation, or **any other importing ways** to get a great performance, thanks for your help!!!

### OS

Linux

### GPU

Nvidia

### CPU

Intel

### Ollama version

0.4.2
Repository: kubernetes
Issue: bug: RPM repo PGP check fails
Labels: kind/bug,sig/docs,sig/release,needs-triage

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!

If the matter is security related, please disclose it privately via https://kubernetes.io/security/
-->

**What happened**:
When trying to upgrade package using official Yum repo this occurs:
```
Running transaction
Transaction failed: Signature verification failed.
PGP check for package "kubectl-1.31.3-150500.1.1.x86_64" (/var/cache/libdnf5/kubernetes-3d554b2ea1b53740/packages/kubectl-1.31.3-150500.1.1.x86_64.rpm) from repo "kubernetes" has failed: Problem occurred when opening the package.

```

**What you expected to happen**:
Update succeeds and package installed.

**How to reproduce it (as minimally and precisely as possible)**:
<!-- Please make sure you are able to reproduce the bug using a supported version and version skew of Kubernetes. See https://kubernetes.io/docs/setup/release/version-skew-policy for which versions and are currently supported.
-->
Add repo following https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#install-using-native-package-management and try to update RPM package.

**Anything else we need to know?**: It worked until now.

**Environment**:
- Kubernetes client and server versions (use `kubectl version`): kubectl-1.31.3-150500.1.1.x86_64
- Cloud provider or hardware configuration: n/a/
- OS (e.g: `cat /etc/os-release`): Fedora Linux 41
Repository: next.js
Issue: Inconsistent behavior of `usePathname` with static rendering during build
Labels: bug,Middleware

### Link to the code that reproduces this issue

https://github.com/amannn/nextjs-bug-repro-usepathnamessg/commit/c6b084df43e08a9b043548fb577be8db5f059bde

### To Reproduce

Compare the output of `usePathname` in development vs during the static prerender when accessing the route `/test` which uses a rewrite in the middleware.

### Current vs. Expected behavior

`usePathname` seems to pick up a request-time pathname from a middleware rewrite. However, as this information is not available during a static build, `usePathname` will return a different value in this case. Then again, when running the app in production, `usePathname` will return the pathname that's displayed in the browser (i.e. after a rewrite), but only on the client side.

In the reproduction this leads to a text content mismatch, but more generally this breaks a dev/prod guarantee. I'd expect a static prerender to only be a performance optimization and not to change application logic.

I guess some unification would be necessary here.

Note that this only applies for static prerendering, if you use SSR in production then the behavior is the same as in dev.

A more real world use case where this behavior was encountered: https://github.com/amannn/next-intl/issues/1568

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: x64
  Version: Darwin Kernel Version 23.6.0: Mon Jul 29 21:13:00 PDT 2024; root:xnu-10063.141.2~1/RELEASE_X86_64
  Available memory (MB): 16384
  Available CPU cores: 12
Binaries:
  Node: 20.11.1
  npm: 10.2.4
  Yarn: 1.22.22
  pnpm: 9.14.2
Relevant Packages:
  next: 15.0.4-canary.23 // Latest available version is detected (15.0.4-canary.23).
  eslint-config-next: 15.0.4-canary.23
  react: 19.0.0-rc-380f5d67-20241113
  react-dom: 19.0.0-rc-380f5d67-20241113
  typescript: 5.6.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Middleware

### Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local)

### Additional context

Maybe a hook like `useInternalPathname()` (naming TBD) could help that always reliably returns the pathname that renders in Next.js, regardless of any rewrites—essentially matching the directory structure in `src/app`.
Repository: rust
Issue: Tracking Issue for relnotes interest group ping group
Labels: C-tracking-issue,T-release,A-meta

Tracking issue for creating a ping group for relnotes PRs so interested contributors can get pinged for that specific purpose (instead of pinging whole teams like T-compiler which has idk 50+ members). Note that the following steps are derived from [T-compiler notification group procedure](https://forge.rust-lang.org/compiler/notification-groups.html) but adjusted because it's compiler-specific ping groups.

### Implementation steps

- [x] ~~File a tracking issue in the [rust-lang/compiler-team](https://github.com/rust-lang/compiler-team) repository to collect your progress.~~ Not compiler-specific ping group.
- [x] Create a PR against the [rust-lang/team](https://github.com/rust-lang/team) repository adding the notification group. https://github.com/rust-lang/team/pull/1613
- [x] Configure the [rust-lang/rust](https://github.com/rust-lang/rust) repository to accept triagebot commands for this group. https://github.com/rust-lang/rust/pull/135032
- [ ] Configure the [rust-lang/blog.rust-lang.org](https://github.com/rust-lang/blog.rust-lang.org) repository to accept triagebot commands for this group. https://github.com/rust-lang/blog.rust-lang.org/pull/1453
- [x] ~~Create a PR for the rustc-dev-guide amending [the notification group section](https://rustc-dev-guide.rust-lang.org/notification-groups/about.html) to mention your group.~~ T-release mostly, not compiler.
- [x] Create a sample PR for the [rust-lang/team](https://github.com/rust-lang/team) repository showing how one can add oneself. This will be referenced by your blog post to show people how to join. See https://github.com/rust-lang/team/pull/1613.
- [ ] Create a PR for the forge release notes section to describe the relnotes interest group ping group.
- [x] ~~Create a Zulip stream for the notification group. If you don’t have the permission to do, you can ask on [#t-compiler/wg-meta](https://rust-lang.zulipchat.com/#narrow/stream/185694-t-compiler.2Fwg-meta).~~ Unclear if needed, probably better to discuss on the relnotes PR itself.
- [ ] Write an announcement blog post for Inside Rust and open a PR against [blog.rust-lang.org](https://github.com/rust-lang/blog.rust-lang.org).

### Relevant context

- Zulip discussion: https://rust-lang.zulipchat.com/#narrow/channel/241545-t-release/topic/Please.20CC.20lang
Repository: godot
Issue: [3.x] Particles2D and Multithreaded rendering throws error (Rare)
Labels: bug,topic:rendering,needs testing

### Tested versions

Tested in Godot 3.5.1, GLES2
[edit] Tested in Godot 3.6, GLES2

### System information

Ubuntu 24.04.1, 64bit, NVIDIA GeForce GTX 1050 Ti

### Issue description

When toggling emission of a CPUParticles2D node it will sometimes throw the error:
`emit_signal: Error calling method from signal 'frame_pre_draw': 'CPUParticles2D::': Method not found..`

This seems to only occur when multithreaded render mode is enabled.

The bug occurs quite rarely, and with varying behavior. Sometimes the error is just printed once, sometimes it keeps spamming very quickly, and sometimes it crashes the game process.

### Steps to reproduce

- Make a particle system and an animation that toggles it on and off (no other particle system settings are required, although the issue MRP has 'one-shot' enabled)
- Make a script that plays the animation repeatedly with a small random delay between plays.
- Duplicate it a few hundred times, to get the error to reproduce without having to wait for hours
- To speed up the reproduction, you can also increase engine_time_scale

Note how the error is printed when render mode in the project settings is "Multi-Threaded", and does not occur with "Single-Safe" render mode.

### Minimal reproduction project (MRP)

Reproduction project available at
github.com/Tugsav/godot-particle2d-multithreading-bug

Reproduction using time scale 50 should be pretty quick.
Reproduction without modifying time scale can take a while (i had the error occur after ~17 min)
Repository: ui
Issue: [feat]: Add support for react 19
Labels: area: request

### Feature description

Is there any timeframe or plan to migrate components to react 19?

### Affected component/components

Most if not all

### Additional Context

The use of forwardRef on same/most components for example is forcing the need to implement some change on the component definition and integration.

### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues and PRs
Repository: kubernetes
Issue: Failure cluster [34ae9536...] [sig-node] [sig-windows] Container runtime failed test
Labels: sig/node,kind/flake,sig/windows,kind/failing-test,needs-triage

### Failure cluster [34ae95361eb5abbcb926](https://go.k8s.io/triage#34ae95361eb5abbcb926)

![image](https://github.com/user-attachments/assets/f4fe5ffb-9bb5-4087-969c-a02084e602ee)


##### Error text:
```
[FAILED] Timed out after 300.000s.
Expected
    <v1.PodPhase>: Failed
to equal
    <v1.PodPhase>: Succeeded
In [It] at: k8s.io/kubernetes/test/e2e/common/node/runtime.go:157 @ 11/13/24 11:24:41.726

```
#### Recent failures:
[11/22/2024, 4:01:07 AM ci-kubernetes-e2e-windows-containerd-gce-master](https://prow.k8s.io/view/gs/kubernetes-ci-logs/logs/ci-kubernetes-e2e-windows-containerd-gce-master/1859794199298183168)
[11/22/2024, 3:14:07 AM ci-kubernetes-e2e-windows-win2022-containerd-gce-master](https://prow.k8s.io/view/gs/kubernetes-ci-logs/logs/ci-kubernetes-e2e-windows-win2022-containerd-gce-master/1859782365962833920)
[11/21/2024, 11:14:03 PM ci-kubernetes-e2e-windows-win2022-containerd-gce-master](https://prow.k8s.io/view/gs/kubernetes-ci-logs/logs/ci-kubernetes-e2e-windows-win2022-containerd-gce-master/1859721958103453696)
[11/21/2024, 8:00:04 PM ci-kubernetes-e2e-windows-containerd-gce-master](https://prow.k8s.io/view/gs/kubernetes-ci-logs/logs/ci-kubernetes-e2e-windows-containerd-gce-master/1859673139961663488)
[11/21/2024, 7:14:04 PM ci-kubernetes-e2e-windows-win2022-containerd-gce-master](https://prow.k8s.io/view/gs/kubernetes-ci-logs/logs/ci-kubernetes-e2e-windows-win2022-containerd-gce-master/1859661559568011264)


/kind failing-test
/kind flake

Flake > 65% occurrence 

/sig node
/sig windows
Repository: rust
Issue: Tracking issue for release notes of #133293: Updates Solaris target information, adds Solaris maintainer
Labels: T-compiler,relnotes,O-solaris,relnotes-tracking-issue


This issue tracks the release notes text for #133293.

### Steps

- [ ] Proposed text is drafted by PR author (or team) making the noteworthy change.
- [ ] Issue is nominated for release team review of clarity for wider audience.
- [ ] Release team includes text in release notes/blog posts.

### Release notes text

The responsible team for the underlying change should edit this section to replace the automatically generated link with a succinct description of what changed, drawing upon text proposed by the author (either in discussion or through direct editing).

````markdown
# Compatibility notes
- [Increase `sparcv9-sun-solaris` and `x86_64-pc-solaris` Solaris baseline to 11.4.](https://github.com/rust-lang/rust/pull/133293)
````

> [!TIP]
> Use the [previous releases](https://doc.rust-lang.org/nightly/releases.html) categories to help choose which one(s) to use.
> The category will be de-duplicated with all the other ones by the release team.
>
> *More than one section can be included if needed.*

### Release blog section

If the change is notable enough for inclusion in the blog post, the responsible team should add content to this section.
*Otherwise leave it empty.*

````markdown
````

cc @psumbera, @Noratrieb -- origin issue/PR authors and assignees for starting to draft text
Repository: next.js
Issue: Turbopack does not respect forceSwcTransforms
Labels: bug,Turbopack

### Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/peaceful-bhabha-n67k3g

### To Reproduce

1. Have a next config:
```
const nextConfig = {
  experimental: {
    forceSwcTransforms: true,
    turbo: {
      rules: {
        "*.svg": {
          loaders: ["@svgr/webpack"],
          exclude: /node_modules/,
          as: "*.js",
        },
      },
    },
  },
};
```

2. Have a babel file in root
3. Run `next dev --turbopack`

### Current vs. Expected behavior

You are using configuration and/or tools that are not yet
supported by Next.js with Turbopack:
Babel detected (babel.config.js)
  Babel is not yet supported. To use Turbopack at the moment,
  you'll need to remove your usage of Babel.

- Unsupported Next.js configuration option(s) (next.config.js)
  To use Turbopack, remove the following configuration options:
    - experimental.forceSwcTransforms


If you cannot make the changes above, but still want to try out
Next.js with Turbopack, create the Next.js playground app
by running the following commands:

  yarn create next-app --example with-turbopack with-turbopack-app
  cd with-turbopack-app
  yarn run dev
        
 ⚠ Learn more about Next.js and Turbopack: https://nextjs.link/with-turbopack

Expected: The build should succeed, same as it does without `--turbopack`.

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.0.0: Mon Aug 12 20:51:54 PDT 2024; root:xnu-11215.1.10~2/RELEASE_ARM64_T6000
  Available memory (MB): 16384
  Available CPU cores: 8
Binaries:
  Node: 20.11.0
  npm: 10.2.4
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 15.0.3 // Latest available version is detected (15.0.3).
  eslint-config-next: N/A
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.6.3
Next.js Config:
  output: N/A
```


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

Turbopack

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

next dev (local)

### Additional context

_No response_
Repository: ui
Issue: [bug]: cli does not work for simple javascript react code.
Labels: bug

### Describe the bug

I have created a react project without typescript in `Vite`, Try to install the shadcn using cli it does not work.
```cmd
PS D:\User\code\react-test> npx shadcn@latest init
✔ Preflight checks.
✔ Verifying framework. Found Vite.
✔ Validating Tailwind CSS.
✖ Validating import alias.

No import alias found in your tsconfig.json file.
Visit https://ui.shadcn.com/docs/installation/vite to learn how to set an import alias.
```

`tailwind.config.js`:

```js

/** @type {import('tailwindcss').Config} */
export default {
  content: ['./index.html', './src/**/*.{js,jsx}'],
  theme: {
    extend: {},
  },
  plugins: [],
};
```

`vite.config.js`:

```js

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

// https://vite.dev/config/
export default defineConfig({
  plugins: [react()],
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src'),
    },
  },
});
```


### Affected component/components

cli

### How to reproduce

1. Create a new project with vite without ts.
2. try to add cli after adding tailwindcss


### Codesandbox/StackBlitz link

https://github.com

### Logs

_No response_

### System Info

```bash
Nodejs: 20, React: 18.3.1
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: godot
Issue: Godot4.4-dev5: `ClassDB` provides classes AnimationNodeStartState and AnimationNodeEndStatewhere which are not registered
Labels: bug,topic:core,regression,topic:animation

### Tested versions

v4.4.dev5.mono.official [9e6098432]

### System information

all

### Issue description

I iterate over all classes provided by `ClassDB` for testing. Using `ClassDB:get_class_list()`
With Godot4.4.dev5 there is now “AnimationNodeStartState”, “AnimationNodeEndState” there are not documented and cannot be instantiated.

### Steps to reproduce

Can be verified by
```
extends Node

func _ready() -> void:
	prints("AnimationNodeStartState class_exists:", ClassDB.class_exists("AnimationNodeStartState"))
	prints("AnimationNodeStartState can_instantiate:", ClassDB.can_instantiate("AnimationNodeStartState"))

        # compile error
	AnimationNodeStartState.new()
```
output:
```
AnimationNodeStartState class_exists: true
AnimationNodeStartState can_instantiate: true
````
errors:
```
 res://test.gd:7 - Parse Error: Native class GDScriptNativeClass used in script doesn't exist or isn't exposed.
  res://test.gd:7 - Parse Error: Static function "new()" not found in base "GDScriptNativeClass".
```

### Minimal reproduction project (MRP)

n/a
Repository: react
Issue: [React 19] ForwardRef props are not referentially stable, breaking downstream memoizations
Labels: React 19

## Summary

I don't know if this is a known behaviour or a bug, but something that's worth highlighting at least.

ForwardRef components are not deprecated, but they're not perfectly backwards compatible either.

The mere existance of `ref` prop on a ForwardRef component, even if `undefined`, makes the component `props` referentially unstable, breaking a whole host of downstream memoizations.

Reproduction:
https://codesandbox.io/p/sandbox/youthful-faraday-8m98cd?file=%2Fsrc%2FApp.tsx%3A34%2C23

React 18:
https://codesandbox.io/p/sandbox/youthful-faraday-forked-32lrwm?workspaceId=8a8eeabe-fead-479a-a993-25a9868e8015

If it's a known behaviour – please highlight this in the docs. Don't think we would have gone ahead with upgrading yet until some of our dependencies would be supporting React 19, because a whole host of packages (charting, datagrids, etc.) that are performance sensitive, suddenly had performance issues.

If not, it needs some attention, as it has pretty bad performance implications.

I believe a lot of maintainers are not dropping ForwardRef yet, because they think it's perfectly backwards compatible, and it's easier to maintain backwards compatibility for them.
Repository: transformers
Issue: SmolLM is ExecuTorch Compatible
Labels: Feature request,ExecuTorch

### Feature request

### Feature request

Enable SmolLM to ["Export to ExecuTorch"](https://github.com/huggingface/transformers/issues/32253) workflow.

#### Instructions
Instructions of how to enable this model for ExecuTorch:
 1. Export the model to ExportIR. For LLM, to run with performance, typically you will need to export the model with cache. #34101 is a reference of how to export and validate the model. Note that you may run into some export issue and it may require fixes in the modeling code.
 2. Lower the model to ExecuTorch (to generate a .pte file). You will need to clone the github repo and create a recipe to lower the model. For example lowering the to XNNPACK is the simplest way. See the example code here: https://github.com/pytorch/executorch/blob/release/0.4/extension/export_util/export_hf_model.py#L89L106
 3. Run the model with ExecuTorch. You can follow these instructions to build and run the executor runtime for llama: https://github.com/pytorch/executorch/tree/release/0.4/examples/models/llama2#step-4-run-on-your-computer-to-validate

(Optional) Congrats! Once you complete step 1-3, you will be able to run the model on a host machine. Now if you would to go further like making the model faster, smaller, cheaper for your model use-case, you can create more complicated recipes with quantizations and delegations for different HW accelerators. You can find more tutorials on our website, for example to optimize and run the model with Core ML on Apple’s platform: https://pytorch.org/executorch/stable/build-run-coreml.html

### Motivation

See details in #32253

### Your contribution

TBD
Repository: next.js
Issue: `webpackPrefetch: true` magic comment doesn't work in next v15.0.3
Labels: bug,Webpack,Lazy Loading

### Link to the code that reproduces this issue

https://github.com/gavrilikhin-d/repro

### To Reproduce

Test prefetching in production mode
1.  ```bash
    npm install
    npm run build
    npm run start
2. Open http://localhost:3000
3. Open the Network tab in the browser's developer tools
4. Click on the "Load Dynamic Component"
5. See no prefetching happening

### Current vs. Expected behavior

Prefetching should work

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.1.0: Thu Oct 10 21:05:14 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T8103
  Available memory (MB): 8192
  Available CPU cores: 8
Binaries:
  Node: 22.9.0
  npm: 10.8.3
  Yarn: 1.22.22
  pnpm: N/A
Relevant Packages:
  next: 15.0.3 // Latest available version is detected (15.0.3).
  eslint-config-next: N/A
  react: 19.0.0-rc-66855b96-20241106
  react-dom: 19.0.0-rc-66855b96-20241106
  typescript: 5.6.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Lazy Loading, Webpack

### Which stage(s) are affected? (Select all that apply)

next build (local), next start (local)

### Additional context

Broken since `15.0.3-canary.7`, because on `15.0.3-canary.6` it works