sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: next.js
Issue: Passing Date value from getServerSideProps or getStaticProps ends in serialization error
Labels: bug

### Verify canary release

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

### Provide environment information

```bash
Operating System:
      Platform: linux
      Arch: x64
      Version: #109~18.04.1-Ubuntu SMP Wed Jan 25 20:53:00 UTC 2023
    Binaries:
      Node: 19.6.0
      npm: 9.4.0
      Yarn: 1.22.19
      pnpm: N/A
    Relevant packages:
      next: 13.1.6
      eslint-config-next: 13.1.6
      react: 18.2.0
      react-dom: 18.2.0
```


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

Data fetching (gS(S)P, getInitialProps), Dynamic imports (next/dynamic)

### Link to the code that reproduces this issue

https://stackblitz.com/edit/nextjs-6kenug?file=package.json

### To Reproduce

I get this behaviour when I try to pass an object with a value of type Date as props from getStaticProps or getServerSideProps.

### Describe the Bug

I believe that the date type is not getting properly serialized.

### Expected Behavior

I believe that the date value should be easily passed in props so it can then be used in the page.

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

Chrome 110.0.5481.100

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

next dev
Repository: flutter
Issue: Building Flutter web app with `--pwa-strategy=offline-first` still downloads canvaskit from the CDN
Labels: c: new feature,platform-web,P2,team-web,triaged-web

Not sure if this is the expected behavior or not. 

If we build Flutter DevTools with:

```
flutter build web \
  --web-renderer canvaskit \
  --pwa-strategy=offline-first \
  --release \
  --no-tree-shake-icons
```

then canvaskit is downloaded from the CDN. This is surprising, I would have thought because we are specifying ` --pwa-strategy=offline-first`, canvaskit would instead be the version bundled with the app (see https://github.com/flutter/flutter/issues/60069#issuecomment-994103190)

If I initialize the engine with the canvaskit URL specified, then it does use the version bundled with the app:

```
 engineInitializer.initializeEngine({
   renderer: 'canvaskit', 
   canvasKitBaseUrl: 'canvaskit/'
})
``` 

See https://github.com/flutter/devtools/pull/5331 for more details. 

FYI @yjbanov @mdebbar
Repository: stable-diffusion-webui
Issue: [Feature Request]: Highlight row when an update is available or move update column.
Labels: enhancement

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

This is minor but when you have a lot of extensions installed, matching the update available checkbox with the plugin in question is unnecessarily taxing.  

### Proposed workflow

This could be solved by either highlighting the rows that have available updates or moving the update column to be first, so that it is right next to the name of the plugin.

### Additional information

_No response_
Repository: java-design-patterns
Issue: Translation to Danish
Labels: info: help wanted,type: feature,epic: translation

Hi, I can see that there is currently no README in Danish? I can do it, if that is something you would like to add.
Repository: vscode
Issue: Voicover not announcing link in view with correct role
Labels: bug,accessibility,workbench-welcome

- VS Code Version: 1.76.0
- OS Version: macOS 12.6.3

Steps to Reproduce:

1. Create an extension that contributes a view with a viewWelcome with contents with a link
example:
```
"contributes": {
   "views": {
     "dataworkspace": [
       {
         "id": "dataworkspace.views.main",
         "name": "%main-view-name%",
         "contextualTitle": "%data-workspace-view-container-name%",
         "icon": "images/data-workspace.svg"
       }
     ]
   },
   "viewsWelcome": [
     {
       "view": "dataworkspace.views.main",
       "contents": "To learn more about projects [read our docs](https://aka.ms/azuredatastudio-projects).",
       "when": "workbenchState != workspace"
     }
   ]
}
```
3. Start Voiceover with using shortcut key Command+F5.
4. Tab to the extension's view and to the link

Actual Result:​
Voiceover is announcing incorrect role for 'read our docs' as button instead of link.
Visually 'read our docs' looks like link and also working as link but voiceover is announcing role as button.

Expected Result:​
Voiceover should be announcing role for 'read our docs' as link instead of button.

![linkAnnouncedAsButton](https://user-images.githubusercontent.com/31145923/222281931-8f71efe9-6237-4687-bc11-b9627afc82de.gif)
Repository: material-ui
Issue: Using `React.ComponentProps` on the component created by `styled` cause significant delay in compilation
Labels: performance,typescript,package: system

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Steps to reproduce 🕹

Link to live example:

A minimum repro can be seen here:

https://github.com/chance-an/styled_repro

Steps:

1. git clone the repository above
2. run `npm install`
3. run `npm run build`

Despite its simplicity, significant time was taken to compile the project.


If we comment out this line in `index.tsx`

```JSX
const TestComponent = (props: React.ComponentProps<typeof StyledContainer>) => {
```
And uncomment this line
```JSX
const TestComponent = (props: any)
```

the build can finish very quickly.

Separately, if we don't use `styled` from `@mui/system/styled` but use the one from `@emotion/styled` the issue goes away, and the project will be built very quickly as well. 



### Current behavior 😯

The project builds very slowly with the introduction of `React.ComponentProps` on the component returned by the `styled` of the `@mui/system` package.

This is a reduced example from an actual React project. In the full project, using `React.ComponentProps` on the component returned by `styled` will incur a javascript heap out of memory after a significantly prolonged compilation process. 

For the minimum repro though, I cannot reproduce the `javascript heap out of memory` error, but only the slow compilation.

In the meantime, if an IDE like VS Code is being used, the editor also takes a significant amount of time loading intellisense. A "Code Helper" (Used by VS Code) process takes 100% CPU cycles at the same time. So it looks like VS Code's ts compiler is also stressed out.

### Expected behavior 🤔

Using `styled` from `@mui/system/styled` should have a similar compilation performance as the one from `@emotion/styled`.

### Context 🔦

A developer should be able to use `styled` and `React.ComponentProps` to extract the props of the produced component correctly without slowing down the compilation or crashing the node heap. 

### Your environment 🌎

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  No particular browser is involved with this issue. It's a compile-time issue.
  
  Output from `npx @mui/envinfo` goes here.
  
  System:
    OS: macOS 13.1
  Binaries:
    Node: 19.0.1 - ~/.nvm/versions/node/v19.0.1/bin/node
    Yarn: Not Found
    npm: 8.19.2 - ~/.nvm/versions/node/v19.0.1/bin/npm
  Browsers:
    Chrome: 110.0.5481.177
    Edge: Not Found
    Firefox: 106.0.5
    Safari: 16.2

```
</details>
Repository: godot
Issue: [WebGL] - GL_INVALID_OPERATION: Insufficient buffer size due to automatic mesh LOD
Labels: bug,platform:web,topic:rendering,topic:3d

### Godot version

4.0.stable

### System information

WebGL, Windows 11

### Issue description

Some .glb (.fbx and .dae too) mesh don't show after a certain distance

Scene on web - WebGL:
![example](https://user-images.githubusercontent.com/57235054/222295477-6adaeac0-5f48-4bb6-866c-bcb74041c07a.png)

Scene running on Desktop - OpenGL
![example pc](https://user-images.githubusercontent.com/57235054/222296219-f450f1e1-2ad6-4945-8994-3330878eee47.png)

Error:
![image](https://user-images.githubusercontent.com/57235054/222295587-7e98082e-c8a6-4fef-b9ab-d755539e374a.png)



### Steps to reproduce

1. Create project
2. Add .glb to Scene
3. Add Camera3D
4. Play on Web

### Minimal reproduction project

[RenderExample.zip](https://github.com/godotengine/godot/files/10866376/RenderExample.zip)
Repository: node
Issue: Potentially wrong docs in readable.pipe(destination) about not cleaning up writable
Labels: doc,stream

### Affected URL(s)

https://nodejs.org/dist/latest-v16.x/docs/api/stream.html#readablepipedestination-options

### Description of the problem

The linked docs say:

> One important caveat is that if the `Readable` stream emits an error during processing, the `Writable` destination *is not closed* automatically. If an error occurs, it will be necessary to manually close each stream in order to prevent memory leaks.

It seems like it *does* close/destroy the writable. See below test. I can't find any tests that assert that it's not closed.

```js
import stream from "node:stream";
import {finished} from "node:stream/promises";
import assert from "node:assert";

class NullWritable extends stream.Writable {
	_write(c, e, cb) { cb(); }
}

const src = stream.Readable.from(["1", "2", "3"]);
const dest = new NullWritable();
const theError = new Error("aborted");
src.pipe(dest);
process.nextTick(() => src.emit("error", theError)); // Emit an error during processing
await assert.rejects(finished(src));
assert.strictEqual(src.destroyed, true);
assert.strictEqual(dest.destroyed, false); // This is true; docs suggest it would be false
```
Repository: next.js
Issue: App getInitialProps context res.status is not a function
Labels: bug

### 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 10 Pro
    Binaries:
      Node: 16.16.0
      npm: N/A
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 12.3.1
      eslint-config-next: 12.3.1
      react: 17.0.2
      react-dom: 17.0.2
```
```


### Which area(s) of Next.js are affected? (leave empty if unsure)

Data fetching (gS(S)P, getInitialProps)

### Link to the code that reproduces this issue

https://github.com/Capricair/next-dynamic-issue.git

### To Reproduce

1. create a next app
2. create _app.js
3. add App.getIntialProps function use res.status()

### Describe the Bug

```
```
App.getInitialProps = async (ctx) => {
  const { req, res } = ctx

  // when url is invalid
  if (req.url === "xxx...") {
    return res.status(404).end()  // res.status is not a function
  }

  // some code ...

  return {}
}
```
```

### Expected Behavior

res can set http status code

### Which browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

_No response_
Repository: flutter
Issue: [3.3.9] New crashes occurred after updating from version 2.8.1 to version 3.3.9.
Labels: c: crash,platform-ios,engine,P2,needs repro info,team-ios,triaged-ios

A new crash occurred after updating from version 2.8.1 to version 3.3.9. First of all, the symbol is also missing, but it is a crash that does not know where it occurs. I've searched but haven't found anything related. May I know why this error occurs?

## Steps to Reproduce

<!-- Please include full steps to reproduce so that we can reproduce the problem. -->

1. Execute `flutter run` on the code sample <!-- (see "Code sample" section below) -->
2. ... <!-- describe steps to demonstrate bug -->
3. ... <!-- for example "Tap on X and see a crash" -->

**Expected results:** <!-- what did you want to see? -->

**Actual results:** <!-- what did you see? -->

<details>

```
Crashed: com.apple.main-thread
SIGSEGV 0x0000000961c33f80
0
libobjc.A.dylib
objc_retain + 16
1
Flutter
(Missing UUID c5b43c20360b3122a6e867c5a3fd398d)
2
Flutter
(Missing UUID c5b43c20360b3122a6e867c5a3fd398d)
3
Flutter
(Missing UUID c5b43c20360b3122a6e867c5a3fd398d)
4
Flutter
(Missing UUID c5b43c20360b3122a6e867c5a3fd398d)
5
Flutter
(Missing UUID c5b43c20360b3122a6e867c5a3fd398d)
6
Flutter
(Missing UUID c5b43c20360b3122a6e867c5a3fd398d)
7
Flutter
(Missing UUID c5b43c20360b3122a6e867c5a3fd398d)
8
Flutter
(Missing UUID c5b43c20360b3122a6e867c5a3fd398d)
9
Flutter
(Missing UUID c5b43c20360b3122a6e867c5a3fd398d)
10
Flutter
(Missing UUID c5b43c20360b3122a6e867c5a3fd398d)
11
Flutter
(Missing UUID c5b43c20360b3122a6e867c5a3fd398d)
12
Flutter
(Missing UUID c5b43c20360b3122a6e867c5a3fd398d)
13
Flutter
(Missing UUID c5b43c20360b3122a6e867c5a3fd398d)
14
Flutter
(Missing UUID c5b43c20360b3122a6e867c5a3fd398d)
15
CoreFoundation
__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 32
16
CoreFoundation
__CFRunLoopDoTimer + 1064
17
CoreFoundation
__CFRunLoopDoTimers + 320
18
CoreFoundation
__CFRunLoopRun + 1936
19
CoreFoundation
CFRunLoopRunSpecific + 600
20
GraphicsServices
GSEventRunModal + 164
21
UIKitCore
-[UIApplication _run] + 1100
22
UIKitCore
UIApplicationMain + 364
23
Eats Delivery-AppStore
AppDelegate.swift - Line 38
main + 38
24
(Missing)

```

</details>
Repository: stable-diffusion-webui
Issue: [Bug]: API returns different results than UI
Labels: asking-for-help-with-local-system-issues

### Is there an existing issue for this?

- [x] I have searched the existing issues and checked the recent builds/commits

### What happened?

As in the title:

when I use img2img tab in UI with prompt `colorful bag with flowers` and parameters:

![image](https://user-images.githubusercontent.com/39011092/222323036-8d2ee446-9f4c-44fd-b18d-e8fdaf2b9a82.png)

![image](https://user-images.githubusercontent.com/39011092/222322062-cfcda8f6-6bba-435d-b2b1-834570f78847.png)

Here's what I get:
![image](https://user-images.githubusercontent.com/39011092/222322190-e586cd1b-f1e2-44f5-9c5c-e532e52f9c63.png)

The same parameters passed in API:


`payload = {
  "init_images": [img],
  "denoising_strength": 0.50,
  "prompt": "colorful bag with flowers",
  "sampler_name": "Euler a",
  "steps": 20,
  "cfg_scale": 7,
  "negative_prompt": "",
  "include_init_images": True,
  "seed":420420,
  "batch_size":1
}

response = requests.post(url=f'{url}/sdapi/v1/img2img', json=payload)`

Now I get slighlty different result, although parameters and seed are the same
![image](https://user-images.githubusercontent.com/39011092/222322459-e9bfc4ea-7584-44f5-a602-7335d48f4477.png)

Did I miss some parameters in API?

### Steps to reproduce the problem

1. Go to UI and generate image, then try to generate exactly the same in API


### What should have happened?

I should get exactly the same image when seed is specified. I get the same image every time I pass the same parameters and seed via UI. The same happens for API case. The problem is that results are different between UI and API.

### Commit where the problem happens

 commit: 0cc0ee1b

### What platforms do you use to access the UI ?

Linux

### What browsers do you use to access the UI ?

Google Chrome, Apple Safari

### Command Line Arguments

```Shell
--api --share
```


### List of extensions

sd-webui-controlnet

### Console logs

```Shell
no cmd error /warning logs, everything loads normally
```


### Additional information

_No response_
Repository: rust
Issue: A code with dependent types, that should compile, doesn't
Labels: A-trait-system,T-compiler,C-bug

I tried this code:

```rust
pub struct BinaryFormatWithoutFieldUid<'a, T>(pub &'a T);

pub struct BinaryFormatWithoutLength<'a, T>(pub &'a T);

pub trait Serialize {}

impl<'a, T> Serialize for BinaryFormatWithoutFieldUid<'a, T>
    where BinaryFormatWithoutLength<'a, T>: Serialize
{}

impl<'a, T> Serialize for BinaryFormatWithoutFieldUid<'a, Option<T>>
    where BinaryFormatWithoutFieldUid<'a, T>: Serialize
{}

impl<'a, T> Serialize for BinaryFormatWithoutLength<'a, Option<T>>
    where BinaryFormatWithoutLength<'a, T>: Serialize
{}
```

I expected it to compile without errors.

Instead, this happened:
```
error[E0275]: overflow evaluating the requirement `BinaryFormatWithoutLength<'_, std::option::Option<_>>: Serialize`
   |
   = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`xrpl_async`)
note: required for `BinaryFormatWithoutLength<'_, std::option::Option<std::option::Option<_>>>` to implement `Serialize`
  --> src/lib.rs:15:13
   |
15 | impl<'a, T> Serialize for BinaryFormatWithoutLength<'a, Option<T>>
   |             ^^^^^^^^^     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   = note: 127 redundant requirements hidden
   = note: required for `BinaryFormatWithoutLength<'_, std::option::Option<std::option::Option<std::option::Option<...>>>>` to implement `Serialize`
   = note: the full type name has been written to '/home/porton/Projects/bugs/rust-overflow/target/debug/deps/xrpl_async-97a5b377c31d9cdb.long-type-8508140246639481262.txt'

For more information about this error, try `rustc --explain E0275`.
error: could not compile `xrpl_async` due to previous error
```

There should be no infinite recursion in this case, because I go from more complex types (like `Option<T>`) to less complex types (`T`). I also go only in the direction `BinaryFormatWithoutFieldUid` -> `BinaryFormatWithoutLength` and not `BinaryFormatWithoutLength` -> `BinaryFormatWithoutFieldUid`, so there should be no infinite recursion.

A funny thing is that commenting out any of the three last definitions makes the file compile.

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.67.1 (d5a82bbd2 2023-02-07)
binary: rustc
commit-hash: d5a82bbd26e1ad8b7401f6a718a9c57c96905483
commit-date: 2023-02-07
host: x86_64-unknown-linux-gnu
release: 1.67.1
LLVM version: 15.0.6
```
and
```
$ rustc --version --verbose
rustc 1.69.0-nightly (9aa5c24b7 2023-02-17)
binary: rustc
commit-hash: 9aa5c24b7d763fb98d998819571128ff2eb8a3ca
commit-date: 2023-02-17
host: x86_64-unknown-linux-gnu
release: 1.69.0-nightly
LLVM version: 15.0.7
```
Repository: godot
Issue: Godot crashes when launching a Vulkan project (Intel a750 Arc, Windows 10)
Labels: bug,platform:windows,topic:rendering

### Godot version

4.0-stable

### System information

Windows 10, Intel a750 Arc, driver version : 31.0.101.4125, supported APIS: DrtX12, OpenGL4.6, OpenCL3.0, Vulkan1.3

### Issue description

When I try to open any project in Godot it will crash almost instantly, If I try to open it through command-line I get this error:

`ERROR: Condition "err" is true. Returning: ERR_CANT_CREATE
   at: _create_device (drivers/vulkan/vulkan_context.cpp:1476)
`

I tried different project as well as creating a new one which didn't fix the issue.
the issue started happening once I updated my drivers, and I than rolled them back which didn't fix anything I also was using rc4 which wasn't working so I just upgraded to 4.0-stable.

if I launch a project in Godot 3.5 though everything works fine and doesn't crash.


### Steps to reproduce

Get a Intel arc A750 and update drivers

### Minimal reproduction project

N/A
Repository: pytorch
Issue: [JIT] Support string type annotations in NamedTuples
Labels: oncall: jit

### 🚀 The feature, motivation and pitch

See below for an example clarifying what "string type annotations" means.

Normally we'd just advise users to not annotate like this. But this is an effect of `from __future__ import annotations` which is difficult to work around, because it applies per-file ([PEP](https://peps.python.org/pep-0563)). It's also plausible that users in some scenarios would want to use this in order to be able to import less packages, to reduce import times.

**Q**: Why do NamedTuples have this issue, but not normal types?
**A**: String annotations are supported for normal types, because the IR is loaded into C++ as strings and parsed in C++. But for NamedTuples, we parse the NamedTuple string name and then run a callback to python, where we use `getattr(obj, "__annotations__")` to get the annotations. At this point, we may not have the necessary context in order to evaluate the ForwardRef.

In order to fix this, we need to plumb the extra context through.

- [x] Fix this for type annotations - fixed in #96933
- [ ] Fix this for instances of NamedTuples whose types are inferred. For an example of this, see test_namedtuple_resolution_forwardref introduced in #96933. Suggestions on investigating this: first, un-mark the test as expectedFailure; then put a breakpoint at `registerNamedTuple` (in python_sugared_value.cpp). This will show the C++ stack leading to the named tuple issue. One option for fixing this is to plumb the RCB through to this callsite. (To run the test, `python test/test_jit.py -k test_namedtuple_resolution_forwardref`).

### Alternatives

Alternatively we can try to support this the way non-nn.Module classes are supported. Roughly speaking, these are pre-compiled and then cached in `torch/jit/_state.py`. Then, we don't need to worry about plumbing the context through. I didn't look at the details, so maybe there's other complications here or other context why NamedTuples were supported differently than other classes.

### Additional context

Rough idea of repro (untested)

```python
import torch
from typing import NamedTuple

class MyNT(NamedTuple):
    x: "str"
    y: "torch.Tensor"

def fn(x: MyNT):
    return x.y.relu()

torch.jit.script(fn)
```

If we also add `from __future__ import annotations`, then we'll find that `MyNT.__annotations__` shows a dict of `str -> FutureRef` instead of the `str -> typing.*` that we normally see.

cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel