sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: stable-diffusion-webui
Issue: [Bug]: Can't install pythorc=2.1.2 missing
Labels: bug-report

### Checklist

- [ ] The issue exists after disabling all extensions
- [ ] The issue exists on a clean installation of webui
- [ ] The issue is caused by an extension, but I believe it is caused by a bug in the webui
- [ ] The issue exists in the current version of the webui
- [ ] The issue has not been reported before recently
- [ ] The issue has been reported before but has not been fixed yet

### What happened?

ERROR: Could not find a version that satisfies the requirement torch==2.1.2 (from versions: 2.2.0, 2.2.1, 2.2.2, 2.3.0, 2.3.1)
ERROR: No matching distribution found for torch==2.1.2


### Steps to reproduce the problem

run ./webui.sh

### What should have happened?

install packages

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

_No response_

### Sysinfo

can't run

### Console logs

```Shell
Traceback (most recent call last):
  File "/home/michele/IdeaProjects/stable-diffusion-webui/launch.py", line 48, in <module>
    main()
  File "/home/michele/IdeaProjects/stable-diffusion-webui/launch.py", line 39, in main
    prepare_environment()
  File "/home/michele/IdeaProjects/stable-diffusion-webui/modules/launch_utils.py", line 380, in prepare_environment
    run(f'"{python}" -m {torch_command}', "Installing torch and torchvision", "Couldn't install torch", live=True)
  File "/home/michele/IdeaProjects/stable-diffusion-webui/modules/launch_utils.py", line 115, in run
    raise RuntimeError("\n".join(error_bits))
RuntimeError: Couldn't install torch.
Command: "/home/michele/IdeaProjects/stable-diffusion-webui/venv/bin/python3" -m pip install torch==2.1.2 torchvision==0.16.2 --extra-index-url https://download.pytorch.org/whl/cu121
Error code: 1
```


### Additional information

_No response_
Repository: vscode
Issue: Feature: add View: Balance Panes function
Labels: feature-request,layout

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->
[x] Searched and reread CoC
<!-- Describe the feature you'd like. -->

Resizing the panes (editors typically horzontally, bottom panel vertically) is a little slow since it onvolves precision with the mouse then dragging.  There is complete toggle for the whole panel.  But if I want to have a little terminal (say) and lots of editor I can drag it up/down.  But then to get back to a balanced layout requires another drag.  And then back to a small one another drag...  

I'm proposing a function to "balance" the layout.  Probably, it would be a toggle between the current layout and a balanced layout.  So if in one context I want a ittle bit of editor with a lot of terminal, then I want to see equal amounts of editor, I can just repeatedly do "View: Balance Panes" to toggle.  The name is may not be the best.  


So before and after...

     
<img width="624" alt="image" src="https://github.com/microsoft/vscode/assets/216707/2e29de28-fb63-4068-b3e4-32564705f4dd">


I want this to be independent of the side bar (bottom, wherever) nav bar which may be displayed or not but does not affect the notion of equal-width equal-height panes
Repository: flutter
Issue: Skip Xcode automation handling with Xcode 16 and new deployment process
Labels: team-infra,P2,triaged-infra

### Type of Request

infra task

### Infrastructure Environment

Recipes

### What is happening?

Assuming we fix https://github.com/flutter/flutter/issues/133465 with a solution like https://github.com/flutter/flutter/pull/150113, we can stop handling Xcode automation in CI: https://flutter.googlesource.com/recipes/+/refs/heads/flutter-3.22-candidate.0/recipe_modules/os_utils/api.py#408

### Steps to reproduce

_No response_

### Expected results

_No response_
Repository: react
Issue: Bug: onPointerDown not called when rendered in 'display: contents' root
Labels: Type: Bug,Component: DOM

`onPointerDown` listeners are not called in iOS Safari when a React application is rendered within an element that has the `display: contents` CSS rule. This issue seems to be specific to iOS, as it works fine on macOS and Windows.

This bug was discovered through a report in the Astro framework. A user noted that a React component became unclickable after a View Transition, which Astro emulates using JavaScript. Upon investigation, I traced the issue to elements with the `display: contents` rule.

The issue may be related to the `trapClickOnNonInteractiveElement` hack. When a fake `pointerdown` listener is added, the bug disappears and everything works correctly. However, I haven't found any documentation on this behavior, so this is just a hypothesis.

React version: 18.3.1

## Steps To Reproduce

Render React component with <button onPointerDown={() => console.log('called')}>Click me</button> in an element with `display: contents` applied. Try clicking the button in iOS Safari.

See [this page](https://v3ron.github.io/react-pointer-down-ios-bug/) for reproduction.
See [this repository](https://github.com/V3RON/react-pointer-down-ios-bug) for source code.

## The current behavior

`onPointerDown` listener is not called

## The expected behavior

`onPointerDown` listener should be called
Repository: vscode
Issue: Tree Sticky Scroll does not support Touch
Labels: feature-request,tree-sticky-scroll

Type: <b>Bug</b>

I have a Github repository folder opened in VS Code. I am on the Explorer tab.

My repo has a tree with folders & sub-folders. I use a Touchscreen laptop. I am able to tap on individual *files* in the list, and view/edit them in the main pane. However I cannot expand or collapse any of the *folders* in the folder tree, it ignores touchscreen input.

VS Code version: Code 1.89.1 (dc96b837cf6bb4af9cd736aa3af08cf8279f7685, 2024-05-07T05:13:33.891Z)
OS version: Windows_NT x64 10.0.22631
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz (8 x 2995)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: enabled_on<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>skia_graphite: disabled_off<br>video_decode: enabled<br>video_encode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: enabled|
|Load (avg)|undefined|
|Memory (System)|39.71GB (28.12GB free)|
|Process Argv|C:\\Users\\cevan\\OneDrive\\Documents\\GitHub\\saltstack --crash-reporter-id bd9a22d1-462b-4f5d-be87-4ac76ad83dff|
|Screen Reader|no|
|VM|0%|
</details><details><summary>Extensions (14)</summary>

Extension|Author (truncated)|Version
---|---|---
aws-toolkit-vscode|ama|3.9.0
saltstack|kor|0.0.9
jenkins-doc|Maa|1.7.0
vscode-docker|ms-|1.29.1
vscode-kubernetes-tools|ms-|1.3.16
debugpy|ms-|2024.6.0
python|ms-|2024.8.0
vscode-pylance|ms-|2024.6.1
remote-wsl|ms-|0.88.2
makefile-tools|ms-|0.9.10
ansible|red|24.6.0
vscode-yaml|red|1.15.0
salt-lint|war|0.1.0
saltstack-extension-pack|war|0.0.2

(1 theme extensions excluded)

</details><details>
<summary>A/B Experiments</summary>

```
vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscorecescf:30445987
vscod805cf:30301675
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
962ge761:30959799
pythongtdpath:30769146
welcomedialog:30910333
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
pythontestfixt:30902429
pythonregdiag2:30936856
pythonmypyd1:30879173
h48ei257:31000450
pythontbext0:30879054
accentitlementsc:30995553
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
jchc7451:31067544
chatpanelc:31048052
dsvsc021:30996838
bdiig495:31013172
pythoncenvpt:31062603
a69g1124:31058053
dvdeprecation:31068756
pythonprt:31056678
dwnewjupytercf:31046870
26j00206:31048877

```

</details>

<!-- generated by issue reporter -->
Repository: vscode
Issue: Give an option to not autoclose after word character other than "|' characters
Labels: feature-request,editor-autoclosing

Type: <b>Feature Request</b>

According to the source code [here](https://github.com/microsoft/vscode/blob/main/src/vs/editor/common/cursor/cursorTypeOperations.ts#L650) it is hardcoded behavior to skip autoclosing after word character specifically for " and ' characters. It would be nice to add ability to configure what other characters can affect skiping  autoclosing behavior after word character. 

VS Code version: Code 1.90.1 (Universal) (89de5a8d4d6205e5b11647eb6a74844ca23d2573, 2024-06-04T19:34:44.157Z)
OS version: Darwin arm64 22.6.0


<!-- generated by issue reporter -->
Repository: rust
Issue: Bootstrap is slow
Labels: T-bootstrap,C-bug

A fully cached `./x run --stage 1 miri` takes 2.35s. This is really slow, and added to most bootstrap invocations.

Bootstrap is doing a lot of work, and it's nontrivial to optimize all of that, but it leads to these slow times.
There's not gonna be a silver bullet, but I believe this is something we should at least consider and attempt to improve if possible.

One particularly slow aspect is updating the submodules. Another thing I found in my profile is that it spends 10% of the time parsing C++. I do not think every bootstrap invocation should involve parsing C++ code. There's also lots of overhead from cargo, maybe there are unnecessary cargo invocations?

I've attached the flamegraph from `perf record --call-graph=dwarf ./x run --stage 1 miri`.
![out](https://github.com/rust-lang/rust/assets/48135649/95d2beab-9d92-4f25-a708-0081eae4bb9c)
Repository: terminal
Issue: Crash when exiting a tab with the debug tap
Labels: Issue-Bug,Area-UserInterface,Severity-Crash,Product-Terminal

### Windows Terminal version

Commit c52ba7dec6386e11befb62e81e4c0c970a9c5e3e

### Windows build number

10.0.19045.4412

### Other Software

_No response_

### Steps to reproduce

I've had this crash quite frequently in the preview build (I think possibly since v1.21), but I couldn't easily reproduce it. However, I've just discovered I can reproduce it consistently when running Windows Terminal from within the debugger with the following steps:

1. Start Windows Terminal.
2. Open a second tab with the debug tap.
3. Type `exit` to close the second tab.

In both tabs I'm using a WSL bash shell, but I don't think that's relevant. The key thing is typing `exit` to close the tab rather than clicking on the close button.

### Expected Behavior

The tab should close without crashing the terminal.

### Actual Behavior

The terminal crashes with an exception in the `Pane::_CloseChild` method:
```
Unhandled exception thrown: read access violation.
this->_content.**m_ptr** was nullptr.
```

On this line:
https://github.com/microsoft/terminal/blob/a7e2b46e2070d3d493fb05b1ae358c7f7135ab49/src/cascadia/TerminalApp/Pane.cpp#L1433

And with the following stack trace:
```
>	TerminalApp.dll!Pane::_CloseChild(const bool closeFirst) Line 1433	C++
 	TerminalApp.dll!winrt::impl::delegate<winrt::Windows::Foundation::EventHandler<winrt::Windows::Foundation::IInspectable>,`Pane::_CloseChildRoutine'::`2'::<lambda_1>>::Invoke(void * sender, void * args) Line 883	C++
 	[External Code]	
 	WindowsTerminal.exe!WindowEmperor::_createNewWindowThread::__l2::<lambda_1>::operator()() Line 222	C++
 	[External Code]	
```

When I've had this crash in the preview build (assuming it was the same thing), it was usually when I was attempting to compile Windows Terminal and my system was low on memory. At the time I thought the lack of memory might have been a factor, but I suspect now that it might be a timing issue, and the low memory was just slowing the system enough for it to trigger the problem. Either way I'm hoping the trace above is enough for someone to figure out the cause.

I had also initially thought this might be the same bug as #17305, but my dev build has both PR #17333 and PR #17358 applied, so it can't be that.
Repository: flutter
Issue: Flutter supports Sensitive Content Protection 
Labels: platform-android,P1,team-android

Android 15 feature that uses a heuristic that detects passwords and logins plus content that explicitly  calls setContentSensitivity. 

This bug tracks the evaluation of if this feature works in android apps that have flutter views (add to app) and flutter apps that use android views (platform views). This includes a simple method channel implementation. See the issues below for tracking of further improvements.

Relevant issues/ follow up steps:

- https://github.com/flutter/flutter/issues/160051
- https://github.com/flutter/flutter/issues/160050
- https://github.com/flutter/flutter/issues/159208
Repository: three.js
Issue: WebGLRenderTarget Texture breaks glTF export
Labels: Addons

### Description

WebGLRenderTarget textures assigned to objects in the scene cause the GLTFExporter to throw at image export resulting in the glTF export to not work at all

Not sure how to fix this properly - but I believe this shouldnt cause the export from failing altogether

### Reproduction steps

1. Create a WebGLRenderTarget
2. Assign `renderTarget.texture` to some material used in the scene
3. Try export with GLTFExporter
4. Observe error

```js
Error: THREE.GLTFExporter: Invalid image type. Use HTMLImageElement, HTMLCanvasElement, ImageBitmap or OffscreenCanvas.
    at GLTFWriter.processImage (GLTFExporter.js:1323:12)
    at GLTFWriter.processTexture (GLTFExporter.js:1430:17)
    at GLTFWriter.processMaterial (GLTFExporter.js:1516:17)
    at GLTFWriter.processMesh (GLTFExporter.js:1929:26)
    at GLTFWriter.processNode (GLTFExporter.js:2284:27)
    at GLTFWriter.processScene (GLTFExporter.js:2360:28)
    at GLTFWriter.processInput (GLTFExporter.js:2416:10)
    at GLTFWriter.write (GLTFExporter.js:552:8)
    at GLTFExporter.parse (GLTFExporter.js:202:10)
    at exportGLTF (misc_exporter_gltf.html:43:18)
```


### Code

```js
setTimeout(()=>{
	const renderTexture = new THREE.WebGLRenderTarget(256, 256);
	// not necessary but let's render the scene once
	renderer.setRenderTarget( renderTexture );
	renderer.render( scene1, camera );
	renderer.setRenderTarget( null );
	// add the render texture to an object in the scene
	const cube = new THREE.Mesh( new THREE.BoxGeometry( 200, 200, 200 ), new THREE.MeshBasicMaterial( { color: 0xffffff, map: renderTexture.texture } ) );				
	scene1.add( cube );
}, 10)
```


### Live example

https://github.com/needle-tools/three.js/tree/webglrendertarget-breaks-gltfexport

### Screenshots

_No response_

### Version

r165

### Device

Desktop, Mobile, Headset

### Browser

Chrome, Safari

### OS

MacOS
Repository: rust
Issue: Docs produce invalid type when using bounds in associated type position
Labels: T-rustdoc,C-bug,F-associated_type_bounds,A-cross-crate-reexports

When using [bounds in associated type position](https://blog.rust-lang.org/2024/06/13/Rust-1.79.0.html#bounds-in-associated-type-position) on a re-exported function or trait from another crate, the docs produces invalid type.

```rust
// In crate A
pub fn debug_iter() -> impl Iterator<Item: core::fmt::Debug> {
    core::iter::empty::<u8>()
}
```
```rust
// In crate B
pub use A::debug_iter;
```

```rust
// cargo doc -p A
pub fn debug_iter() -> impl Iterator<Item: Debug>
```
```rust
// cargo doc -p B
pub fn debug_iter() -> impl Iterator + Debug
```

### 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.81.0-nightly (8337ba918 2024-06-12)
binary: rustc
commit-hash: 8337ba9189de188e2ed417018af2bf17a57d51ac
commit-date: 2024-06-12
host: x86_64-pc-windows-msvc
release: 1.81.0-nightly
LLVM version: 18.1.7
```
Repository: rust
Issue: `unnameable_types` should show where the type is reachable
Labels: A-lints,A-diagnostics,A-visibility,T-compiler,D-terse,L-unnameable_types

### Code

```Rust
// This is just the documentation sample for the lint
#![deny(unnameable_types)]

mod m {
    pub struct S;
}

pub fn get_unnameable() -> m::S { m::S }
```


### Current output

```Shell
error: struct `S` is reachable but cannot be named
 --> src/lib.rs:5:5
  |
5 |     pub struct S;
  |     ^^^^^^^^^^^^ reachable at visibility `pub`, but can only be named at visibility `pub(crate)`
  |
note: the lint level is defined here
 --> src/lib.rs:2:9
  |
2 | #![deny(unnameable_types)]
  |         ^^^^^^^^^^^^^^^^
```


### Desired output

```Shell
error: struct `S` is reachable but cannot be named
 --> src/lib.rs:5:5
  |
5 |     pub struct S;
  |     ^^^^^^^^^^^^ reachable at visibility `pub`, but can only be named at visibility `pub(crate)`
  |
note: `S` is reachable from here
  |
8 | pub fn get_unnameable() -> m::S { m::S }
  |                            ^^^^ returns a value of type `S`
  |
note: the lint level is defined here
 --> src/lib.rs:2:9
  |
2 | #![deny(unnameable_types)]
  |         ^^^^^^^^^^^^^^^^
```


### Rationale and extra context

The output should give at least one example of how the type is reachable. This will:

* Help understand why the lint is not a false-positive (a reaction I had when first enabling it — “surely these can't be…”).
* If the desired outcome is that the type is *not* reachable, help the user make it not reachable.

Right now, this is a pure “hidden action at a distance” situation: there is no way to discover where the type is reachable other than by searching for uses of it (which can be difficult).

### Other cases

_No response_

### Rust Version

```Shell
rustc 1.79.0 (129f3b996 2024-06-10)
binary: rustc
commit-hash: 129f3b9964af4d4a709d1383930ade12dfe7c081
commit-date: 2024-06-10
host: x86_64-apple-darwin
release: 1.79.0
LLVM version: 18.1.7
```


### Anything else?

@rustbot label +A-lint +A-visibility +L-unnameable_types
Repository: react
Issue: [Compiler Bug]: Compiler incorrectly removes memoization of an expensive operation in useMemo
Labels: Type: Bug,Status: Unconfirmed,Component: Optimizing Compiler

### What kind of issue is this?

- [X] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
- [ ] babel-plugin-react-compiler (build issue installing or using the Babel plugin)
- [ ] eslint-plugin-react-compiler (build issue installing or using the eslint plugin)
- [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script)

### Link to repro

https://playground.react.dev/#N4Igzg9grgTgxgUxALhAMygOzgFwJYSYAEUYCAsgJ4ASEEA1gBQCGAlEcADrFFyFg4iaOkQC8JMuQQBbCI0btRAPg7ci63v0GRpCHAAs8mAOZiiCAB4AHBJjB4AbghasA3Go0w9sYsyIBqIh09QxN3HgBfABoiAG1mAF1WDy8cHyE6cIiQCKA

### Repro steps

The compiler seems to incorrectly erase memoization of possibly expensive operations using `useMemo` in some cases.

Compare the compiler output of the two similar examples, in the first all memoization will be replaced, in the 2nd it will be correctly added in

```
// all memoization is removed, incorrectly
function useMyHook(a) {
  const foo = useMemo(() => {
    const something = expensive(a);
    return a + something;
  }, [a])
  return foo;
}

```

```
// memoization is preserved/added, correctly
function useMyHook(a) {
  const foo = useMemo(() => {
    const something = expensive(a);
    return something;
  }, [a])
  return foo;
}

```

I believe this is a byproduct of how memoization is dependent on the `return` value.

Another side effect of that decision (although already a rule break) is that someone incorrectly using `useMemo` instead of `useEffect` would likely force that effect to run every render (regardless of their deps array that would normally prevent it)



### How often does this bug happen?

Every time

### What version of React are you using?

v17.0.2
Repository: rust
Issue: MIR_borrow_checking and MIR_effect_checking are very slow
Labels: I-slow,A-borrow-checker,T-compiler,A-MIR,C-bug,E-needs-mcve

I tried this code:

https://git.libre-chip.org/libre-chip/fayalite/src/commit/25aa90ec603acdc49a984588e75ba62d7f16b5c4

I expected to see this happen: compile in a reasonably short time

Instead, this happened:
running `cargo +nightly rustc -p fayalite -- -Z time-passes` gives small times for everything except:
```
time:  25.136; rss:  396MB ->  782MB ( +386MB)  MIR_borrow_checking
time:  22.335; rss:  782MB ->  973MB ( +191MB)  MIR_effect_checking
```

I'm running on a Ryzen 9 7950X so this isn't just a slow cpu.

### 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.81.0-nightly (8337ba918 2024-06-12)
binary: rustc
commit-hash: 8337ba9189de188e2ed417018af2bf17a57d51ac
commit-date: 2024-06-12
host: x86_64-unknown-linux-gnu
release: 1.81.0-nightly
LLVM version: 18.1.7
```

compilation is also quite slow on 1.79.0 stable, using `RUSTC_BOOTSTRAP=1 cargo rustc -p fayalite -- -Z time-passes`:
```
time:  24.300; rss:  389MB ->  768MB ( +379MB)  MIR_borrow_checking
time:  21.751; rss:  768MB ->  958MB ( +191MB)  MIR_effect_checking
```
Repository: create-react-app
Issue: Npx create-react-app: 8 vulnerabilities (2 moderate, 6 high)
Labels: needs triage,issue: bug report

### Describe the bug

When I create a new npx create-react-app application and install any dependencies I receive the message: 8 vulnerabilities (2 moderate, 6 high)

### Did you try recovering your dependencies?

I've already started other projects from scratch and also performed global npm updates. Unsuccessful.

### Environment

Environment Info:

  current version of create-react-app: 5.0.1
  running from C:\Users\joseg\AppData\Local\npm-cache\_npx\c67e74de0542c87c\node_modules\create-react-app

  System:
    OS: Windows 11 10.0.22631
    CPU: (16) x64 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz
  Binaries:
    Node: 22.2.0 - C:\Program Files\nodejs\node.EXE
    Yarn: Not Found
    npm: 10.8.1 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: Not Found
    Edge: Chromium (125.0.2535.92)
    Internet Explorer: 11.0.22621.3527
  npmPackages:
    react: ^18.3.1 => 18.3.1
    react-dom: ^18.3.1 => 18.3.1
    react-scripts: 5.0.1 => 5.0.1
  npmGlobalPackages:
    create-react-app: Not Found

### Steps to reproduce

1. npx create-react-app .

### Expected behavior

The correct thing would be not to show any type of error.

### Actual behavior

Imagem from error:
![image](https://github.com/facebook/create-react-app/assets/57471773/4d4e7cf8-010b-441a-920d-2df15e77eccf)

After run npm fund

![image](https://github.com/facebook/create-react-app/assets/57471773/2b0b1eb2-dc6d-4d83-a90a-37736ab35882)