sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: next.js
Issue: What is the deal with Access-Control-Allow-Origin header for Edge functions?
Labels: bug,Runtime

### Verify canary release

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

### Provide environment information

[blank]


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

Middleware / Edge (API routes, runtime)

### Link to the code that reproduces this issue

[blank]

### To Reproduce

Try to set `Access-Control-Allow-Origin: *` on an Edge function request. I ended up taking the initiative of publishing the CORS Edge example as [a library](https://www.npmjs.com/package/nextjs-edge-cors) only to find that also didn't work.

### Describe the Bug

No amount of begging and pleading will set the correct `headers: { "Access-Control-Allow-Origin": "*" }` header I am asking to be set on the response.

This is not an optional thing. You should not step on our headers. We don't provide headers and expect Vercel to retain veto power over them. 

### Expected Behavior

The headers should be set as the developer specifies them.

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

_No response_

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

_No response_
Repository: stable-diffusion-webui
Issue: [Feature Request]: deploy webui on a base_url/subpath instead of `/` 
Labels: bug-report

### 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 ?

I want to deloy webui on an exist host with subpath,  like `http://xxx.com/webui/`


I tried nginx to for service route，not work. 



### Proposed workflow

1. start webui with args `--base-url /webui`
2. got the service on `http://host:port/webui/`


### Additional information

_No response_
Repository: rust
Issue: Floating point comparisons are miscompiled for signalling NaN inputs on AArch64
Labels: A-LLVM,P-high,T-compiler,regression-from-stable-to-stable,I-unsound,WG-llvm,A-floating-point,O-AArch64,I-miscompile,C-external-bug

When optimizations are enabled, we miscompile this function on aarch64 (definitely `aarch64-apple-darwin`, but linux seems impacted too):

```rust
// https://rust.godbolt.org/z/YMbEWMvao
pub fn clamp0(f: f32) -> f32 {
    // Carefully written check that maps `NaN` to `0.0`
    if !(f > 0.0) { 0.0 } else { f }
}
```

This function is carefully written so that `NaN` inputs are mapped to zero[^3]. Sadly, the way we compile it, this check only works for quiet NaN -- signalling NaN are returned verbatim. For example, `clamp0(black_box(f32::from_bits(0x7f800001)))` incorrectly returns its input, a `NaN`. (The `black_box` is only needed because we get it right if it's evaluated via const-propagatation).

[^3]: Recall that all comparisons with `NaN` return false, so if `f` is NaN then `f > 0.0` will be false.

The generated code seems to use the `fmaxnm` instruction, which is based on IEEE-754 2008's maxNum function. This function is wrong here for signaling NaN, since it returns NaN for signalling NaN arguments.

While experimenting, I noticed that when `f > 0.0` is changed to `f >= 0.0` the miscompilation no longer happens. That said, the semantics change too[^1].

[^1]: With `if !(f  > 0.0) { 0.0 } else { f }`, `clamp0(-0.0)` will become a positive zero, which is not the case for `if !(f  >= 0.0) { 0.0 } else { f }`.

I think this is an LLVM issue, but it's also possible that we're telling LLVM something that is incorrect for signalling NaN. I don't know which is the case.

---

This could cause real problems in the wild. I've written code before which passes the result of similarly "clever" clamp implementations to `to_int_unchecked` (UB, but likely harmless[^harmless] and only because of our miscompilation) before using them as an unchecked array index... which now turns that "harmless" UB into an out of bounds access[^2] (not really harmless). So I think this is a potentially serious issue.

[^harmless]: We lived with the UB being possible in all `f as int` casts for a very long time.

[^2]: Such code is spooky, but it is often easy to verify it behaves properly for every possible f32 input.

### Meta

`rustc --version --verbose`:
```
rustc 1.70.0-nightly (cf7ada217 2023-04-03)
binary: rustc
commit-hash: cf7ada217c8ac63367b184afd9fffaff30f6ed44
commit-date: 2023-04-03
host: aarch64-apple-darwin
release: 1.70.0-nightly
LLVM version: 16.0.0
```

This has happened at least back to `1.55.0-aarch64-apple-darwin`, so I think we've always been broken here. The fact that it only happens for sNaN (rare) and doesn't happen if a `>=` condition is used probably explains why nobody noticed it -- I only noticed when doing exhaustive testing of some larger function (`clamp0` is minimized) for all `f32`s.
Repository: pytorch
Issue: [FSDP] summon_full_params with_grad=True CPU offload can crash
Labels: oncall: distributed,triaged,module: fsdp

### 🐛 Describe the bug

It can crash if the grads are not None (i.e. optim.zero_grad(set_to_none=False) is called, or grad is not zeroed at all):

```
527     work = group._allgather_base(output_tensor, input_tensor)
528 RuntimeError: Tensors must be CUDA and dense
```

### Versions

main

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu
Repository: material-ui
Issue: [Autocomplete][material-ui] `fullwidth=true` always passed to inner component
Labels: bug 🐛,package: material-ui,component: autocomplete

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Steps to reproduce 🕹

Link to live example: https://stackblitz.com/edit/react-zc5u5j?file=demo.js

Steps:

1. create `<Autocomplete/>` with a `<TextField/>` as inner input.
2. see the render result.
3. inspect React props with React Dev Tools.




### Current behavior 😯

The `<Autocomplete/>` is full width, even if I didn't specify fullwidth prop.

After inspecting the props of `<TextField/>`, I found that `<Autocomplete/>` always pass `fullwidth={true}` to inner input component, which is unexpected.

![image](https://user-images.githubusercontent.com/5836790/231062825-b913ce0e-d761-4f22-b7a4-3a82285c805e.png)

### Expected behavior 🤔

It should not be fullwidth if I din't tell it to be. This makes the component more predictable.

### Context 🔦

_No response_

### Your environment 🌎

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.
```
</details>
Repository: terminal
Issue: [Settings - Line Height] : Screen reader is not announcing the sub-text present under the 'Line Height' button.
Labels: Issue-Bug,Area-Accessibility,Product-Terminal,HCL-E+D,A11yWCAG,HCL-WindowsTerminal,A11ySev3

### Windows Terminal version

1.18.902.0

### Windows build number

25324.1011

### Other Software

Test Environment:
OS: Windows 11 Version Dev (OS Build 25324.1011)
App: Windows Terminal Preview
Screen Reader: Narrator

### Steps to reproduce

Repro Steps:

1.Open Windows Terminal.
2.Open Setting page using 'Ctrl + ,' keys.
3.Now navigate to the 'Advanced' button present under 'Default Profile'.
4. Now navigte to the 'Line Height' and Observe the issue.

User Experience:
People with visual impairments who rely on the screen readers are unable to know the button's description.

Guideline link:
https://www.w3.org/TR/WCAG21/#info-and-relationships

Attachments:
[Screen reader is not announcing the sub-text present under the 'Line Height' button..zip](https://github.com/microsoft/terminal/files/11197360/Screen.reader.is.not.announcing.the.sub-text.present.under.the.Line.Height.button.zip)




### Expected Behavior

Screen reader should announce the sub-text present under the 'Line Height' button.


### Actual Behavior

Screen reader is not announcing the sub-text present under the 'Line Height' button.
Repository: pytorch
Issue: [functorch] torch.compile - functorch transforms Interaction
Labels: triaged,oncall: pt2,module: functorch,module: pt2-dispatcher

### 🐛 Describe the bug

This is an umbrella issue for all the issues related to functorch - torch.compile interaction.

Currently, functorch transforms can be compiled under torch.compile with undocumented API. However, there are still a few issues which require resolution.

Example of compiling transform
```python
import torch
from torch._dynamo import allow_in_graph
from functools import wraps

def traceable(f):
    f = allow_in_graph(f)

    @wraps(f)
    def wrapper(*args, **kwargs):
        return f(*args, **kwargs)

    return wrapper

def fn(x):
    return vmap(torch.sin)(x)

opt_fn = torch.compile(traceable(fn))
opt_fn(torch.randn(3, 3))

```

torchbench issues:

- [ ] https://github.com/pytorch/pytorch/issues/98825
- [ ] https://github.com/pytorch/pytorch/issues/98827

user reported issues:
- [x] https://github.com/pytorch/pytorch/issues/97425
- [ ] https://github.com/pytorch/pytorch/issues/100105
- [x] https://github.com/pytorch/pytorch/issues/100075

### Versions

master

cc @ezyang @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519 @Chillee @samdow @janeyx99 @soumith @ngimel
Repository: next.js
Issue: scrolling issue only in safari browser  when we import components in next/dynamic
Labels: Upstream,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: darwin
      Arch: x64
      Version: Darwin Kernel Version 22.1.0: Sun Oct  9 20:14:54 PDT 2022; root:xnu-8792.41.9~2/RELEASE_X86_64
    Binaries:
      Node: 14.17.3
      npm: 9.6.4
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 13.3.0
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
```


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

Operating System (Windows, MacOS, Linux)

### Link to the code that reproduces this issue

de

### To Reproduce

scrolling issue is coming only safari browser when we import the components in next/dynamic.

https://user-images.githubusercontent.com/130436242/231077380-e415f32b-50f5-4834-a2a4-3e0e7f06507a.mp4



### Describe the Bug

when we  open course page for the first time the scroll works exactly correct,  but when we click on any scrolltab its scroll to that particular place perfectly.  But when we try to scroll to top of the page the scroll gets bounce back to selected scrolltab when it reach/touch that scrolltab element. It only happens in  safari browser when we import any component of course page related in next/dynamic... you can find the issue in above video

### Expected Behavior

it should scroll top to page  after clicking on the scroll tab also, it should not bounce

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

safari 

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

next
Repository: pytorch
Issue: [functorch] functorch_maml_omniglot - fails under torch.compile
Labels: triaged,oncall: pt2,module: functorch,module: pt2-dispatcher

### 🐛 Describe the bug

Running `functorch_maml_omniglot` from `torchbench` with following patch
```patch
diff --git a/torchbenchmark/models/functorch_maml_omniglot/__init__.py b/torchbenchmark/models/functorch_maml_omniglot/__init__.py
index faf16d73..430eaadf 100644
--- a/torchbenchmark/models/functorch_maml_omniglot/__init__.py
+++ b/torchbenchmark/models/functorch_maml_omniglot/__init__.py
@@ -10,6 +10,17 @@ from typing import Tuple
 from ...util.model import BenchmarkModel
 from torchbenchmark.tasks import OTHER
 
+from torch._dynamo import allow_in_graph
+from functools import wraps
+
+def traceable(f):
+    f = allow_in_graph(f)
+
+    @wraps(f)
+    def wrapper(*args, **kwargs):
+        return f(*args, **kwargs)
+
+    return wrapper
 
 def loss_for_task(net, n_inner_iter, x_spt, y_spt, x_qry, y_qry):
     params, buffers, fnet = net
@@ -66,7 +77,7 @@ class Model(BenchmarkModel):
         self.model = net
 
         root = str(Path(__file__).parent.parent)
-        self.meta_inputs = torch.load(f'{root}/maml_omniglot/batch.pt')
+        self.meta_inputs = torch.load(f'{root}/functorch_maml_omniglot/batch.pt')
         self.meta_inputs = tuple([torch.from_numpy(i).to(self.device) for i in self.meta_inputs])
         self.example_inputs = (self.meta_inputs[0][0],)
 
@@ -90,7 +101,9 @@ class Model(BenchmarkModel):
         # In parallel, trains one model per task. There is a support (x, y)
         # for each task and a query (x, y) for each task.
         compute_loss_for_task = functools.partial(loss_for_task, net, n_inner_iter)
-        qry_losses, qry_accs = vmap(compute_loss_for_task)(x_spt, y_spt, x_qry, y_qry)
+        fn = vmap(compute_loss_for_task)
+        fn = torch.compile(traceable(fn))
+        qry_losses, qry_accs = fn(x_spt, y_spt, x_qry, y_qry)
 
         # Compute the maml loss by summing together the returned losses.
         qry_losses.sum().backward()
```

Leads to failure:
```
Exception: Please convert all Tensors to FakeTensors first or instantiate FakeTensorMode with 'allow_non_fake_inputs'. Found in aten.convolution.default(*(FakeTensor(FakeTensor(..., device='meta', size=(160, 1, 28, 28)), cpu), 
```

### Versions

master

cc @ezyang @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519 @Chillee @samdow @janeyx99 @soumith @ngimel
Repository: pytorch
Issue: [functorch] vmap_hessian_fc - fails under torch.compile
Labels: triaged,oncall: pt2,module: functorch,module: pt2-dispatcher

### 🐛 Describe the bug

Running vmap_hessian_fc from torchbench/userbench with following patch

```patch
diff --git a/userbenchmark/functorch/vmap_hessian_fc.py b/userbenchmark/functorch/vmap_hessian_fc.py
index ebfe7cf3..6ae546c0 100644
--- a/userbenchmark/functorch/vmap_hessian_fc.py
+++ b/userbenchmark/functorch/vmap_hessian_fc.py
@@ -1,6 +1,6 @@
 import torch
 import torch.nn as nn
 from functorch import vmap, jacfwd, jacrev
 from .util import BenchmarkCase
 
 # batched hessians of fully connected layers is a popular quantity
@@ -8,12 +8,25 @@ from .util import BenchmarkCase
 # This test case is from https://github.com/pytorch/functorch/issues/989
 # We haven't been able to get the full model yet, so, this test case
 # is going into the functorch userbenchmark instead of torchbenchmark.
+
+from torch._dynamo import allow_in_graph
+from functools import wraps
+
+def traceable(f):
+    f = allow_in_graph(f)
+
+    @wraps(f)
+    def wrapper(*args, **kwargs):
+        return f(*args, **kwargs)
+
+    return wrapper
+
 class VmapHessianFC(BenchmarkCase):
     def __init__(self):
-        device = 'cuda'
+        device = 'cpu'
         D1 = 2  # x, y
         D2 = 3  # u, v, p
-        B = 10000
+        B = 10
         x = torch.randn(B, D1).to(device)
 
         model = nn.Sequential(
@@ -43,9 +56,12 @@ class VmapHessianFC(BenchmarkCase):
             out = self.model(x)
             return out, out
 
-        hessian, pred = vmap(
+        fn = vmap(
             jacfwd(jacrev(predict, argnums=0, has_aux=True), argnums=0, has_aux=True),
             in_dims=0,
-        )(
+        )
+
+        fn = torch.compile(traceable(fn))
+        hessian, pred = fn(
             self.x
         )
```

Leads to failure:
```
RuntimeError: Failed running call_function <function VmapHessianFC.run.<locals>.predict at 0x7fa75ef8f040>(*(FakeTensor(FakeTensor(..., device='meta', size=(10, 2)), cpu),), **{}):
InferenceMode::is_enabled() && self.is_inference() INTERNAL ASSERT FAILED at "/home/kshiteej/Pytorch/pytorch_functorch/aten/src/ATen/native/VariableMethodStubs.cpp":67, please report a bug to PyTorch. Expected this method to only be reached in inference mode and when all the inputs are inference tensors. You should NOT call this method directly as native::_fw_primal. Please use the dispatcher, i.e., at::_fw_primal. Please file an issue if you come across this error otherwise.
(scroll up for backtrace)
```

### Versions

master

cc @ezyang @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519 @Chillee @samdow @janeyx99 @soumith @ngimel
Repository: next.js
Issue: Inconsistent redirection behavior in middleware (about `localhost` and `127.0.0.1`)
Labels: bug,Runtime

### 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 Home
    Binaries:
      Node: 18.14.2
      npm: N/A
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 13.3.1-canary.4
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
```


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

Middleware / Edge (API routes, runtime)

### Link to the code that reproduces this issue

https://github.com/wonu/next-middleware-redirect-issue

### To Reproduce

1. `next dev` or `next start` with `-H 127.0.0.1`
2. enter `/handler`, then redirected to `127.0.0.1:3000`
3. enter `/middleware`, then redirected to `localhost:3000`

### Describe the Bug

Redirection in middleware to `127.0.0.1` goes to `localhost` when next sever runs with `-H 127.0.0.1`.
Without that `-H`, it goes to `127.0.0.1` well.
This happens regardless of App Router, and Route Handlers and API Routes work well, consistently.

### Expected Behavior

Redirection in middleware to `127.0.0.1` should go to `127.0.0.1` rather than `localhost` when next sever runs with `-H 127.0.0.1`.

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

_No response_

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

_No response_
Repository: storybook
Issue: [Feature Request]: `@storybook/nextjs` to support `redirects`+`rewrites` from `next.config.js`
Labels: feature request,has workaround,nextjs

### Is your feature request related to a problem? Please describe

I'm recently switched from the `@storybook/react-webpack` framework to the `@storybook/nextjs` framework with my NextJS project. Previously, I was using a `.storybook/middleware.js` file, which looked something like this:

```ts
const proxy = require("express-http-proxy");
const { join } = require("path");
const express = require("express");

const expressMiddleWare = (router) => {
  // `rewrite` for `/foo` to `imgix.bar.com/foo`
  router.use(
    "/foo",
    proxy("imgix.bar.com")
  );
};

module.exports = expressMiddleWare;
```

The routes were manually kept in-sync with the [`rewrites`](https://nextjs.org/docs/api-reference/next.config.js/rewrites) and [`redirects`](https://nextjs.org/docs/api-reference/next.config.js/redirects) defined in `next.config.js`. I thought that after migrating to `@storybook/nextjs` that this would be handled natively by the framework and that I would be able to remove my `middleware.js` file, especially because the Middleware API is undocumented and unstable. Unfortunately that was not the case, and the framework does not do this.

### Describe the solution you'd like

I would like it if `@storybook/nextjs` natively supported the `rewrites` and `redirects` defined in `next.config.js`, so that I do not have to manually configure them using the undocumented/unstable Middleware API.

### Describe alternatives you've considered

As far as I can tell, the only way that Storybook can accommodate rewrites/redirects is via the Middleware API, but I'm open to alternative suggestions.

### Are you able to assist to bring the feature to reality?

no

### Additional context

_No response_
Repository: godot
Issue: Missing import asset storage options and poor click-economy and performance for asset extraction
Labels: enhancement,topic:editor,topic:import,regression,topic:3d

### Godot version

c3ed7af

### System information

Windows 10

### Issue description

In Godot 3 imported 3D asset had the option directly in the "Import" tab to change the storage types of sub-assets for a convenient full asset extraction. E.g. to extract meshes to .mesh, materials to .material and animations to .anim and textures to single files.

![import_properties](https://user-images.githubusercontent.com/52464204/231093541-708b7f7f-8599-4c78-81bb-552e55ae1dbd.png)


In Godot 4 the same option does not exist or is limited to e.g. "Extract Textures". Replacement options are split up and buried in the "Advanced Import" menu. This menu handling requires many more steps and has unavoidable extra slow preimport and reimport steps as well.

The core issue is that what was a matter of seconds to setup in Godot 3 now takes minutes to do in Godot 4 if you want to extract all the assets to single file (or even hours on complex assets due to all the additional import steps).

E.g. you need to open the "Advanced Import" menu which triggers an unavoidable slow asset preimport. You need to find and change all the options for e.g. extract materials or extract meshes to the filepaths with requires many more button pressed and path / folder selection steps. When you are done you need to do another full reimport. In Godot 4 a reimport is in general far slower cause it includes far more complex import steps than just the asset extract in Godot 3. Some of those more complex import steps are duplicates of the already done first import consuming a lot of time for nothing.

Extracting all imported files to single files is often needed for a number of reasons where a direct scene inheritance of the imported file is not an option.

Common reasons are:
- Character customization and runtime asset switches
- Not wanting to have redudant copies of shared assets in the project and on export
- Fixing "broken" parts like additional nodes or bones added by the importer
- Having placeholder materials or shared materials that need to be switched to the real materials
- Breaking dependency links on purpose to make it editable and not mess up on reimports

The solution could properly be to add back the storage selection directly in the "Import" tab or add a convenient button for full asset extract or make the "Advanced Importer" menu (a lot) faster and require less clicks to do the same as in Godot 3.

### Steps to reproduce

Missing options in the 3D asset "Import" tab compared to Godot 3.
General slow workflow with the "Advanced Import" menu due to preimport and many more import steps and button presses required.

### Minimal reproduction project

na
Repository: kubernetes
Issue: plState := cfgCtlr.priorityLevelStates[plName]. It may not exist and the plState may be nil。
Labels: kind/bug,area/apiserver,sig/api-machinery,triage/accepted

https://github.com/kubernetes/kubernetes/blob/ad18954259eae3db51bac2274ed4ca7304b923c4/staging/src/k8s.io/apiserver/pkg/util/flowcontrol/apf_controller.go#L1009