sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Significant application performance degradation when making a module public
Labels: I-slow,A-codegen,T-compiler,C-bug,E-needs-mcve

I've encountered an unexpected and significant performance degradation in my application when changing a module's visibility from private to public. This behavior seems counterintuitive and potentially indicates a compiler optimization issue or an unexpected interaction between module visibility and performance.

my code:
```rust
mod black:
```
source: https://github.com/hayden4r4/blackscholes-rust/blob/master/src/lets_be_rational/mod.rs#L8
benches: https://github.com/hayden4r4/blackscholes-rust/blob/master/benches/black.rs

## Current behavior
When the black module is made public, the overall application performance degrades by approximately 50%.

## Expected
Changing a module's visibility should not have a significant impact on the application's overall performance. We would expect minimal to no performance change when modifying module visibility.

## Environment
`Rust version`: `1.80.0 (051478957 2024-07-21)`
`Cargo version`: `1.80.0 (376290515 2024-07-16)`
`os`: `macos m1 max`

Anyone may know where is the bug/problem/challange?
Repository: stable-diffusion-webui
Issue: [Feature Request]: ERROR: Could not install packages due to an OSError: [Errno 28] : by pass proposition
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 ?

First thanks for this nice program!!!!
During installation (linux mint) i had the following issue:
"     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╸━━━ 2.0/2.2 GB 12.7 MB/s eta 0:00:14
ERROR: Could not install packages due to an OSError: [Errno 28]"

After some tries, i realized that this always occurs "exactly" at 2.0 Gib... So this was not an erratic problem.
After some search on the web, It seems that this is due to my /tmp partition (if my research where ok)
As i didn't wanted to touch it, and i assume that the intent is to allow installation in "user space" i try a modification to bypass this

Modification proposed:
In file "_stable-diffusion-webui/modules/launch_utils.py_"
in line 380
    _torch_command = os.environ.get('TORCH_COMMAND', f"pip install torch==2.1.2 torchvision==0.16.2 --extra-index-url {torch_index_url}")_
add the option "_--no-cache-dir_"

I am not a dev, so i don't really know if there is drawback to do that... But at least that allow me to install it.
As i already found in some comments that error reported, at least, this may help someone with the same issue...
Thanks again!


### Proposed workflow

1. Evaluate is the proposal has drawbacks
2. If no, consider to implement it, if yes, perhaps a "try catch" aproach either to retry with this method, or to provide an explanatory text of the issue



### Additional information

_No response_
Repository: electron
Issue: [Bug]: Recent Documents Fiddle Example not working on macOS
Labels: platform/macOS,documentation :notebook:,bug :beetle:,arch/x64,status/confirmed,31-x-y

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

31.3.1

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

macOS

### Operating System Version

macOS Sonoma 14.5

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

When I run the Fiddle example for [Managing recent documents](https://www.electronjs.org/docs/latest/tutorial/recent-documents#managing-recent-documents) I expect to be able to right click on the dock icon and see `recently-used.md` in the dock menu.

### Actual Behavior

The app starts up as expected but the dock menu does not contain `recently-used.md`


<img width="755" alt="image" src="https://github.com/user-attachments/assets/67f7f160-daa0-4704-aa6e-74b9beca4073">

<img width="912" alt="image" src="https://github.com/user-attachments/assets/732b29bf-bf84-4042-bd1d-2230d05692f9">


### Testcase Gist URL

_No response_

### Additional Information

_No response_
Repository: vscode
Issue: Sidebar does not remember original width when it is forced to narrow due to a smaller window
Labels: bug,layout,grid-widget

<!-- ⚠️⚠️ 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.92.0
- OS Version: Windows_NT x64 10.0.22631

Steps to Reproduce:

1. Make sure the sidebar has a normal (non-minimal) width
2. Resize the window to be very small, so that the sidebar is forced to shrink
3. Resize the window to a larger size again

Expected result: The sidebar grows to be as wide as it was before you made the window smaller

Actual result: The sidebar stays at the smaller size

This is relevant if you usually work with maximized windows, but sometimes drag the windows between multiple monitors. During the dragging phase, the window shrinks to the last size. If this size is small for some reason, it shrinks the sidebar. When you drop the window on the other monitor's top border, the window maximizes again, but the sidebar is tiny.

Many other applications (like e.g. WebStorm or the Windows Explorer) behave like the "expected result".
Repository: flutter
Issue: [go_router] Convert GoException to sealed class with derived classes for different cases
Labels: c: new feature,package,c: proposal,P3,p: go_router,team-go_router,triaged-go_router

### Use case

in `errorBuilder` we can take the exact routing error from `state.error`.
The exception inside it is pretty generic `GoException` with some text inside.
It would be nice to have `GoException` converted to sealed class with child classes to represent different types of errors.

### Proposal

```dart
sealed class GoException {
  final String message;

  const GoException({required this.message});
}

class NotFoundGoException extends GoException {
  final Uri uri;

  const NotFoundGoException(this.uri)
      : super(message: 'no routes for location: $uri');
}

class RedirectLoopGoException extends GoException {
  RedirectLoopGoException({required super.message});
}

class RedirectLimitGoException extends GoException {
  RedirectLimitGoException({required super.message});
}

class EmptyLocationGoException extends GoException {
  const EmptyLocationGoException()
      : super(message: 'Location cannot be empty.');
}
```
Repository: opencv
Issue: Test_ONNX_conformance.Layer_Test/test_dequantizelinear_blocked_OCV_CPU test fails after 4.x->5.x megre
Labels: bug,category: dnn

### System Information

PR: https://github.com/opencv/opencv/pull/25998
OS: Any

### Detailed description

```
2024-08-06T11:10:23.7211780Z [ RUN      ] Test_ONNX_conformance.Layer_Test/test_dequantizelinear_blocked_OCV_CPU, where GetParam() = (test_dequantizelinear_blocked, OCV/CPU)
2024-08-06T11:10:23.7213089Z Exception during net.forward() call!
2024-08-06T11:10:23.7213718Z unknown file: Failure
2024-08-06T11:10:23.7217903Z C++ exception with description "OpenCV(5.0.0-pre) /home/ci/opencv/modules/dnn/src/int8layers/quantization_utils.cpp:44: error: (-2:Unspecified error) in function 'void cv::dnn::block_repeat(cv::InputArray, const MatShape&, int, int, cv::OutputArray)'
2024-08-06T11:10:23.7220016Z > Axis out of range:
2024-08-06T11:10:23.7220568Z >     'axis >= 0 && axis < src.dims()'
2024-08-06T11:10:23.7221166Z > where
2024-08-06T11:10:23.7221636Z >     'axis' is 1
2024-08-06T11:10:23.7222157Z " thrown in the test body.
2024-08-06T11:10:23.7223682Z [  FAILED  ] Test_ONNX_conformance.Layer_Test/test_dequantizelinear_blocked_OCV_CPU, where GetParam() = (test_dequantizelinear_blocked, OCV/CPU) (1 ms)
```

### Steps to reproduce

Remove the test from denylist, build and run tests.

### Issue submission checklist

- [X] I report the issue, it's not a question
- [X] I checked the problem with documentation, FAQ, open issues, forum.opencv.org, Stack Overflow, etc and have not found any solution
- [X] I updated to the latest OpenCV version and the issue is still there
- [X] There is reproducer code and related data files (videos, images, onnx, etc)
Repository: rust
Issue: run-make: vendor cargo dependencies or external dependencies within the tests
Labels: A-testsuite,C-enhancement,T-compiler,A-run-make

- [ ] tests/run-make/thumb-none-qemu
- [ ] tests/run-make/x86_64-fortanix-unknown-sgx-lvi
- [ ] tests/run-make/thumb-none-cortex-m (uses git clone too)

These tests use cargo to build crates but they have external dependencies -- this makes their pass/fail status conditioned on internet connectivity which does not seem ideal (and also if it's not pinned and it can become awkward from breakages..)

We should investigate if we could vendor the external deps or otherwise make them locally available to make the test outcomes more reproducible.
Repository: godot
Issue: Particle sub-emitters can fail to emit when their parent emitter has a high `fixed_fps`
Labels: bug,topic:particles

### Tested versions

4.2, master (3978628c)

### System information

Godot v4.3.rc (3978628c6) - Arch Linux #1 SMP PREEMPT_DYNAMIC Sun, 04 Aug 2024 05:11:32 +0000 - Wayland - Vulkan (Forward+) - dedicated AMD Radeon RX 6800 XT (RADV NAVI21) - AMD Ryzen 7 5800X3D 8-Core Processor (16 Threads)

### Issue description

When setting the `fixed_fps` property on a particle emitter to some values, its sub-emitters can fail to emit.

https://github.com/user-attachments/assets/584c5e56-53ad-4535-bcf3-583ab222c90d

In this video the white squares are the "parent" emitter and the red squares are the sub-emitters. The slider changes the fixed_fps of the "parent".

### Steps to reproduce

Use the MRP and drag the slider towards the right until, you should see the red subemmiter particles stop showing up at some point.

### Minimal reproduction project (MRP)

[subemmittermrp.zip](https://github.com/user-attachments/files/16510365/subemmittermrp.zip)
Repository: TypeScript
Issue: Unexpected declaration error when using symbols and intersections
Labels: Bug,Help Wanted

### 🔎 Search Terms

- declarations

### 🕗 Version & Regression Information

- This is the behavior in every version I tried, and I reviewed the FAQ for entries about generating declarations.

### ⏯ Playground Link

https://www.typescriptlang.org/dev/bug-workbench/?#code/PTAEAEDMEsBsFMB2BDAtvAXKWB7A5nvAE4B0ALgM4BQ8AHgA45FmgDGOiFLAMvoUQFUASgElQAXlABlAJ6oARjlgAKAES8CxVQEoA3FRoMmLMjPrxQG-lOIA3aKwuSA3qEg4cWLkWiI8oAF9QADJQZypQUABtK2JhEQBdLFd5ZCIvMh8-QP0A-SoQCBgEFHQsZHpocmpoVEZmUAAqUGQKSz5iNyIcVFBVEmBcTSJVfLp6lgATeFZYNIt2ThZIRAB1LAAeAEEAGlAAIQA+ZWQsLe0JQ9BleSx9i-ErrZCD-XHjUGnZ+bYOLjdEJstsdTqBzpdrrcwQ8nvkvnMiAs-ixaFhYqR0TYiPZHPlCoAZckAfBuAel2CmAAKJGZjwSagWxpaDIeQIUAAcmQrNAAAtWqAmKBoG0AK4UXz+UoWVno+KcyDdXp0MjEFCwUCoHCTIUs1TFTAgQYdEageRClisZCIRA4FjyCwSyYkZQAFgADAAmADM2kME1+SxaEgBq2UtD0ZNAgFByH0fRb-eSBlYhsNAA

### 💻 Code

```ts
// @filename: logger.ts
export const LoggerURI = Symbol("Logger");

export type LoggerService = { foo: string } & {
  [LoggerURI]: { bar: string };
};

// @filename: api.ts
import * as Logger from "./logger";

export declare const fnW: <A, B>(a: A) => (b: B) => A & B;
export declare const fn: <A>(a: A) => (b: A) => A;

declare const x: Logger.LoggerService;

// ❌🤯
// Exported variable 'a' has or is using name 'LoggerURI' from external module "file:///logger" but cannot be named.(4023)
export const a = fnW(x);
// ✅
export const b = fn(x);

```


### 🙁 Actual behavior

Unexpected type error:

```
Exported variable 'a' has or is using name 'LoggerURI' from external module "file:///logger" but cannot be named.(4023)
```

### 🙂 Expected behavior

No type error. `LoggerURI` is exported so it can be named.

### Additional information about the issue

_No response_
Repository: ollama
Issue: Support --mlock on the command line. Also there are undocumented model file parameters
Labels: bug

### What is the issue?

The original issue was that my Mac was experiencing an exponential slow down. Upon investigating the issue I noticed my RAM usage was very, very low, but my swap was climbing at the rate of about 1GB per 1K of filled context.

In the end I discovered the --mlock flag in llama.cpp. 
I was in discord asking for help setting it since the command line Ollama straight up rejects it.

Eventually we discovered that this is controlled by the model file parameter use_mlock

Except that appears to be undocumented. In the same space I found a few other undocumented parameters.

So in a nutshell, it would lovely if you could add --mlock to the command line since I don't want to have to edit every model file. Also if you could update the docs so use_mlock and the other undocumented parameters are documented, that would be awesome.

Thanks for your hard work and such a great product!

### OS

macOS

### GPU

Intel

### CPU

Intel

### Ollama version

0.3.3
Repository: godot
Issue: Viewport Render is stretching  when `window.borderless` is `true`
Labels: bug,topic:rendering,needs testing

### Tested versions

4.2.2

### System information

Godot v4.2.2.stable - Windows 10.0.22621 - GLES3 (Compatibility)

### Issue description

- In borderless mode the viewport stretch toward the top and side (where the title bar was) and the mostly top of the viewport being cropped.
	I take some screenshot via `get_viewport().get_texture()` and it fine.
- The mouse position doen't match the one display which again confirm the stretching

### Steps to reproduce

Put a visual element near the top of the game screen (control node)
Toggle borderless mode (via the inpector - remote scene `root` window/viewport)


The provided project:
- has both `Sprite2D` and `TextureRect`
- A button to toggle borderless mode
- Some (maybe usefull) Stats
- A `TextureButton` and mouse position marker

### Minimal reproduction project (MRP)

[Issue__ViewPortSize_WindowBorderless.zip](https://github.com/user-attachments/files/16511052/Issue__ViewPortSize_WindowBorderless.zip)

![Screenshot 2024-08-06 132336](https://github.com/user-attachments/assets/5753deaf-b637-48f7-a46d-5f246416e6b3)
![Screenshot 2024-08-06 132347](https://github.com/user-attachments/assets/ba1de3a6-04a9-4e81-85cf-c28c285e556a)
Repository: next.js
Issue: Middleware not being triggered
Labels: bug,Middleware,Navigation,Runtime

### Link to the code that reproduces this issue

https://github.com/utkarshk384/nextjs-repro

### To Reproduce

1. Run `npm install`
2. Start the server with `npm run dev`

### Current vs. Expected behavior

Middlewares are triggered randomly with no clear trigger pattern. To replicate the issue you can perform the following actions:

1. Head to `/` route
2. Click on `Authenicated Route` to get redirected with a search param of `login=0`
3. Now click on `Set Cookie` and then Click on `Authenticated Route` again
4. This time the middleware won't be triggered as the message won't be console logged.
5. Now if you hard refresh and click on `Authenticated Route` then you'll be able to access the authenticated route. However when I click go back to the root route, and click on `Delete Cookie` and try accessing the route then for some reason I am still able to access the route even without the cookie.


# Expected Behaviour
When logged in, the authenticated route should be accessible without any issues and when not then the user should be redirected to `/` route with `login=0` search param.

# Current Behavior

User is randomly being redirected to authenticated route and sometimes even with the cookie the middleware is not being triggered.

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.2.0: Wed Nov 15 21:53:18 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T6000
  Available memory (MB): 16384
  Available CPU cores: 8
Binaries:
  Node: 20.11.0
  npm: 10.2.4
  Yarn: 1.22.19
  pnpm: N/A
Relevant Packages:
  next: 14.2.5 // Latest available version is detected (14.2.5).
  eslint-config-next: 14.2.5
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.5.4
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Middleware, Navigation, Runtime

### Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local)

### Additional context

I've tested with the next `14.2.5` and with next js version `^13.5.6` and in both cases the issue is persistant.
Repository: tauri
Issue: [bug] custom sign command for windows will be executed for macos / linux build
Labels: type: bug,status: needs triage

### Describe the bug

Custom sign command for windows will be executed for macos / linux build.

Since it's under windows section, it should only be executed for windows build.

I tested with tauri v1

### Reproduction

1. create tauri app with `signCommand` set
2. build on macos or linux for native

### Expected behavior

_No response_

### Full `tauri info` output

```text
[✔] Environment
    - OS: Mac OS 14.4.1 X64
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.81.0-beta.2 (08328a323 2024-07-25)
    ✔ cargo: 1.81.0-beta.2 (a2b58c3da 2024-07-16)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: beta-aarch64-apple-darwin (default)
    - node: 20.12.2
    - pnpm: 8.15.4
    - yarn: 1.22.19
    - npm: 10.8.2

[-] Packages
    - tauri [RUST]: 1.7.1
    - tauri-build [RUST]: 1.5.3
    - wry [RUST]: 0.24.10
    - tao [RUST]: 0.16.9
    - tauri-cli [RUST]: 1.6.0
    - @tauri-apps/api [NPM]: 1.6.0
    - @tauri-apps/cli [NPM]: 1.6.0

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: out
    - devPath: http://localhost:3030/
    - framework: React (Next.js)
    - bundler: Webpack
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: pytorch
Issue: JITerator: Torch.prod produces RuntimeError: CUDA driver error: invalid argument
Labels: needs reproduction,triaged,module: jiterator,oncall: pt2

### 🐛 Describe the bug

There's seems to be a fairly widespread problem with the JITerator where it produces cached kernels that raise "RuntimeError: CUDA driver error: invalid argument". In fact, we know that it is specifically JITerator based, as deleting JITerator cached kernels in .cache/torch/kernels causes the problem to go away:

https://discuss.pytorch.org/t/torch-prod-produces-runtimeerror-cuda-driver-error-invalid-argument/179054/1

It's not clear to me that we as a team should spend time fixing JITerator, but maybe we can figure out how to migrate away from it to a PT2 based on the fly compile solution instead.

### Versions

main

cc @mruberry @chauhang @penguinwu
Repository: excalidraw
Issue: Sans font option
Labels: font

A humble proposal for Public Sans (https://public-sans.digital.gov/) as a strong option for the sans and headline typefaces in excalidraw. Reasons why:

- OFL licensed
- designed for legibility on all modern screens and devices
- variety of weights available
- consistent headline + body look will make excalidraw a little extra corp-friendly
Repository: excalidraw
Issue: Add allowed URL
Labels: Embeddable

I'm just wanting to have my site (https://ellinet13.github.io) allowed.
Repository: PowerToys
Issue: [FancyZones] Android emulator keeps snapping out of the zone.
Labels: Issue-Bug,FancyZones-Dragging&UI,Product-FancyZones,Needs-Triage

### Microsoft PowerToys version

0.83.0

### Installation method

GitHub

### Running as admin

Yes

### Area(s) with issue?

FancyZones

### Steps to reproduce

## Main issue:
Whenever I try to snap the emulator window to a zone it resizes and snaps temporarily then unsnaps out of the zone and it never sticks. The emulator is a floating window launched from CLI using "emulator -avd_name".

## Relevant Settings:
- PowerToys launched as admin.
- "Allow child window snapping enabled"

https://github.com/user-attachments/assets/890d1496-559d-481c-99cc-9c61aeca26d1


[log_2024-08-06.txt](https://github.com/user-attachments/files/16511508/log_2024-08-06.txt)


### ✔️ Expected Behavior

Window snaps and remains in snapped position as per layout

### ❌ Actual Behavior

Emulator window snaps out of the position after a few seconds.

### Other Software

Vanilla Android Emulator
Repository: next.js
Issue: `OPTIONS` requests result in pages being rendered and side effects executed
Labels: bug

### Link to the code that reproduces this issue

https://github.com/kantord/nextjs-options-request-problem-example

### To Reproduce

1. `npm run dev`
2. `curl -X OPTIONS -i http://localhost:3000`

### Current vs. Expected behavior

Current behavior:

- Side effects (such as API calls, DB calls, console log etc etc) are being executed in the server component(s) used in implementing the page
- The response contains a fully rendered HTML body

Expected behavior:

- responses `OPTIONS` requests do not need to have a body, thus I would not expect the page to be actually rendered, especially would not expect side effects of it being executed
- No response bod


### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 ZEN SMP PREEMPT_DYNAMIC Fri, 12 Jul 2024 00:06:19 +0000
  Available memory (MB): 31839
  Available CPU cores: 32
Binaries:
  Node: 21.7.1
  npm: 10.5.0
  Yarn: 1.22.22
  pnpm: 9.6.0
Relevant Packages:
  next: 14.2.5 // Latest available version is detected (14.2.5).
  eslint-config-next: 14.2.5
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.5.4
Next.js Config:
  output: N/A
```


### 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), next start (local), Vercel (Deployed), Other (Deployed)

### Additional context

I think fully rendering a page for an OPTIONS request is at best a performance issue (as there is no need for a response body), at worst a bug (because potential side effects, such as DB calls, tracking, API calls etc are being executed and potentially alter app behavior)

I had this bug happen because a tracker code was executing an OPTIONS request to the root page.