sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Crash in `render_pipeline_create` in a build with double enabled
Labels: bug,topic:rendering,needs testing,crash,regression

### Godot version

v4.2.dev.custom_build.90f90cbcb

### System information

Fedora, RX 590

### Issue description

If i try to open any project or create a new project in a build with doubles enabled i get this crash

```
[1] /lib64/libc.so.6(+0x3ea00) [0x7ffb96a3ea00] (??:0)
[2] /usr/lib64/libvulkan_radeon.so(+0xdf889) [0x7ffb7a0df889] (??:0)
[3] /usr/lib64/libvulkan_radeon.so(+0xe96ca) [0x7ffb7a0e96ca] (??:0)
[4] /usr/lib64/libvulkan_radeon.so(+0xecb98) [0x7ffb7a0ecb98] (??:0)
[5] RenderingDeviceVulkan::render_pipeline_create(RID, long, long, RenderingDevice::RenderPrimitive, RenderingDevice::PipelineRasterizationState const&, RenderingDevice::PipelineMultisampleState const&, RenderingDevice::PipelineDepthStencilState const&, RenderingDevice::PipelineColorBlendState const&, BitField<RenderingDevice::PipelineDynamicStateFlags>, unsigned int, Vector<RenderingDevice::PipelineSpecializationConstant> const&) (/run/media/qbie/WorkData/Projects/godot/drivers/vulkan/rendering_device_vulkan.cpp:6527)
[6] RendererCanvasRenderRD::RendererCanvasRenderRD() (/run/media/qbie/WorkData/Projects/godot/servers/rendering/renderer_rd/renderer_canvas_render_rd.cpp:2559 (discriminator 9))
[7] RendererCompositorRD::RendererCompositorRD() (/run/media/qbie/WorkData/Projects/godot/servers/rendering/renderer_rd/renderer_compositor_rd.cpp:306 (discriminator 2))
[8] RendererCompositorRD::_create_current() (/run/media/qbie/WorkData/Projects/godot/./servers/rendering/renderer_rd/renderer_compositor_rd.h:138)
[9] RendererCompositor::create() (/run/media/qbie/WorkData/Projects/godot/servers/rendering/renderer_compositor.cpp:45)
[10] RenderingServerDefault::RenderingServerDefault(bool) (/run/media/qbie/WorkData/Projects/godot/servers/rendering/rendering_server_default.cpp:413 (discriminator 2))
[11] Main::setup2() (/run/media/qbie/WorkData/Projects/godot/main/main.cpp:2298)
[12] Main::setup(char const*, int, char**, bool) (/run/media/qbie/WorkData/Projects/godot/main/main.cpp:2029)
[13] /run/media/qbie/WorkData/Projects/godot/bin/godot.linuxbsd.editor.dev.double.x86_64(main+0xff) [0x29d0b95] (/run/media/qbie/WorkData/Projects/godot/platform/linuxbsd/godot_linuxbsd.cpp:62)
[14] /lib64/libc.so.6(+0x29510) [0x7ffb96a29510] (??:0)
[15] /lib64/libc.so.6(__libc_start_main+0x89) [0x7ffb96a295c9] (??:0)
[16] /run/media/qbie/WorkData/Projects/godot/bin/godot.linuxbsd.editor.dev.double.x86_64(_start+0x25) [0x29d09d5] (??:?)
```

### Steps to reproduce

Build godot with double_precision=yes, create new project (or open any project), it crashes

I only have forward+ projects, didn't test mobile renderer or gles3. Since it's a vulkan issue i imagine gles3 would work fine.

### Minimal reproduction project

See above
Repository: rust
Issue: rustdoc: synthetic blanket impls: hang / very long compiletimes with complex mutually recursive structs involving many projections
Labels: T-rustdoc,A-trait-system,I-compiletime,T-compiler,C-bug,A-synthetic-impls,S-has-mcve

### Problem

When I run `cargo doc`, it never terminates. Instead, it uses 100% of a CPU indefinitely.

### Steps

1. git clone https://github.com/gents83/wgpu.git
2. cd wgpu
3. git checkout 91d872e1
4. cargo +nightly doc -p wgpu-core

That final command never seems to exit.

### Notes

I'm running Fedora 38 and cargo 1.73.0-nightly (7c3904d6c 2023-08-14).
Repository: opencv
Issue: Different coefficient in cubic resize
Labels: feature,category: gpu/cuda (contrib),RFC

### Describe the feature and motivation

I'm not sure that it is a bug or feature.

When resizing with cubic interpolation:
- `resize` use `A = -0.75` in [`interpolateCubic`](https://github.com/opencv/opencv/blob/4.x/modules/imgproc/src/resize.cpp#L908)
- `cuda::device::resize` use equivalent `A = -0.5` in [`bicubicCoeff`](https://github.com/opencv/opencv/blob/4.x/modules/core/include/opencv2/core/cuda/filters.hpp#L139C1-L155C1)

Should we keep this inconsistency?

If we change cuda `bicubicCoeff`, then some tests will fail, including but not limit to `test_gapi` / `perf_gapi` / `perf_cudawarp` / `perf_superres`, which call resize internally and compare the result with prepared pre-computed data / file in `opencv_extra`.

And, the coordinate computation use [`half pixel`](https://github.com/onnx/onnx/blob/v1.14.0/docs/Operators.md#Resize) in [`resize`](https://github.com/opencv/opencv/blob/4.x/modules/imgproc/src/resize.cpp#L3343) but `asymmetric` in [`cuda::device::resize`](https://github.com/opencv/opencv_contrib/blob/4.x/modules/cudawarping/src/cuda/resize.cu#L116C1-L118C1) / [`cuda::device::resize_linear`](https://github.com/opencv/opencv_contrib/blob/4.x/modules/cudawarping/src/cuda/resize.cu#L81C1-L83C1), which makes the results have a translation by `0.5 × (scale - 1)`.

Also, fixing this will cause some existing tests failed, especially `perf_*`. Anyway, should we keep this inconsistency? If yes, maybe it's better to document it?


### Additional context

_No response_
Repository: godot
Issue: Polygon2D disappearing
Labels: bug,topic:rendering,confirmed,topic:2d

### Godot version

4.1

### System information

Godot v4.1.1.stable - Windows 10.0.19045 - Vulkan (Compatibility) - NVIDIA GeForce RTX 3050 (NVIDIA; 31.0.15.3179) - AMD Ryzen 7 5700X 8-Core Processor (16 Threads)

### Issue description

In my game I have a feature where right clicking adds a point to my polygon node but I keep running into issues where the polygon disappears but then reappears seemingly randomly when you have points intersecting or going to far away from the last point. My project is at https://tntredstone.itch.io/world-creator, and my source code is at https://github.com/TNTRedstone/world-creator

### Steps to reproduce

1. Make a new 2D Godot project
2. Add a polygon2D node
3. Add this script: `
extends Polygon2D
func _input(_event):
	if Input.is_mouse_button_pressed(MOUSE_BUTTON_RIGHT):
               polygon = polygon + PackedVector2Array([get_local_mouse_position()])
 `

### Minimal reproduction project

[MRPolygon2Derror.zip](https://github.com/godotengine/godot/files/12360705/MRPolygon2Derror.zip) (new MRP)
Repository: storybook
Issue: [Bug]: React + Storybook + Vite example component Page.css can leak
Labels: bug,good first issue,help wanted,sev:S4

### Describe the bug

The example src/stories/Page.tsx component includes this at the top:

```tsx
import React from 'react';

import { Header } from './Header';
import './page.css';
```

The contents of `page.css` are:
```
section {
  font-family: 'Nunito Sans', 'Helvetica Neue', Helvetica, Arial, sans-serif;
  font-size: 14px;
  line-height: 24px;
  padding: 48px 20px;
  margin: 0 auto;
  max-width: 600px;
  color: #333;
}

section h2 {
  font-weight: 700;
  font-size: 32px;
  line-height: 1;
  margin: 0 0 4px;
  display: inline-block;
  vertical-align: top;
}
// Omitted for brevity
```

I've just noticed that my own component's story which uses `<section>` was picking up those styles:
Head:
<img width="911" alt="image" src="https://github.com/storybookjs/storybook/assets/12085479/eb352193-6f5d-4b12-b348-4c26114e9465">

Component affected:
<img width="1444" alt="image" src="https://github.com/storybookjs/storybook/assets/12085479/fd701f68-4bae-4adb-a95c-cb160658cc1a">

I can just delete the examples, and all is well. Not a high priority problem. It does raise the question though, why would that be required? Can that initial import be a scoped `page.module.css` to avoid having to remove docs that are helpful to new developers in the future?

### To Reproduce

Interestingly, I can't reproduce using a basic [stack blitz](https://stackblitz.com/edit/github-dhssxd?file=src%2Fcomponents%2FComponentA%2FComponentA.tsx), even clicking through to Page and back to ComponentA doesn't have the effect. It's reliable on my local though.

### System

```shell
Environment Info:

  System:
    OS: macOS 13.4
    CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
  Binaries:
    Node: 18.13.0 - /usr/local/bin/node
    Yarn: 1.22.19 - ~/.yarn/bin/yarn
    npm: 9.5.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 115.0.5790.170
    Safari: 16.5
  npmPackages:
    @storybook/addon-essentials: ^7.2.1 => 7.2.1 
    @storybook/addon-interactions: ^7.2.1 => 7.2.1 
    @storybook/addon-links: ^7.2.1 => 7.2.1 
    @storybook/blocks: ^7.2.1 => 7.2.1 
    @storybook/react: ^7.2.1 => 7.2.1 
    @storybook/react-vite: ^7.2.1 => 7.2.1 
    @storybook/testing-library: ^0.2.0 => 0.2.0
```


### Additional context

_No response_
Repository: kubernetes
Issue: OpenAPI loading double-buffering (or triple-buffering) 
Labels: sig/api-machinery,kind/feature,triage/accepted

### What would you like to be added?

While inspecting the code for https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/client-go/discovery/cached/disk/cached_discovery.go, it appears that we buffer the OpenAPI response _twice_ as a []byte, once in io.ReadAll when we are reading it for parsing, and once in the HTTP caching layer.

Arguably we need 3x the memory because our json parser is not streaming, so we retain the []byte while we unmarshal into the OpenAPI types.

Given we are writing it to disk anyway, we should probably just write to a temp file.

### Why is this needed?

This is inefficient, and is visible in memory profiles.

I think we can also eliminate two library dependencies from our stack (possibly even 3).: https://github.com/gregjones/httpcache is archived.  diskv has not had many updates in years.  diskv pulls in google/btree, so we might also be able to eliminate that.
Repository: go
Issue: x/tools/gopls: triage process for feature requests
Labels: gopls,Tools

This is a meta issue.

We've had limited bandwidth for ad-hoc feature requests in gopls for the last 6-8 months, due to some fundamental work on scalability landed in v0.12.x and v0.13.x.

Meanwhile, we have an active triage rotation for bugs, but do not have a similar process for features.  We should revisit our [backlog](https://github.com/golang/go/issues?q=is%3Aissue+is%3Aopen+label%3Agopls+label%3AFeatureRequest) of feature requests to re-prioritize and identify good contribution opportunities. We should also endeavor to close feature requests that we're unlikely to ever implement, rather than leaving them in limbo.

Tentative proposal:
- Create a public GitHub project to sort feature requests into categories:
  - **Planned**: features that we actively plan to do ourselves. Most of these should be associated with a release milestone.
  - **Help Wanted**: features that we don't immediately plan to do ourselves, but would be happy to accept as contributions.
  - **Future**: features that we'd like to do eventually, but which don't make good contribution opportunities.
  - **Likely Decline**: features that we probably won't ever do. We should make a comment on each of these indicating their status (in addition to sorting them to this category) so that folks have an opportunity to disagree.
  - **Untriaged**: issues that we haven't discussed yet.
- Actively sort incoming feature requests into these categories during our regular bug triage meeting, and meet ~quarterly to refresh the project board.

CC @golang/tools-team
Repository: godot
Issue: OptionButton is messed with Project Settings of `Always On Top`, `Transparent`, `Embed Subwindows`, `Transparent Background`
Labels: bug,topic:core,topic:porting,topic:gui

### Godot version

v4.2.dev3.official.013e8e3af

### System information

Windows 11, Vulkan API 1.3.205 - Forward+ - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce RTX 3060 Ti

### Issue description

some combinations of settings of `Always On Top`, `Transparent`, `Embed Subwindows`, `Transparent Background` will cause weired behavior of OptionButton.

1. Options can't be selected:
- `Always On Top` = true
- `Transparent` = true
- `Embed Subwindows` = false
- `Transparent Background` = true
![image](https://github.com/godotengine/godot/assets/42859362/d897ce24-123f-4eed-880c-8a4040935f95)
2. Options doesn't show up:
- `Always On Top` = true
- `Transparent` = false
- `Embed Subwindows` = false
- `Transparent Background` = false
![image](https://github.com/godotengine/godot/assets/42859362/0518573e-7882-4543-9082-f44de8b0ad04)


### Steps to reproduce

open minimal reproduction project and change project settings and run project.

![image](https://github.com/godotengine/godot/assets/42859362/61d00955-3ff1-4c7d-a9ab-d1a8b6e26376)
![image](https://github.com/godotengine/godot/assets/42859362/90e85e50-71ff-419e-b163-4f39e43cafa3)


### Minimal reproduction project

[test for optionbutton.zip](https://github.com/godotengine/godot/files/12361584/test.for.optionbutton.zip)
Repository: flutter
Issue: Caches in windows does not seem to be working correctly
Labels: team-infra,P3,triaged-infra

In windows even after mounting a cache the checkout step is taking 4+ minutes. Here is an example:

https://luci-milo.appspot.com/raw/build/logs.chromium.org/flutter/led/godofredoc_google.com/967ec1746872ef774ed681cdbdd7140eb015ef578998fd979d0a62624ad747b2/+/build.proto
Repository: godot
Issue: Godot headless prints several "ERROR: VisualServer attempted to free a NULL RID."
Labels: bug,topic:rendering

### Godot version

v3.6.beta2 [68c507f59]

### System information

Manjaro XFCE and Ubuntu Focal (docker)

### Issue description

When running the Linux x64 headless build, Godot prints this error message several times when closing:

```
ERROR: VisualServer attempted to free a NULL RID.
   at: free (servers/visual/visual_server_raster.cpp:69)
```

It does not crash (non-zero exit), though.

### Steps to reproduce

Download Godot 3.6 beta 2's Linux x64 headless build and run the script below with:

```bash
godot -s example.gd
```

Also seems to happen in 3.6 beta 3. Did not test in beta 1, but was not happening as far as 3.5.1.

### Minimal reproduction project

```gdscript
extends SceneTree

func _init():
	quit()
```
Repository: godot
Issue: Can't get to the script (C# object) instance from EditorInspectorPlugin code
Labels: bug,topic:dotnet

### Godot version

4.1.rc3.mono.official [cdd2313ba]

### System information

N/A

### Issue description

Looks like EditorInspectorPlugin's virtual methods (_CanHandle() _ParseBegin() _ParseEnd() etc.) GodotObject parameter (@object) doesn't relate to C# script class instance at all.
In [my other issue](https://github.com/godotengine/godot/issues/79080) I realised that when you attaching a script to Node or Resource (which are GodotObjects), it kind of becomes the Type of that script (class).
Also according to [this answer](https://ask.godotengine.org/27441/c%23-how-do-i-get-the-script-of-another-node) I just must cast GodotObject to the script Type. But it fails!
Maybe I'm being stupid (again?), but how to get to the "real" instance?

### Steps to reproduce

1. Open attached project
2. Look in TestInspectorPlugin.cs
3. Press "TEST" button in inspector
Checked everything I can think of; must print C# script class type somewhere, but don't!

### Minimal reproduction project

[TestProject.zip](https://github.com/godotengine/godot/files/12362107/TestProject.zip)
Repository: go
Issue: encoding/xml: XML tag name that consist of ':' doesn't get umarshaled properly
Labels: NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.19.9 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
Reproduces using go 1.21 with go.dev/play


### What operating system and processor architecture are you using (`go env`)?
go version go1.19.9 linux/amd64


<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN="/usr/bin"
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/root/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/root/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/gimme/.gimme/versions/go1.19.9.linux.amd64"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/gimme/.gimme/versions/go1.19.9.linux.amd64/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.19.9"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/root/go/src/kubevirt.io/kubevirt/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3975233845=/tmp/go-build -gno-record-gcc-switches"

</pre></details>

### What did you do?
Umarshaling XML to a struct that has attribute with XML tag whos name consist of `:` wont unmarshal correctly and  end up empty.

For example: 
```
type QemuDomain struct {
	XMLName xml.Name `xml:"domain"`
	XmlNs   string   `xml:"xmlns:qemu,attr,omitempty"` <------ XmlNs set as XML attribute, with a name consist of ':'
}
```
The `XmlNs` attribute end up with empty string.

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on go.dev/play is best.
-->

Reproducer https://go.dev/play/p/5l9WHxVBO5S

### What did you expect to see?
I expect the `XmlNs` attribute to umarshal correctly and wont end up empty.


### What did you see instead?
The `XmlNs` attribute end up empty.
Repository: rust
Issue: Tracking Issue for stabilizing stack smashing protection (i.e., -Z stack-protector)
Labels: C-tracking-issue,PG-exploit-mitigations

<!--
NOTE: For library features, please use the "Library Tracking Issue" template instead.

Thank you for creating a tracking issue! 📜 Tracking issues are for tracking a
feature from implementation to stabilisation. Make sure to include the relevant
RFC for the feature if it has one. Otherwise provide a short summary of the
feature and link any relevant PRs or issues, and remove any sections that are
not relevant to the feature.

Remember to add team labels to the tracking issue.
For a language team feature, this would e.g., be `T-lang`.
Such a feature should also be labeled with e.g., `F-my_feature`.
This label is used to associate issues (e.g., bugs and design questions) to the feature.
-->

<!--
This is a tracking issue for the RFC "XXX" (rust-lang/rfcs#NNN).
The feature gate for the issue is `#![feature(FFF)]`.
-->
This is a tracking issue for stabilizing stack smashing protection (i.e., -Z stack-protector). The was added in #84197 without a tracking issue. There is also no feature gate for it.

As part of the work on reviewing previously-added support for exploit mitigations to the Rust compiler (see https://hackmd.io/@rcvalle/H1epy5Xqn), @luismerino and I, and also @wesleywiser reviewed the stack smashing protection option (i.e., -Z stack-protector) implementation and it looked good for stabilization, so we'd like to propose stabilizing it.

<!--
### 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.
-->

TBD.

### Unresolved Questions
<!--
Include any open questions that need to be answered before the feature can be
stabilised.
-->

 Is there any concern or anything that the community would like to see implemented before its stabilization?

### Implementation history

<!--
Include a list of all the PRs that were involved in implementing the feature.
-->

* #84197
* #93052
* #109671
* #111722
* #116037
Repository: flutter
Issue: codesign.dart needs a way to be manually invoked by release engineers
Labels: P2,from: postmortem,team-release,triaged-release

The last AI before we can deprecate codesign.py is to ensure release engineers have a back up way of codesigning binaries (in case automation fails, or there is an outage).

There's a few ways this could be done, but I presume creating an MPA script that schedules codesigning drone builds for a given hash would be sufficient, and allow us to reuse our existing infra.
Repository: next.js
Issue: Dynamic import fails with named import of client component on server component 
Labels: bug,Lazy Loading

### Verify canary release

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

### Provide environment information

```bash
Operating System:
      Platform: win32
      Arch: x64
      Version: Windows 11 Home Single Language
    Binaries:
      Node: 20.5.0
      npm: N/A
      Yarn: N/A
      pnpm: N/A
    Relevant Packages:
      next: 13.4.16-canary.1
      eslint-config-next: 13.4.16
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.1.6
    Next.js Config:
      output: N/A
```


### Which area(s) of Next.js are affected? (leave empty if unsure)

Dynamic imports (next/dynamic)

### Link to the code that reproduces this issue or a replay of the bug

https://codesandbox.io/p/sandbox/nervous-hermann-99l2ds

### To Reproduce

 1. Create a `server-component ` & use it in `app/page.tsx`
```JSX
//server-component.tsx
export function ExampleServerComponent(){
  return <div>ServerComponent</div>
}
```

2. Import `client-component` dynamically
```JSX
//client-component.tsx
"use client"

export function HeavyClientComponent() {
  return <div>Hi from heavy client component</div>
}
```
```JSX
//server-component.tsx

//...
const HeavyClientComponent = dynamic(() =>
    import("./client-component").then((mod) => mod.HeavyClientComponent)
)

export function ExampleServerComponent(){
   return (
    <div>
      <HeavyClientComponent />
      Hi from Server component
    </div>
  )
}
```

3. Run `npm run dev`

Throws error `Error: Cannot access .then on the server.`

However if the `client-component` uses `default export` then no error occurs.

Is it some sort of limitation that I cannot use named exports with `next/dynamic` to dynamically load client component on a server component.

### Describe the Bug

I am trying to import a heavy client component inside a server components, all exports are named. Dynamically importing with named exports throws error whereas default exports don't cause such problem.

### Expected Behavior

Named exports work fine while dynamically importing client component into a server component.

### Which browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

_No response_