sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: next.js
Issue: `“use cache”` does not serialize the serializable value (but `unstable_cache` serializes)
Labels: bug,dynamicIO

### Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/keen-cloud-gggnf4?embed=1

### To Reproduce

unstable_cache serializes everything and everything works.
All logs are output to the console

1. Try entering mail in the field with unstable_cache
2. Try to enter mail again in the field with unstable_cache and look at the logs (make sure there are no errors)
3. Try to enter the mail again in the “use cache” field and make sure that the error pops up.
```
Error: Only plain objects, and a few built-ins, can be passed to Client Components from Server Components. Classes or null prototypes are not supported.
  [{}]
   ^^
    at stringify (<anonymous>)
Error while saving cache key: ["development","c04d358ed385c8992fa9fcf45e6ff96556234302f3",[{"ctx":{},"type":"query","path":"user.getByEmail","rawInput":"oxmaster@gmail.com","meta":"$undefined","input":"oxmaster@gmail.com","next":"$T"}]] Error: Only plain objects, and a few built-ins, can be passed to Client Components from Server Components. Classes or null prototypes are not supported.
  [{}]
   ^^
```


BONUS:
1. Try replacing `<main>` in `page.tsx` with a fragment (empty tag) and make sure the error does not correspond to reality

### Current vs. Expected behavior

Current: error
Expected: no error

### Provide environment information

```bash
Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Pro
  Available memory (MB): 16320
  Available CPU cores: 6
Binaries:
  Node: 22.10.0
  npm: 10.9.0
  Yarn: N/A
  pnpm: 9.12.2
Relevant Packages:
  next: 15.0.4-canary.22 // Codesandbox: (15.0.4-canary.23)
  eslint-config-next: 15.0.0
  react: 19.0.0-rc-380f5d67-20241113
  react-dom: 19.0.0-rc-380f5d67-20241113
  typescript: 5.7.1-rc
Next.js Config:
  output: standalone
```


### Which area(s) are affected? (Select all that apply)

dynamicIO

### Which stage(s) are affected? (Select all that apply)

next dev (local)

### Additional context

An unexplained error is displayed when trying to serialize a value. But `“use cache”` cannot serialize it, although `unstable_cache` serializes everything fine
Repository: go
Issue: proposal: net/http: add methods to Request for setting and getting Bearer tokens
Labels: Proposal

### Proposal Details

I propose the addition of the following two methods:

```go
// SetBearerAuth, if the provided token is valid, sets the request's
// Authorization header to use the Bearer authentication scheme with that token
// and returns true.
// Otherwise, it leaves the request unchanged and returns false.
// See RFC 6750, Section 2.1.
func (*Request) SetBearerAuth(token string) bool

// BearerAuth returns the token provided in the request's
// Authorization header, if the request uses the Bearer authentication scheme.
func (r *Request) BearerAuth() (token string, ok bool)
```

---

Those methods parallel ones related to HTTP Basic Authentication already exported by net/http:

- https://pkg.go.dev/net/http#Request.SetBasicAuth
- https://pkg.go.dev/net/http#Request.BasicAuth

At first, you may think that the logic for getting/setting a Bearer token is so trivial that it doesn't deserve its own methods in the standard library. However, I've come to realise that many implementations out there suffer from correctness issues and/or performance issues; here are two examples (among others):

- [Many](https://github.com/search?q=language%3AGo+%2F%22Bearer+%22%2F+%2F%5C.Header%5C.Get%5C%28%22Authorization%22%5C%29%2F&type=code) implementations [mistakenly](https://auth0.com/blog/the-bearer-token-case/) parse "Bearer" as case-sensitive, which may cause interoperability issues.
- [Many](https://github.com/search?q=language%3AGo+%2Fhttp%5C.Request%2F+%2Fstrings%5C.Split%5C%28.*%2C+%22+%22%5C%29%2F+%2F%5C.Header%5C.Get%5C%28%22Authorization%22%5C%29%2F&type=code) implementations naively rely on [`strings.Split`](https://pkg.go.dev/strings#Split), thereby facilitating [denial-of-service attacks](https://owasp.org/www-community/attacks/Denial_of_Service); see also [this tangentially related issue](https://github.com/rs/cors/issues/170) (now resolved) in [github.com/rs/cors](https://github.com/rs/cors).

Moreover, and despite my lack of data to back up the following claim, I believe that Bearer is one of the most popular authentication scheme nowadays (likely even more popular than Basic), given the prominent role it plays in OAuth 2.x and OpenID Connect. Therefore, the logic required for parsing a request's Authorization header that uses Bearer arguably deserves to be enshrined in the standard library.

[This playground](https://go.dev/play/p/X3VaUBsWgpm) contains a standalone implementation as well as a test suite. For convenience, `SetBearerAuth` and `BearerAuth` are presented there as package-level functions rather than as `*Request` methods.
Repository: bitcoin
Issue: Add support for creating v3 raw transactions in `createrawtransaction` RPC
Labels: Feature

### Please describe the feature you'd like to see added.

Currently, `createrawtransaction` RPC creates only v2 raw transaction, i.e. the first byte of the serialised transaction hex is `02`. It'd be helpful for the RPC to conditionally create V3 raw transactions if such intent is passed in the arguments of the RPC call.

### Is your feature related to a problem, if so please describe it.

_No response_

### Describe the solution you'd like

- A new argument to the RPC call can be passed that allows the user to create v3 raw transactions conditionally. It can be either a `bool isV3` or `int version` (with sanity checks) whichever is most compatible with the current RPC nomenclature.
- Default transaction version need not change as part of this solution.

### Describe any alternatives you've considered

_No response_

### Please leave any additional context

Need to double check for conformity of v3 raw transactions with other RPCs. Though I didn't notice any issue with signing and broadcasting v3 transactions after manually updating the hex during testing TRUC transactions while coming up with [V28 Testing Guide](https://github.com/bitcoin-core/bitcoin-devwiki/wiki/28.0-Release-Candidate-Testing-Guide#2-v3-transactions-truc).
Repository: PowerToys
Issue: Fancyzones layout - Snap zone to existing window on the desktop.
Labels: Needs-Triage

### Description of the new feature / enhancement

A method of editing a zone to exactly match the edges od a window on the desktop.

Maybe key combo while dragging zone highlights a window while hovering over it, then Dropping the Zone snaps it to the dimensions of that window.

Maybe an option to snap the edge of a zone to the window edges of Desktop windows.

### Scenario when this would be used?

I have a specific app that I sized to the exact size that I need.
I cannot get a Zone to exactly match the window size.

The dimensions reported by Fanchzones does not match the same dimensions of the desktop, maybe due to scaling of the desktop.

### Supporting information

_No response_
Repository: rust
Issue: `AtomicUsize::from_mut` has incorrect alignment requirements in docs
Labels: E-easy,E-help-wanted,A-docs,T-libs

### Location

[`core::sync::atomic::AtomicUsize::from_mut`](https://doc.rust-lang.org/nightly/core/sync/atomic/struct.AtomicUsize.html#method.from_mut)
[`core::sync::atomic::AtomicIsize::from_mut`](https://doc.rust-lang.org/nightly/core/sync/atomic/struct.AtomicIsize.html#method.from_mut)

### Summary

The documentation for [`AtomicUsize::from_mut`](https://doc.rust-lang.org/nightly/core/sync/atomic/struct.AtomicUsize.html#method.from_mut) claims that it's only available when `usize` has alignment 8, but in reality it's available when `usize` has alignment equal to its size (AFAICT), which is different on non-64-bit platforms. For example, this code compiles on 32-bit Linux:
```rust
#![feature(atomic_from_mut)]

use std::sync::atomic::AtomicUsize;

pub fn main(){
    let mut x: usize = 0;
    assert_eq!(std::mem::size_of_val(&x), 4);
    let _y: &mut AtomicUsize = AtomicUsize::from_mut(&mut x);
}
```
[Godbolt](https://godbolt.org/z/jaEev1Wos)

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: deno
Issue: Vitest Coverage v8 & Istanbul Providers Broken
Labels: debugger,testing,node compat

Relates to #23882.
Version: Deno 2.1.1

The v8 provider returns 0 for everything.
The istanbul provider is just wrong: 
<img width="977" alt="Screenshot 2024-11-22 at 7 25 54 AM" src="https://github.com/user-attachments/assets/7cf53583-32ba-47ca-a10f-095c1f32ad32">
<img width="492" alt="Screenshot 2024-11-22 at 7 26 30 AM" src="https://github.com/user-attachments/assets/e532eec3-ce1c-4bee-ac13-b590d5ad82fc">
<img width="552" alt="Screenshot 2024-11-22 at 7 28 21 AM" src="https://github.com/user-attachments/assets/71ab738e-c354-402f-b681-2d2291a33edd">

I think instanbul is mostly just mapping the line #s wrong, but it generally looks accurate-ish.
Repository: electron
Issue: Exiting GPU process due to errors during initialization
Labels: platform/linux,bug :beetle:

### Preflight Checklist

- [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [x] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

33.2.0

### What operating system(s) are you using?

Ubuntu

### Operating System Version

20.04.6

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

No error being outputted in the console

### Actual Behavior

When running `electron .` in the project folder, this is the output:

```
> cos-wrapper@1.5.0 start
> electron .

[8642:1122/134210.699969:ERROR:viz_main_impl.cc(181)] Exiting GPU process due to errors during initialization
```


### Testcase Gist URL

_No response_

### Additional Information

The system is a freshly created Ubuntu VM connecting using remote desktop.
The app is based on this repo: https://github.com/serialport/electron-serialport/

The application had been built initially (4 years ago) on a Windows PC that then had been formatted, and I have been asked to try to create a new building environment. I started from scratch using the repo mentioned above and imported the logic of the app to avoid issues caused by using obsolete versions of the libraries used.

The weird thing is that the window opens and load the content as expected (just loading a URL). I am not sure what this error is even referring to, as the message doesn't give more details.

Can someone at least explain what this error is about so I can further investigate?
Repository: rust
Issue: Confusing error message when using re-exported struct [E0423]
Labels: A-diagnostics,T-compiler

### Code

```Rust
pub use my_mod::MyStruct; // this pub use is causing the problem

mod my_mod {
    #[derive(Debug)]
    pub struct MyStruct(u32);

    mod my_sub_mod {
        use crate::MyStruct; // import the rexported struct

        fn my_func() {
            let s = MyStruct(42);
            println!("MyStruct: {:?}", s);
        }
    }
}
```

### Current output

```Shell
error[E0423]: expected function, tuple struct or tuple variant, found struct `MyStruct`
  --> src/lib.rs:11:21
   |
11 |             let s = MyStruct(42);
   |                     ^^^^^^^^

For more information about this error, try `rustc --explain E0423`.
```

### Desired output

```Shell
Either having no error or the error saying the import is bad
```

### Rust Version

```Shell
rustc 1.81.0
```

### Anything else?

This is a really confusing message that is not helping
Repository: next.js
Issue: Relay multi-project configuration doesn't work
Labels: bug

### Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/crimson-frog-go8s7s

### To Reproduce

Provide a Relay configuration that makes use of the multi-project format:

```js
module.exports = {
    root: ".",
    // For simplicity I'm defining just one project but it doesn't make any difference
    sources: {
      ".": "repro",
    },
    excludes: ["**/node_modules/**", "**/__mocks__/**", "**/__generated__/**"],
    projects: {
      "repro": {
        output: "__generated__",
        language: "typescript",
        schema: "schema.graphql",
      },
    },
  };
```

Start the app (both dev mode or build) and observe the Relay integration doesn't work.

### Current vs. Expected behavior

 ```
 ⚠ Invalid next.config.mjs options detected: 
 ⚠     "compiler.relay.src" is missing, expected string
 ⚠ See more info here: https://nextjs.org/docs/messages/invalid-next-config
 ```

### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
  Available memory (MB): 4102
  Available CPU cores: 2
Binaries:
  Node: 20.9.0
  npm: 9.8.1
  Yarn: 1.22.19
  pnpm: 8.10.2
Relevant Packages:
  next: 15.0.4-canary.23 // Latest available version is detected (15.0.4-canary.23).
  eslint-config-next: N/A
  react: 19.0.0-rc-380f5d67-20241113
  react-dom: 19.0.0-rc-380f5d67-20241113
  typescript: 5.3.3
Next.js Config:
  output: N/A
Done in 3.69s.
```


### Which area(s) are affected? (Select all that apply)

Not sure

### Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local)

### Additional context

_No response_
Repository: terminal
Issue: Request: "Select color scheme..." mouse-hover should provide color-scheme preview
Labels: Help Wanted,Product-Terminal,Issue-Task,Needs-Tag-Fix,Area-CmdPal

### Description of the new feature

This is a tiny quality-of-life improvement request:

CTRL + SHIFT + P   ----> "Select color scheme..."

We see now see a dropdown of all our color schemes.
The UP and DOWN arrows trigger a preview of the highlighted color-scheme.
But hovering the mouse over a color-scheme ...only results in a 'gentle highlight', no preview.

My request: hovering over a color-scheme should also trigger a preview in the current tab.

This may seem trivial, but it would be much appreciated.


### Proposed technical implementation details

_No response_
Repository: fucking-algorithm
Issue: Switching language to English has no effect
Labels: chrome-extension-bug

**Describe the bug**
I have tried switching the language to English in the settings but it has no effect. Even after refreshing, everything is in Chinese.  I have tried quitting Chrome and trying again, but still there is no English.

To clarify, the English explanations do appear on Leetcode, but the extension menu itself is always in Chinese.

**Screenshots**
<img width="414" alt="image" src="https://github.com/user-attachments/assets/5b166f75-68b9-46d8-a117-ec032f90eb9e">

**Platform**
Chrome on MacOS.
Repository: vscode
Issue: Copilot onActivated event
Labels: chat

<!-- ⚠️⚠️ 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. -->
We use the following check to decide whether or not to display copilot-related CTAs:

```
vscode.extensions.getExtension('github.copilot-chat')?.isActive
```

This check doesn't properly work through right after our participant extension startup. It seems that it takes time to activate the copilot and it happens after our extension is up and running. Is there a way to listen for the activation of `github.copilot-chat`?

I also tried `vscode.extensions.onDidChange` to hide copilot-related CTAs when a user disables the copilot chat extension, but it looks like the event doesn't happen on disabling, only when you enable the extension.
Repository: vscode
Issue: Missed GTK window (min-max-close) control icons/buttons
Labels: upstream,linux,electron,under-discussion,titlebar


Type: <b>Feature Request</b>

Window close, minimize and maximize buttons (icon shape) with the new look in VSCode Insider latest update on ubuntu24 - automatically changed from GTK window control icons appearance to windows system looking ones.

VS Code version: Code - Insiders 1.96.0-insider (69acde7458f428f0e6869de8915c9dd995cdda1a, 2024-11-21T05:04:38.064Z)
OS version: Linux x64 6.8.0-49-generic
Modes:


<!-- generated by issue reporter -->![Image](https://github.com/user-attachments/assets/cdadf498-97bf-4064-8149-6edc946f9eb8)
Repository: go
Issue: x/vuln/cmd/govulncheck: unmask module versions in SBOM testdata
Labels: vulncheck or vulndb

Go will soon release a feature where versions of the main module and dependencies built from an untagged or dirty commit produce a valid Go version. Before, those versions were `(devel)`. The new change is already at go tip, making some of the tests fail that expect `(devel)` version. We currently mask the dirty versions with `(devel)` too, but when all builders' go versions have this feature, we should just use the actual version.
Repository: godot
Issue: BBCode italic tag can override enclosing font size tag
Labels: bug,topic:gui

### Tested versions


 - Reproducible in v4.3.stable.official [77dcf97d8]

### System information

Godot v4.3.stable - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1650 (NVIDIA; 32.0.15.6094) - Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz (16 Threads)

### Issue description

Applying BBCode tags for italics inside of a font size change can undo the enclosing font size tag's effect.  On the left of each image below is the Godot Inspector showing the text I placed into a RichTextLabel and on the right of the same image is that same RichTextLabel running "in-game" (using Run Current Scene on just the label).

**Example 1: Two paragraphs of text rendered exactly as expected, no font size changes, no italics.**

![Image](https://github.com/user-attachments/assets/485114ba-7b41-4b9c-9ef9-a5caac2ac225)

**Example 2: Two paragraphs of text rendered exactly as expected, one font size change wrapped around both paragraphs, no italics.**

![Image](https://github.com/user-attachments/assets/5bb9047f-c186-453c-a033-df5b0a264261)

**Example 3: Two paragraphs of text manifesting the bug, because the introduction of italics in paragraph two has undone the font size that should still be in effect.**

![Image](https://github.com/user-attachments/assets/af7c533c-3437-42ca-a3b4-6601c57f86b3)

Note that the only change from Example 2 to Example 3 was the introduction of the `[i]...[/i]` tags.


### Steps to reproduce

- Open a new project.
- Create a single scene whose root node is a RichTextLabel.
- Resize the label to be large enough to see its content.
- Enable BBCode for the label in the Inspector.
- Enter in the Text field of the label any of the example texts you see in the images above.
- Use F6 to run the scene and observe the behavior shown in the images above.

This can be expedited use the MRP I attach below.

### Minimal reproduction project (MRP)

[mrp-for-bbcode-bug-report.zip](https://github.com/user-attachments/files/17872469/mrp-for-bbcode-bug-report.zip)
Repository: deno
Issue: Deno.serve: request.signal is aborted even though the response finished successfully
Labels: ext/http,triage required 👀

Version: Deno 2.1.1

Example:

```ts
Deno.serve((req: Request) => {
    req.signal.addEventListener("abort", () => {
        console.log("Request aborted on the server side:", req.signal.aborted);
    });

    return new Response("Hello, World!");
});

const constructor = new AbortController();
const { signal } = constructor;

const res = await fetch("http://localhost:8000", { signal });
console.log(await res.text());

console.log("Request aborted on the client side:", signal.aborted);
```

Prints:

```
Request aborted on the server side: true
Hello, World!
Request aborted on the client side: false
```

This is awkward, and may even lead to potential bugs.

Bun doesn't seem to have this problem.
Repository: vscode
Issue: Editor GPU: Move decoration style parsing and validation into ViewGpuContext
Labels: plan-item,editor-gpu

This should move into ViewGpuContext so lines with inline decorations that aren't supported don't make it that far:

https://github.com/microsoft/vscode/blob/27687b2229467b1409b51a30f9bd024758feec7e/src/vs/editor/browser/gpu/fullFileRenderStrategy.ts#L377-L394

Probably blocked on https://github.com/microsoft/vscode/issues/234473
Repository: vscode
Issue: Editor GPU: Avoid invalidating lines and clearing render data when we can avoid it
Labels: plan-item,perf,editor-gpu

Currently the up to date line cache and render buffer is cleared more aggressively than should be necessary:

https://github.com/microsoft/vscode/blob/27687b2229467b1409b51a30f9bd024758feec7e/src/vs/editor/browser/gpu/fullFileRenderStrategy.ts#L140-L177
Repository: ui
Issue: [feat]: Add iconLibrary documentation
Labels: area: request

### Feature description

Documentation for the new property can be added to the components.json page, please.

Page:
https://ui.shadcn.com/docs/components-json

Property:
"iconLibrary": "lucide"

### Affected component/components

_No response_

### Additional Context

Additional details here...

### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues and PRs