sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: storybook
Issue: [Bug]: Vue components with intersection type props don't have "Props" panel in docs
Labels: bug,needs triage

### Describe the bug

Using **intersection types** for for Vue component props **fails to display "Props" section** with controls in docs as if the component didn't have any props at all.


### Reproduction link

https://stackblitz.com/edit/github-jnqruegb?file=src%2Fstories%2FExampleFails.stories.ts,src%2Fstories%2FExampleWorks.stories.ts,src%2Fstories%2Ftypes.ts,src%2Fstories%2FExampleFails.vue,src%2Fstories%2FExampleWorks.vue&preset=node

### Reproduction steps

1. Use reproduction link
2. Check the "Example intersection ❌" docs page (files: `ExampleFails.stories.ts`, `ExampleFails.vue`, `types.ts`)
3. Note there isn't a "Props" section although the component has props defined by intersection type
4. Check the "Example NO intersection ✅" docs page (files: `ExampleWorks.stories.ts`, `ExampleWorks.vue`, `types.ts`)
5. Note there is a "Props" section this time as this component's props are defined as a single type without intersection

### System

```bash
Storybook Environment Info:

  System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 18.20.3 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.2.3 - /usr/local/bin/npm <----- active
    pnpm: 8.15.6 - /usr/local/bin/pnpm
  npmPackages:
    @storybook/addon-essentials: ^8.5.0-alpha.20 => 8.5.0-alpha.20 
    @storybook/addon-interactions: ^8.5.0-alpha.20 => 8.5.0-alpha.20 
    @storybook/addon-onboarding: ^8.5.0-alpha.20 => 8.5.0-alpha.20 
    @storybook/blocks: ^8.5.0-alpha.20 => 8.5.0-alpha.20 
    @storybook/test: ^8.5.0-alpha.20 => 8.5.0-alpha.20 
    @storybook/vue3: ^8.5.0-alpha.20 => 8.5.0-alpha.20 
    @storybook/vue3-vite: ^8.5.0-alpha.20 => 8.5.0-alpha.20 
    storybook: ^8.5.0-alpha.20 => 8.5.0-alpha.20
```

### Additional context

_No response_
Repository: godot
Issue: The ruler tool's most important label renders *behind* another
Labels: bug,topic:editor,usability,topic:2d

### Tested versions

Godot v4.3.stable

### System information

Godot v4.3.stable - macOS 15.1.1 - Vulkan (Mobile) - integrated Apple M3 Max - Apple M3 Max (14 Threads)

### Issue description

Every time I need to measure a distance using the ruler, I'm plagued by this very annoying little thing: the label of the distance that I'm trying to measure is rendered below the label of the height (or the width, for that matter) making it unreadable or hard to read what the distance is I need! Surely this is easy to fix...

![Image](https://github.com/user-attachments/assets/c3d0502f-264b-468b-91a9-0b74d9362f74)


### Steps to reproduce

Use the ruler, dummy

### Minimal reproduction project (MRP)

n/a
Repository: transformers
Issue: [i18n-Chinese] Translating perf_infer_gpu_multi.md to Chinese
Labels: WIP

<!--
Note: Please search to see if an issue already exists for the language you are trying to translate.
-->
I noticed that no one has translated docs/source/en/perf_infer_gpu_multi.md before. Could I translate this to Chinese?
Repository: go
Issue: proposal: archive/tar: support zero-copy reading/writing
Labels: Proposal

### Proposal Details

the container ecosystem (podman,docker) spends its days creating and consuming huge .tar files. There is potential for significant speed-up here by having the tar package use zero-copy file transport.

The change is straightforward, but involves an API change, so opening a proposal.

with the following change, tarring up a 2G file from tmpfs to tmpfs goes from 2.0s to 1.3s  

```diff
diff -u /home/hanwen/vc/go/src/archive/tar/writer.go hacktar/writer.go
--- /home/hanwen/vc/go/src/archive/tar/writer.go	2024-08-22 14:56:29.586690369 +0200
+++ hacktar/writer.go	2024-12-12 15:01:22.150045055 +0100
@@ -9,6 +9,7 @@
 	"fmt"
 	"io"
 	"io/fs"
+	"log"
 	"path"
 	"slices"
 	"strings"
@@ -491,7 +492,7 @@
 //
 // TODO(dsnet): Re-export this when adding sparse file support.
 // See https://golang.org/issue/22735
-func (tw *Writer) readFrom(r io.Reader) (int64, error) {
+func (tw *Writer) ReadFrom(r io.Reader) (int64, error) {
 	if tw.err != nil {
 		return 0, tw.err
 	}
@@ -550,6 +551,16 @@
 }
 
 func (fw *regFileWriter) ReadFrom(r io.Reader) (int64, error) {
+	log.Println("hanwen")
+	if _, ok := fw.w.(io.ReaderFrom); ok {
+		n, err := io.Copy(fw.w, r)
+		if n > fw.nb {
+			return n, fmt.Errorf("read %d bytes, beyond max %d", n, fw.nb)
+		}
+		fw.nb -= n
+		return n, err
+	}
+
 	return io.Copy(struct{ io.Writer }{fw}, r)
 }
 

```
Repository: react
Issue: Bug: initial props will leak if a component renders nested elements, when an outer element never rerenders.
Labels: Status: Unconfirmed

JSX code like this will leak that `something` value:
```ts
<div>
  <SubComponent foo={something} />
</div>
```

As the component and the sub component re-render. That div will never change, and will hold on to that initial prop via `div.__reactProps$[SECRET].children[0].props.foo`.

This is not only unexpected. In cases it can be very difficult to work around.

Here at Framer (http://framer.com) we use a tree like structure that represents the user document. Which potentially can be huge, like 1G or more. Sometimes this has to be reloaded from the server. At that point we cannot afford having the old document lingering around. But it is react that will continue to retain it due to this issue.

React version: 18.2.38 (But has been in react since at least 17.)

See also: https://github.com/facebook/react/issues/25658 (now closed as stale) and other reports filed in the past. I hope that by filing this one, with such a small reproduction, helps someone to dig in and hopefully fix it? 🙏 


## Steps To Reproduce

Click the "next" button in the code example. That switches from a huge array to a large one. But the memory use won't drop.

Link to code example: https://codesandbox.io/p/sandbox/leak-static-element-children-props-forked-zdm83w

Or the simplified version:
```ts
import React from "react";

function SubComponent({ prop }: { prop: number[] }) {
  return <p>array length: {prop.length}</p>;
}

function Test({ prop }: { prop: number[] }) {
  return (
    <div className="holder">
      <SubComponent prop={prop} />
    </div>
  );
}

export default function App() {
  // Initially, a very large state.
  const [state, setState] = React.useState(
    Array.from({ length: 20_000_000 }, () => Math.random())
  );

  return (
    <>
      <Test prop={state} />
      <button
        onClick={() => {
          // Any next state is a lot smaller.
          setState(Array.from({ length: 1_000_000 }, () => Math.random()));
        }}
      >
        Next
      </button>
    </>
  );
}
```


## The current behavior

Leaks memory:
<img width="935" alt="memory-leak" src="https://github.com/user-attachments/assets/8b1339c5-9a23-48d5-b007-559a856f8052" />


## The expected behavior

React internals should not be retaining properties that the code using the library has moved away from.
Repository: langchain
Issue: DOC: Improper `id_key` for MultiVectorRetriever in Multi-RAG cookbooks
Labels: 🤖:docs

### URL

https://github.com/langchain-ai/langchain/blob/master/cookbook/Multi_modal_RAG.ipynb
https://github.com/langchain-ai/langchain/blob/master/cookbook/Multi_modal_RAG_google.ipynb

### Checklist

- [X] I added a very descriptive title to this issue.
- [X] I included a link to the documentation page I am referring to (if applicable).

### Issue with current documentation:

The `id_key` string in the first highlight should be `id_key` or when creating `Document` class (last `id_key` highlight in the image), the metadata should be `doc_id`. 

![image](https://github.com/user-attachments/assets/84ecf057-aed0-4f9d-beea-571daf61f338)

Because of this conflict, anyone following the cookbook will be unable to get any output after querying MultiVectorRetriever.

Please fix or point me to the doc which I should change to fix this issue. I would very much like to contribute.

### Idea or request for content:

_No response_
Repository: godot
Issue: Bug with VisibilityEnabler and AudioStreamPlayer
Labels: bug,topic:core

### Tested versions

The bug is present in the stable 4.3 version and the several 4.4 dev versions that I have tried.

### System information

Godot v4.4.dev6 - Windows 10.0.19045 - Multi-window, 2 monitors - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1060 6GB (NVIDIA; 32.0.15.6636) - AMD Ryzen 7 2700X Eight-Core Processor (16 threads)

### Issue description

Having a scene with this layout:

```
Node2D
-- VisibilityEnabler2D
-- AudioStreamPlayer
```

print this error in the debugger
```
E 0:00:01:0513   can_process: Condition "!is_inside_tree()" is true. Returning: false
  <Source C++>   scene/main/node.cpp:865 @ can_process()
```
~~In the editor version it does not pose a problem, on the other hand in the exported version it causes undesirable behavior (queue_free no longer destroys the scenes concerned by this problem in the project where I had it)~~

**Edit:** After further testing I realized that the bug related to `queue_free` comes from elsewhere, the error exists but it does not seem to create more problems during export.

### Steps to reproduce

- create a scene with a Node2D that has as child a VisibilityEnabler2D and an AudioStreamPlayer
- Launch game
- an error appears in the debugger

### Minimal reproduction project (MRP)

[Minimal Project.zip](https://github.com/user-attachments/files/18113305/Minimal.Project.zip)
Repository: vscode
Issue: Paste slow
Labels: info-needed,typescript

<!-- ⚠️⚠️ 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

<!-- 🪓 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.96.0
- OS Version: macOS 14.7.1

Steps to Reproduce:

1. When I paste into a TypeScript file, it is very slow. It shows a small circular progress indicator for several seconds before finishing the paste

This is a very large repo, but pasting was fast even in this repo before version 1.96.
Repository: ui
Issue: [bug]: 2.1.7 breaks alias resolution
Labels: bug

### Describe the bug

`npx shadcn@latest add sidebar` doesn't work (points to 2.1.7)

`npx shadcn@2.1.6 add sidebar` works as expected.


Here are examples of my config

```json
{
  ...
  "aliases": {
    "components": "@org/package1/components",
    "utils": "@org/package1/lib/utils",
    "ui": "@org/package1/components/ui",
    "lib": "@org/package1/lib",
    "hooks": "@org/package1/hooks"
  },
}

```

```json
{
    "compilerOptions": {
        "paths": {
            "@org/package1/*": ["./src/*"],
        }
    },
    "include": ["src"],
    "references": []
  }
```

with 2.1.6 the components are created with these types of imports

```typescript
import { cn } from "@org/package1/lib/utils"
```

with 2.1.7

```typescript
import { cn } from "@org/lib/utils"
```

### Affected component/components

all

### How to reproduce

with the configs above you can

1. run `npx shadcn@2.1.6 add sidebar` and see how importing utils resolves to
2. run `npx shadcn@2.1.7 add sidebar` and see that's different


### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
macos 15.1.1
Tmux
node 20
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: node
Issue: module.registerHooks() tracking issue
Labels: module,loaders

- [x] Initial proposal: https://github.com/nodejs/node/issues/52219
- [x] Loaders design proposal: https://github.com/nodejs/loaders/pull/198
- [x] Initial implementation: https://github.com/nodejs/node/pull/55698
- [ ] Implement evaluation hook for at least CJS to help use cases like require-in-the-middle, which was supposed to be based on https://github.com/nodejs/loaders/pull/198 but we had some discussions over the collaboration summit/NodeConf EU about changing the hook to be "wrapping around evaluation", not "after evaluation": [WIP](https://github.com/joyeecheung/node/tree/evaluate-hooks)
   - For ESM, there's currently no way for Node.js to hook into the evaluation of child modules, will need to discuss with V8 about it ([issue](https://issues.chromium.org/u/1/issues/384413088)). Allowing mutation of the exports would require a spec change so out of scope for `module.registerHooks()` or Node.js in general
- [ ] Implement link hook for ESM, as proposed in https://github.com/nodejs/loaders/pull/198 to make use cases like import-in-the-middle less hacky
- [ ] `Symbol.dispose` integration (requested in https://github.com/nodejs/node/pull/55698#discussion_r1855211481)
- [ ] Reordering of the documentation when `module.registerHooks()` is battle tested enough and should be preferred over `module.register` to avoid various caveats (requested in https://github.com/nodejs/node/pull/55698#discussion_r1849538179 and https://github.com/nodejs/node/pull/55698#pullrequestreview-2471072027)
- [ ] Advocating it to popular npm packages doing CJS monkey-patching to reduce the overall dependency of CJS loader internals in the ecosystem
- [ ] Support of unknown extensions (learned about it when I was initially proposing https://github.com/nodejs/node/issues/52219)
- [ ] Support `node:builtin?param=val`
- [ ] Figure out how to make search params work with CJS cache
- [ ] Create a polyfill of `module.register()` built on top of `module.registerHooks()`
- [ ] `startGraph` hook proposed in https://github.com/nodejs/loaders/pull/205
Repository: rust
Issue: Lint for returning a pointer to stack memory associated with a local variable
Labels: A-diagnostics,T-compiler

### Code

```Rust
pub fn foo() -> *const i32 {
    let x = 42;
    &x
}
```

### Current output

rustc doesn't currently warn about this.

### Desired output


A warning that this pointer is referencing a local variable and is going to be dangling immediately. E.g.

```text
error: returning a pointer to stack memory associated with a local variable
  --> <source>:12:5
  |
LL|  &x
  |  ^^
```

### Rationale and extra context

This code is very unlikely to be correct, which is exactly why a warning should be emitted. This would be similar to Clang's `-Wreturn-stack-address` warning.

In case of returning a reference, rustc would catch this and emit a compiler error. While it is fine to create such a pointer, it is very unlikely that the code should be written that way.

### Rust Version

```Shell
rustc 1.84.0-nightly (b8c8287a2 2024-11-03)
binary: rustc
commit-hash: b8c8287a229cd79604aa84c25e1235fc78cd5f2e
commit-date: 2024-11-03
host: x86_64-unknown-linux-gnu
release: 1.84.0-nightly
LLVM version: 19.1.3
```

### Anything else?

If this becomes a `Warn` lint it will start warning immediately and potentially break users that configured warnings as errors. So maybe this should be `Allow` for the beginning?
Repository: go
Issue: x/crypto/sha3: TestCSHAKELargeS times out on s390x
Labels: NeedsInvestigation,arch-s390x

### Go version

go version go1.23.2 linux/s390x

### Output of `go env` in your module/workspace:

```shell
GO111MODULE=''
GOARCH='s390x'
GOBIN=''
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='s390x'
GOHOSTOS='linux'
GOINSECURE=''
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPRIVATE=''
GOPROXY='direct'
GOROOT='/usr/lib/golang'
GOSUMDB='off'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/usr/lib/golang/pkg/tool/linux_s390x'
GOVCS=''
GOVERSION='go1.23.2'
GODEBUG=''
GCCGO='gccgo'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
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 -m64 -march=z196 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build429958401=/tmp/go-build -gno-record-gcc-switches
```


### What did you do?

go test ./...

### What did you see happen?

```
[snip]
panic: test timed out after 10m0s
	running tests:
		TestCSHAKELargeS (9m59s)

goroutine 27 [running]:
testing.(*M).startAlarm.func1()
	/usr/lib/golang/src/testing/testing.go:2373 +0x464
created by time.goFunc
	/usr/lib/golang/src/time/sleep.go:215 +0x42

goroutine 1 [chan receive, 9 minutes]:
testing.(*T).Run(0xc00009a680, {0x1f3110, 0x10}, 0x1fec40)
	/usr/lib/golang/src/testing/testing.go:1751 +0x48e
testing.runTests.func1(0xc00009a680)
	/usr/lib/golang/src/testing/testing.go:2168 +0x62
testing.tRunner(0xc00009a680, 0xc00008eca0)
	/usr/lib/golang/src/testing/testing.go:1690 +0x132
testing.runTests(0xc000092180, {0x319cc0, 0xc, 0xc}, {0xc1cee04b5ea3e990, 0x8bb2cd7205, 0x31e7e0})
	/usr/lib/golang/src/testing/testing.go:2166 +0x4b4
testing.(*M).Run(0xc0000a00a0)
	/usr/lib/golang/src/testing/testing.go:2034 +0x704
main.main()
	_testmain.go:95 +0xd8

goroutine 14 [runnable]:
golang.org/x/crypto/sha3.(*asmState).Read(0xc00072c008, {0xc000732000, 0x200003e8, 0x200003e8})
	/home/jcajka/upstream/crypto/sha3/sha3_s390x.go:194 +0x3d6
golang.org/x/crypto/sha3.TestCSHAKELargeS(0xc00009a4e0)
	/home/jcajka/upstream/crypto/sha3/sha3_test.go:470 +0xf8
testing.tRunner(0xc00009a4e0, 0x1fec40)
	/usr/lib/golang/src/testing/testing.go:1690 +0x132
created by testing.(*T).Run in goroutine 1
	/usr/lib/golang/src/testing/testing.go:1743 +0x46e
FAIL	golang.org/x/crypto/sha3	600.056s
[snip]
```

### What did you expect to see?

All tests passing. 
It seems that the failure have been introduced in commit https://github.com/golang/crypto/commit/80ea76eb17c0c52f5d5d04e833d6aeb6b062d81d I have suspicion that it might also be related to the removal of the s390x ASM in https://github.com/golang/crypto/commit/59b5a86796b9d310b31d416f56d93b5ce30da22b In that context of losing the optimized path, have you reached out to the original contributor before removing/disabling it?
Repository: react-native
Issue: Missing '#include "ReactCommon/SchedulerPriority.h"'; 'SchedulerPriority' must be declared before it is used
Labels: Needs: Repro,Newer Patch Available,Needs: Attention,Type: New Architecture

### Description

I'm trying to upgrade the react native version to 0.76.3, but an error occurs in iOS and the build fails. What's the problem?

### Steps to reproduce

1. pod install
2. bundle install && RCT_NEW_ARCH_ENABLED=1 bundle exec pod install
3. Xcode ios build

### React Native Version

0.76.3

### Affected Platforms

Build - MacOS

### Areas

Other (please specify)

### Output of `npx react-native info`

```text
System:
  OS: macOS 14.6.1
  CPU: (12) arm64 Apple M3 Pro
  Memory: 114.44 MB / 36.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 18.19.1
    path: ~/.nvm/versions/node/v18.19.1/bin/node
  Yarn:
    version: 4.2.2
    path: ~/.nvm/versions/node/v18.19.1/bin/yarn
  npm:
    version: 10.2.4
    path: ~/.nvm/versions/node/v18.19.1/bin/npm
  Watchman:
    version: 2024.11.25.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.13.0
    path: /Users/benji/.rbenv/shims/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 24.1
      - iOS 18.1
      - macOS 15.1
      - tvOS 18.1
      - visionOS 2.1
      - watchOS 11.1
  Android SDK: Not Found
IDEs:
  Android Studio: 2024.1 AI-241.18034.62.2412.12266719
  Xcode:
    version: 16.1/16B40
    path: /usr/bin/xcodebuild
Languages:
  Java: Not Found
  Ruby:
    version: 2.7.4
    path: /Users/benji/.rbenv/shims/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 15.0.1
    wanted: 15.0.1
  react:
    installed: 18.3.1
    wanted: 18.3.1
  react-native:
    installed: 0.76.3
    wanted: 0.76.3
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: true
  newArchEnabled: true
```


### Stacktrace or Logs

```text
Missing '#include "ReactCommon/SchedulerPriority.h"'; 'SchedulerPriority' must be declared before it is used
```


### Reproducer

private repository

### Screenshots and Videos

<img width="490" alt="스크린샷 2024-12-13 오전 1 09 34" src="https://github.com/user-attachments/assets/87ad278a-fd0b-44ee-ad41-2cc73f56cbb2" />
<img width="1107" alt="스크린샷 2024-12-13 오전 1 14 12" src="https://github.com/user-attachments/assets/70a85ba4-2422-4b33-b29e-aaf91c4eb750" />
Repository: storybook
Issue: [Documentation]: Improve docs for storybook/@nextjs-experimental-vite
Labels: documentation

### Describe the problem

Could the docs be improved for the Next.js 'With Vite' setup?

I would personally greatly appreciate a template repo as I have not been able to get the right config to get this specific setup working.
I understand this is experimental - but its hard to be a tester if I can't get it running.

@valentinpalkovic Who I think is the expert on this plugin 😁 

### Additional context

Just for clarity of my goals-
My final desired stack is a monorepo of Storybook + UI library + tailwindcss (using turborepo).  With the UI components finally consumed in a Next.js app in an external repo.
Repository: godot
Issue: Scene takes ~10 seconds longer on startup if another Godot Instance or the Godot Project Manager is open in the background
Labels: bug,topic:editor,performance

### Tested versions

Godot v4.3.stable (77dcf97d8)



### System information

Godot v4.3.stable (77dcf97d8) - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3070 Laptop GPU (NVIDIA; 32.0.15.6614) - 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz (16 Threads)

### Issue description

If the project manager is open, starting the main or a custom scene takes an extra 10 seconds. 

Here is a comparison video:
Left shows me running a project.
Right, starting the same project but the project manager is also open in the background

https://github.com/user-attachments/assets/168d5940-d833-450a-a49b-44c36d31f405

This is the same if another Instance of the Godot Editor is open in the background. But I found it interesting that the project manager already causes this issue.

### Steps to reproduce

Open a Godot Project.
Open a new Godot Project manager. 
Run your project. 

### Minimal reproduction project (MRP)

N/A