sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: Update CupertinoScrollbar for macOS
Labels: framework,f: scrolling,f: cupertino,P3,team-design,triaged-design

Follow up to https://github.com/flutter/flutter/pull/138189

We auto-adapt on iOS, but not macOS. See `material/scrollbar.dart`.

---

After looking into doing this right quick, I realized it would not be so straight forward.
The CupertinoScrollbar implements the iOS spec, not the native macOS behaviors. They are different!
The Material Scrollbar that is currently shown on macOS is more like the native one (which is great! 👍 ), it supports hovering and does not change size when dragged.
If we want to auto-adapt a macOS scrollbar like we do on iOS, the CupertinoScrollbar will need to be updated to support the native behaviors from macOS.
Repository: pytorch
Issue: [cuDNN][cuDNN V8 API] cuDNN Flash-Attention Upstreaming RFC/tracking issue
Labels: module: cudnn,module: cuda,triaged,module: sdpa

### 🚀 The feature, motivation and pitch

cuDNN has been brewing its own flavor of flash attention (v2) for some time now, and it appears to be ready for integration into upstream PyTorch.

The current implementation uses the new graph API provided by the yet-to-be finalized cuDNN v1.0 frontend. It also differs from previous cuDNN frontend integrations, such as for convolution (see #https://github.com/pytorch/pytorch/issues/58414), in that the flash-attention implementation requires some (lightweight) runtime compilation. Of course, these will be cached after the initial compilation. Additionally, the support matrix is not as exhaustive as that of convolution---there are requirements on the strides (inputs must be contiguous, with stride 1 in the embedding dimension), inputs must have dtype `bfloat16` or `float16`, and  only hardware newer than compute capability 8.0 is supported, etc.
 
I've outlined the following steps to be considered for integration, including potential issues that could surface along the way.
Early performance benchmarks (`bfloat16`, `H100`):
https://docs.google.com/spreadsheets/d/17fckdkCB3JRjugevDTcSfP4cBCmaGS1qNckiuJXBm-k

- [x] Step 0: Initial forward pass proof-of-concept. Here, we consider the forward pass to be experimentally functional, though not all shapes and compute-capabilities are well-tested. Note that we would require the cuDNN frontend 1.0 interface to be finalized and released at this point. Prototype implementation: https://github.com/pytorch/pytorch/compare/main...eqy:pytorch:cudnnmha3 At this point, the implementation can be tried with `TORCH_CUDNN_MHA_ENABLED=1` The existing context managers for selecting SDP backends would also apply to the cuDNN implementation at this point as well.
- [x] Step 1: Forward pass + backward pass and bells and whistles like dropout
- [x] Step 2: (WE ARE HERE) Robustness, incl.  shape checks before dispatching into cuDNN MHA, handling of workspace size limitations, etc.
- [ ] Step 3: `TORCH_CUDNN_MHA_ENABLED=1` becomes `TORCH_CUDNN_MHA_DISABLED=0`, and it is enabled by default alongside existing SDP backends.

CC @drisspg @ptrblck @malfet 

### Alternatives

_No response_

### Additional context

_No response_

cc @csarofeen @ptrblck @xwang233 @msaroufim @jbschlosser @bhosmer @cpuhrsch @erichan1 @drisspg @mikaylagawarecki
Repository: rust
Issue: Disallow future-incompatibility lints in the 2024 edition
Labels: A-lints,T-lang,A-maybe-future-edition,C-discussion

We have quite a long list of [future-incompatibility lints](https://github.com/rust-lang/rust/labels/C-future-compatibility) that are waiting to be made into hard errors. The lints are so severe that we warn even when they are used by a dependency of the crate being built, because they will cause the crate to stop compiling at some point in the future.

We could use the edition as an impetus to switch some or all of these lints over to hard errors (or deny-by-default lints). Note that because of the way editions work this would only affect the crate being upgraded, not its dependencies. This would mean pairing the carrot with the stick, so to speak; if any of the crates triggering these errors are upgraded to the edition they will also need to have their future-incompat issues fixed. It also means that new code (using the latest edition) won't be written that triggers these lints.

On the other hand it's unlikely that the crates with future-incompat issues are being maintained in the first place, so this wouldn't do much to help the problem.

Opening this issue for discussion and consideration by the lang team.

For some background on how we handled this in past editions, see https://github.com/rust-lang/rust/issues/80165#issuecomment-791583502.
Repository: pytorch
Issue: [ONNX] Refactor xfail API to handle conditional failure scenarios
Labels: module: onnx,triaged

### 🐛 Describe the bug

Tracked from https://github.com/pytorch/pytorch/pull/112289#discussion_r1379074723

### Versions

main
Repository: go
Issue: runtime,cmd/compile: segfaults on loong64
Labels: NeedsInvestigation,arch-loong64,compiler/runtime

```
#!watchflakes
post <- goarch == "loong64" && (log ~ `signal: segmentation fault \(core dumped\)` || log ~ `runtime error: invalid memory address or nil pointer dereference`)
```

Issue created automatically to collect these failures.

Example ([log](https://build.golang.org/log/89ca2b636492e80e9486d77e2e447cea78560640)):

    signal: segmentation fault (core dumped)


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: godot
Issue: Empty test project fails to successfully export to Xcode in Godot 4.1.3, 4.2 RC2
Labels: bug,platform:ios,topic:editor,topic:export

### Godot version

Godot 4.1.3, 4.2 RC2

### System information

Mac Sonoma 14.0, Xcode 15.0.1 (M2 Mac) (Latest of everything as far as I can tell)

### Issue description

An empty test project with a simple Node2D with a label inside it fails to export for iOS. The error returned is:

    /Users/scripturial/Downloads/ios/TempTestDeleteMe.xcodeproj: error:
    "TempTestDeleteMe" requires a provisioning profile. Select a provisioning
    profile in the Signing & Capabilities editor. (in target 'TempTestDeleteMe'
    from project 'TempTestDeleteMe')
    ** ARCHIVE FAILED **

The project is half exported, and this half exported project half works, but it is incomplete. (For example, if I add the SQLite plugin, the plugin files don't appear to be copied into Xcode and SQLite does not work.

### Steps to reproduce

 - Create an empty project with a simple label
 - Add some icons to make sure the exporter doesn't get upset about the icons
 - Use the Export panel to create an iOS export
 - do an export.
 
 It doesn't seem like it matters what export settings I enter, it always produces the error. But here is what I have in my test project:
 
 
<img width="471" alt="image" src="https://github.com/godotengine/godot/assets/138373494/d6095e91-58c3-4bf3-ad65-0d5f72f7f61a">


### Minimal reproduction project

It's literally an empty project? Should I upload it?
Repository: ant-design
Issue: treeSelect如何指定让节点显示title以外的属性
Labels: 💡 Feature Request,Inactive

### What problem does this feature solve?

我不确定现在是否能实现我的需求

### What does the proposed API look like?

TreeSelect上暴露一个属性用于判断treeNode显示哪个属性

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: flutter
Issue: MultiChildRenderObjectElement is held by RendererBinding.pipelineOwner (that is deprecated) from GC.
Labels: a: leak tracking

PR that marks the test: https://github.com/flutter/flutter/pull/137812

Steps to repro:
1. Add `LeakTesting.settings = LeakTesting.settings.withTracked(allNotGCed: true);` as first line in main of `flutter/test/rendering/viewport_test.dart`
2. Remove `withIgnored` for some tests added by the PR above
3. See the test failing

Also test with `--test-randomize-ordering-seed=20231114`.

notGCed leaks are not enabled for the library, because the leaks are flacky.
Repository: pytorch
Issue: Can the official provide cpu offload method for large model inference?
Labels: feature,triaged,needs design

### 🚀 The feature, motivation and pitch

Provides functions similar to those used in diffuser. 
from accelerate import cpu_offload_with_hook

### Alternatives

_No response_

### Additional context

_No response_
Repository: next.js
Issue: static.edge is not exported from react-dom - error when packaging NextJS app using custom server
Labels: bug

### Link to the code that reproduces this issue

https://github.com/seanjb/nextjs-custom-server-ncc-issue

### To Reproduce

1. run `npm install`
2. run `npm run build` - app builds fine
2. run `npm run start ` - app starts fine using custom server
3. run `npm run package` - error thrown about react-dom not exposing server.edge

### Current vs. Expected behavior

Current Behaviour
The below error is thrown when NCC tries to package the next custom server

Error: Module not found: Error: Package path ./server.edge is not exported from package C:\dev\test-ncc\node_modules\react-dom (see exports field in C:\dev\test-ncc\node_modules\react-dom\package.json)
Did you mean './react-dom/static.edge'?
Requests that should resolve in the current directory need to start with './'.
Requests that start with a name are treated as module requests and resolve within module directories (node_modules).
If changing the source code is not an option there is also a resolve options called 'preferRelative' which tries to resolve these kind of requests in the current directory too.

Expected Behaviour
Would expect the code to compile into a single JS file using NCC without issue.

### 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: 18.16.0
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 13.5.6
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.2.2
Next.js Config:
  output: N/A


warn  - Latest canary version not detected, detected: "13.5.6", newest: "14.0.3-canary.8".
        Please try the latest canary version (`npm install next@canary`) to confirm the issue still exists before creating a new issue.
        Read more - https://nextjs.org/docs/messages/opening-an-issue
```


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

Not sure

### Additional context

I suspect this is in fact a Next dependency issue - but I have raise a sister issue https://github.com/vercel/ncc/issues/1138 incase it is specifically NCC related. 

My end goal here is to have a single JS file (with all dependencies included) for the custom server, so if using NCC is the wrong approach to take I am open to suggestions.
Repository: rust
Issue: std::simd generates a lot of cpu instructions on opt-level=z
Labels: A-LLVM,C-optimization

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code:

```rust
#![feature(portable_simd)]

use std::simd::prelude::*;

pub fn bigger_diffs(a: [u64; 64], other: [u64; 64]) -> u128 {
    let first = u64x64::from_array(a);
    let second = u64x64::from_array(other);
    let (a, b) = (first.saturating_sub(second), second.saturating_sub(first));
    (a ^ b).reduce_sum() as u128
}
```

I expected to see this happen: 
Under opt-level=z on default x86_64 target I expect the compiler to generate a loop with some jumps

Instead, this happened: 
It generated more than 1200 instructions, seemingly unrolling some kind of a loop

### 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.76.0-nightly (ba7c7a301 2023-11-13)
binary: rustc
commit-hash: ba7c7a301984967c8c13adb580ef9b86ba706a83
commit-date: 2023-11-13
host: x86_64-unknown-linux-gnu
release: 1.76.0-nightly
LLVM version: 17.0.4
```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Backtrace</summary>
<p>

```
RUST_BACKTRACE=1 cargo build
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
$ ./target/debug/simd_unroll
0
```

</p>
</details>
Repository: kubernetes
Issue: E2e framework should have Azure SSH support but still "/root/.ssh/id_rsa: no such file or directory"
Labels: sig/testing,kind/failing-test,area/provider/azure,sig/cloud-provider,needs-triage

### Which jobs are failing?

https://testgrid.k8s.io/provider-azure-cloud-provider-azure#cloud-provider-azure-conformance-serial-vmss-capz

### Which tests are failing?

Kube-proxy should recover after being killed accidentally
Kubelet should not restart containers across restart

### Since when has it been failing?

2023.11.5

### Testgrid link

https://testgrid.k8s.io/provider-azure-cloud-provider-azure#cloud-provider-azure-conformance-serial-vmss-capz

### Reason for failure (if possible)

Recently there's a [PR](https://github.com/kubernetes/kubernetes/pull/121708) to support SSH in e2e framework. Since Azure is now in the list of `ProvidersWithSSH`, our cloud-provider-azure job starts testing 2 tests which are not covered before:
```
Kube-proxy should recover after being killed accidentally
Kubelet should not restart containers across restart
```
However, the support seems incomplete according to the error:
```
Nov 14 19:54:38.766: INFO: Unexpected error: Daemon kube-proxy on node 10.1.0.4 did not respond with a 200 via curl -s -o /dev/null -I -w "%{http_code}" http://localhost:10256/healthz within 10m0s: 
    <*fmt.wrapError | 0xc003afa5c0>: 
    error getting signer for provider azure: error reading SSH key /root/.ssh/id_rsa: open /root/.ssh/id_rsa: no such file or directory
    {
        msg: "error getting signer for provider azure: error reading SSH key /root/.ssh/id_rsa: open /root/.ssh/id_rsa: no such file or directory",
        err: <*fmt.wrapError | 0xc003afa5a0>{
            msg: "error reading SSH key /root/.ssh/id_rsa: open /root/.ssh/id_rsa: no such file or directory",
            err: <*fs.PathError | 0xc003cc3830>{
                Op: "open",
                Path: "/root/.ssh/id_rsa",
                Err: <syscall.Errno>0x2,
            },
        },
    }
```
@aravindhp @jsturtevant @marosset 


### Anything else we need to know?

_No response_

### Relevant SIG(s)

/sig
Repository: deno
Issue: Reject Deno.openKv() if remote is invalid
Labels: suggestion,ext/kv

All errors encountered with `Deno.openKv()` should reject to allow them to be handled by user code.

Currently, invalid connections or issues with connecting result in information be written to stderr while the promise resolves with a `Kv` instance where any methods just "hang".  This actually makes it impossible to determine from code if you have successfully connected to a remote KV instance.

A sample reproduction using the CLI where the target does not exist. Similar things happen when you supply the wrong protocol (e.g. `https` versus `http`) while errors with an invalid token reject on individual methods of the KV instance (versus rejecting on open):

```
$ DENO_KV_ACCESS_TOKEN=abcdef deno --unstable
Deno 1.38.1
exit using ctrl+d, ctrl+c, or close()
REPL is running with all permissions allowed.
To specify permissions, run `deno repl` with allow flags.
> const kv = await Deno.openKv("http://localhost:4444");
undefined
> KV Connect to 'http://localhost:4444/' failed to fetch metadata: error sending request for url (http://localhost:4444/): error trying to connect: tcp connect error: Connection refused (os error 61)
KV Connect to 'http://localhost:4444/' failed to fetch metadata: error sending request for url (http://localhost:4444/): error trying to connect: tcp connect error: Connection refused (os error 61)

undefined
> kv
Kv {}
> KV Connect to 'http://localhost:4444/' failed to fetch metadata: error sending request for url (http://localhost:4444/): error trying to connect: tcp connect error: Connection refused (os error 61)
> await kv.get(["a"]);
KV Connect to 'http://localhost:4444/' failed to fetch metadata: error sending request for url (http://localhost:4444/): error trying to connect: tcp connect error: Connection refused (os error 61)
```
Repository: pytorch
Issue: torch.compile + SAC: mutations in backward are not preserved
Labels: oncall: distributed,module: checkpoint,triaged,needs design,oncall: pt2,module: aotdispatch,module: pt2-dispatcher,pt2d-triage-nov2024

### 🐛 Describe the bug

As titled. To repro:
1. Remove the `@unittest.skip` block on top of
`test/dynamo/test_activation_checkpointing.py::ActivationCheckpointingViaTagsTests::test_compile_selective_checkpoint_inplace_op`
(code pointer: https://github.com/pytorch/pytorch/blob/9724d0fd87af6107a22dc06d7a7fda5a26fa0615/test/dynamo/test_activation_checkpointing.py#L578)
2. Run:
`TORCH_COMPILE_DEBUG=1 pytest -vs test/dynamo/test_activation_checkpointing.py::ActivationCheckpointingViaTagsTests::test_compile_selective_checkpoint_inplace_op`
3. We get this log: https://gist.github.com/yf225/0e8ebcbaa4aa05db1a80e18e51a7d4d1. Notice that `__compiled_fn_0` has the in-place ops (as expected), but `Joint graph 0` doesn't have the in-place ops (which seems not correct).


### Versions

PyTorch nightly

cc @H-Huang @awgu @kwen2501 @wanchaol @fegin @fduwjj @wz337 @wconstab @d4l3k @c-p-i-o @soulitzer @chauhang @penguinwu @zou3519 @bdhirsh @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @XilunWu @tianyu-l @ezyang @msaroufim @anijain2305 @kiukchung @lucasllc
Repository: stable-diffusion-webui
Issue: [Bug]: why the same setting in webui supermerge, but generate different image?
Labels: bug-report

### Is there an existing issue for this?

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

### What happened?

I have set the prompt, neg prompt,seed,sampling method,steps,width....everything in same.
but when I use the different mbw alpha, the generate image is almost in same, while a little different. 
for example, I sent 6 different mbw alphas, and generate 6 image in a big image, between the 6 images, there are look similar,
but when I sent the same setting mbw alpha and same model, generate twice, then the generate images are very different?  
I wander why? what has happended?
Is the same batch of mbw alphas use the same noise? but different alphas use different noise even the setting,model is the same? 
The seed can not control the noise?
how can I show my result, if you can see the image that I generate, you will understand everything.

### Steps to reproduce the problem

1. Go to .... 
2. Press ....
3. ...


### What should have happened?

in the same setting, the same model generated images should look more similar, while different model should more different.


### Sysinfo

none

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

_No response_

### Console logs

```Shell
none
```


### Additional information

_No response_
Repository: PowerToys
Issue: improving windows explorer
Labels: Product-File Explorer,Needs-Triage

### Description of the new feature / enhancement

we urgently need tools to

- force windows explorer to sort entries (folders as well as files) by calender date
- force windows explorer to display details view in every folder

### Scenario when this would be used?

everydays work with windows explorer

### Supporting information

_No response_
Repository: pytorch
Issue: Plan for transformer module based ROCm
Labels: module: rocm,triaged,ciflow/rocm

### 🚀 The feature, motivation and pitch

Is there any plan for transformer module based ROCm?
Thanks :)
https://github.com/pytorch/pytorch/commit/94c9dbff22f18d319b0ce792f7a509d2c90b1a97

### Alternatives

_No response_

### Additional context

_No response_

cc @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang
Repository: go
Issue: slices: better panic message for out of range Insert
Labels: NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version 
go version go1.21 darwin/arm64
</pre>

### Does this issue reproduce with the latest release?
Yes


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/sedyh/Library/Caches/go-build"
GOENV="/Users/sedyh/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/sedyh/Desktop/share/go/path/go1.21.1/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/sedyh/Desktop/share/go/path/go1.21.1"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/sedyh/Desktop/share/go/root/go1.21.1"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/sedyh/Desktop/share/go/root/go1.21.1/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.21.1"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/x5/kntr8jy137vg9cjlm83chwmh0000gn/T/go-build3952104386=/tmp/go-build -gno-record-gcc-switches -fno-common"
</pre></details>

### What did you do?

For some reason `slices.Insert` causes out of bounds panic if there no values at `if !overlaps(v, s[i+m:]) {}`.

As far as I can see in https://go.dev/cl/540155, this is intended, but it seems wrong to me, because:
- I don't see any point in this. I think this is the only case why I wanted to use it.
- This case is not processed separately, it is a standard out of bounds panic.
- This is not stated in the function comments.

### What did you expect to see?

```go
s := []float64{}
s = slices.Grow(s, 5)
s = slices.Insert(s, 4, 1.0)
```

The function works the same regardless of how full the slice is.

### What did you see instead?

```panic: runtime error: slice bounds out of range [5:1]```

This is not a specially caused panic, it looks like a missed case.