sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: material-ui
Issue: [RFC] Change Checkbox padding from 9px to 8px
Labels: design: material,component: checkbox,RFC

### What's the problem?

The hover & click padding of the Checkbox component is having 9px padding.
I know the default spacing of MUI (and the most common one in general) is 8px.
It leads to negative margins needed to align the checkbox properly in some cases.

### What are the requirements?

_No response_

### What are our options?

_No response_

### Proposed solution

I think MUI should consider changing the Checkbox padding to 8px.

### Resources and benchmarks

![image](https://github.com/user-attachments/assets/572be599-2090-4a3d-9a23-6d43ee9c0895)


**Search keywords**:
Repository: rust
Issue: Tracking Issue for AArch64 MTE memory tagging intrinsics
Labels: T-libs-api,C-tracking-issue,F-stdarch_aarch64_mte

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(stdarch_aarch64_mte)]`

This is a tracking issue for AArch64 MTE memory tagging intrinsics.

<!--
Include a short description of the feature.
-->

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

```rust
// core::arch::aarch64

pub unsafe fn __arm_mte_create_random_tag<T>(src: *const T, mask: u64) -> *const T;
pub unsafe fn __arm_mte_increment_tag<const OFFSET: i64, T>(src: *const T) -> *const T;
pub unsafe fn __arm_mte_exclude_tag<T>(src: *const T, excluded: u64) -> u64;
pub unsafe fn __arm_mte_set_tag<T>(tag_address: *const T);
pub unsafe fn __arm_mte_get_tag<T>(address: *const T) -> *const T;
pub unsafe fn __arm_mte_ptrdiff<T, U>(a: *const T, b: *const U) -> i64;
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [x] Implementation: https://github.com/rust-lang/stdarch/pull/1627
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilization PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- None yet.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: vscode
Issue: support finding matches in the debug console's output
Labels: feature-request,debug-console

blocked on https://github.com/microsoft/vscode/issues/212077 and possible perf issues
Repository: go
Issue: path/filepath: Rel() fails on Windows when only one parameter has `\\?\` prefix
Labels: OS-Windows,NeedsInvestigation

### Go version

go version devel go1.24-47cdc43289 Mon Aug 12 13:09:41 2024 -0400 windows/amd64

### Output of `go env` in your module/workspace:

```shell
PS C:\Users\Dan\REPOS\go\src> ..\bin\go.exe env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Dan\AppData\Local\go-build
set GOENV=C:\Users\Dan\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\Dan\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\Dan\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Users\Dan\REPOS\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLCHAIN=auto
set GOTOOLDIR=C:\Users\Dan\REPOS\go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=devel go1.24-47cdc43289 Mon Aug 12 13:09:41 2024 -0400
set GODEBUG=
set GOTELEMETRY=local
set GOTELEMETRYDIR=C:\Users\Dan\AppData\Roaming\go\telemetry
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=0
set GOMOD=C:\Users\Dan\REPOS\go\src\go.mod
set GOWORK=
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=C:\Users\Dan\AppData\Local\Temp\go-build933240645=/tmp/go-build -gno-record-gcc-switches
```


### What did you do?

* Used patchset 3 of my demo CL: https://go-review.googlesource.com/c/go/+/604875/3 on top of d36353499f673c89a267a489beb80133a14a75f9
* Ran `.\all.bat`

### What did you see happen?

```
--- FAIL: TestRelWindows (0.00s)
    path_windows_test.go:734: Rel("C:\\foo", "\\\\?\\C:\\foo\\bar") = "", Rel: can't make \\?\C:\foo\bar relative to C:\foo; want "bar"
    path_windows_test.go:734: Rel("C:/foo", "//?/C:/foo/bar") = "", Rel: can't make //?/C:/foo/bar relative to C:/foo; want "bar"
    path_windows_test.go:734: Rel("\\\\?\\C:\\foo", "C:\\foo\\bar") = "", Rel: can't make C:\foo\bar relative to \\?\C:\foo; want "bar"
    path_windows_test.go:734: Rel("//?/C:/foo", "C:/foo/bar") = "", Rel: can't make C:/foo/bar relative to //?/C:/foo; want "bar"
FAIL
FAIL    path/filepath   1.568s
```

### What did you expect to see?

The demo CL (<https://go-review.googlesource.com/c/go/+/604875/3>) contains several expectations, but I'll pick one. I'm particularly surprised that the relative path from basepath `\\?\C:\foo` to targpath `\\?\C:\foo\bar` is an error instead of `bar`.

I'm a little out of my depth, but this Microsoft documentation (<https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-file-namespaces>) seems to indicate that `\\?\` is just a way of turning off string parsing in Windows APIs.

I think it should be possible to work around this limitation, for instance by prefixing `\\?\` onto the parameters when they are already absolute paths.
Repository: rust
Issue: Incremental compilation relies on hashes for soundness
Labels: T-lang,T-compiler,A-incr-comp,C-bug

Incremental compilation relies on hashes for soundness -- specifically, on SipHash-1-3 with an all-zero key, which is not a cryptographic hash function. Collisions in that hash can lead to UB and other ill effects. Is that a problem? Should we do things to mitigate the risk of that? Or do we tell people they are expected to use non-incremental builds if they actually want to rely on the soundness of the result? Or is this not a bug at all and the current hashing scheme is "good enough"? After all, as @the8472 argues, if the programmer doesn't actively try to exploit the hard-coded all-zero key they are quite unlikely to hit a collision by pure chance. (That should follow from the fact that SipHash is a PRF, but I am no cryptographer.)

Fixing this by using a cryptographic hash is likely to be [very bad for performance](https://github.com/rust-lang/rust/pull/127809#issuecomment-2233743267). However, @michaelwoerister mentions that there could be cheaper mitigation techniques:

> Unless I'm overlooking something all incr. comp. specific hashes only need to be stable between successive incremental builds. So we can easily harden our use of SipHash there by generating random keys and then caching these in the incr. comp. cache.

If we use a truly random key for this, we could rely on SipHash being a cryptographic PRF -- without knowing the key, it's supposed to be very hard to find collisions. However, that promise is typically made for SipHash-2-4, not the weakened variant SipHash-1-3 that rustc uses. There seems to be [evidence](https://github.com/rust-lang/rust/issues/10389#issuecomment-2243667340) that even the weaker function is "good", but I'll leave it to cryptographic experts to evaluate the evidence here. @briansmith would be good to get your take on this.

Nominating for t-lang discussion to see what their stance is on the soundness requirements for incremental compilation, and whether relying on a non-collision-resistant hash function for soundness is "good enough" -- or whether this should be considered an implementation decision, to be made by t-compiler. ([Previously](https://github.com/rust-lang/rust/pull/95845#issuecomment-1175324596), t-lang ruled that TypeId should use a "full (non-truncated) cryptographic hash", but the tradeoffs are quite different here so it's not at all clear that the same decision would apply to incremental hashes.)

EDIT: I have moved the nomination to https://github.com/rust-lang/rust/issues/129030 as that broader question directly affects this more specific question.
Repository: vscode
Issue: 1 paste requires 2 undo operations to revert
Labels: feature-request,editor-autoindent,undo-redo

<!-- ⚠️⚠️ 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. -->

<!-- 🪓 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. -->


https://github.com/microsoft/vscode/issues/113453
I'm experiencing the same, but the original bug report was closed. 
It was said in the thread there that "If there are a lot more people hitting this, then I would add a setting." 
I'm another person who is hitting this issue and finds it very annoying to have to undo twice, as I never ever encounter a situation where I need to undo the formatting only. 
Please consider reopening the original issue or adding a setting so that we could configure 'undo' to undo the pasting event completely in one go.
Repository: vscode
Issue: Editor GPU: Rasterizer should support sub-pixel coordinates
Labels: plan-item,editor-gpu

Parent: #221145

Currently all glyphs for a particular metadata all look the same. The idea here is to allow glyphs to use sub-pixel offsets for more natural rendering.

See how the `e` in the DOM actually result in different pixels:



![Image](https://github.com/user-attachments/assets/accb1f28-2052-4378-af74-8e02734619a1)
Repository: godot
Issue: Baking Lightmaps with LightmapGI breaks meshlibrary (Gridmap) transforms.
Labels: bug,topic:rendering,topic:3d

### Tested versions

- Reproducible in 4.3 rc3
- Reproducible in 4.2.2 stable

### System information

Godot v4.3.rc3 - Fedora Linux 40 (KDE Plasma) - Wayland - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3080 (nvidia; 555.58.02) - 11th Gen Intel(R) Core(TM) i9-11900K @ 3.50GHz (16 Threads)

### Issue description

When baking lightmaps with LightmapGI, (VoxelGI untested) all transforms that I had saved into my meshlib revert, until I interact with the Gridmap again. Note that these transforms aren't the rotation I placed the grids with, rather the rotations I made while making the meshlibrary so they would all be properly aligned.

### Steps to reproduce

1. Get a random MeshInstance, doesn't matter where, it happened with GLTF files too.
2. Rotate it while creating the MeshLibrary and Unwrap the UV2 for Lightmaps
3. Save the MeshLibrary with the transforms you just made.
4. Put a Gridmap in another scene and place some of that tile from the MeshLibrary
5. Place a DirectionalLight, LightmapGI
6. Bake lights on the LightmapGI and watch the rotated tiles ignore the MeshLibrary transforms.
7. To undo the effect, interact with the GridMap, this will also destroy the Baked lights.

### Minimal reproduction project (MRP)

Note: Created in 4.3 rc3
Just open level.tscn and bake the lights on LightmapGI, the effect should immediately become visible.
[Archive.zip](https://github.com/user-attachments/files/16590233/Archive.zip)
Repository: pytorch
Issue: [torch.compile] tighten FX graph restrictions post-functionalization
Labels: triaged,oncall: pt2,module: inductor,module: pt2-dispatcher

Chatting with @eellison, there are some invariants that would be nice to have:
- [ ] no targets are OpOverloadPacket (they're either a HOP or OpOverload)
- [ ] OpOverloads's args are the non-kwonly-args and the kwargs are the kw-only args, or some other standard convention. This is true after tracing but might not be true after graph passes!
- [ ] node.meta["val"] are all populated. Or maybe we should make FakeTensorUpdater faster (https://github.com/pytorch/pytorch/blob/main/torch/_inductor/fx_utils.py#L55), it is currently O(# of nodes in graph)
- [ ] Inductor pattern matcher's replacement graph is assumed to be functional, but we don't check this. Also related: #134363


cc @ezyang @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire @bdhirsh
Repository: PowerToys
Issue: An option to pin sections so it's easier to turn off and turn back on
Labels: Idea-Enhancement,Product-Keyboard Shortcut Manager,Needs-Triage

### Description of the new feature / enhancement

Hi. I want to be able to toggle my Keyboard Manager without having it going back to the full list of toggles. 

So like an option to pin modules so I don't have to scroll all the way through modules to find my Keyboard Manager to enable it again when I turn it off.

OR 

You can implement a thing inside the Keyboard Manager to toggle remaps on and off, so I wouldn't have to toggle the whole keyboard manager to have the first problem listed above.

### Scenario when this would be used?

When toggling keyboard manager on and off

### Supporting information

_No response_
Repository: next.js
Issue: Turbopack can't locate serverExternalPackages if installed via pnpm and are child dependencies of other installed modules
Labels: bug,Turbopack,linear: turbopack

### Link to the code that reproduces this issue

https://github.com/jmikrut/nextjs-68805

### To Reproduce

1. Install dependencies via pnpm
2. Run `pnpm dev --turbo`
3. Go to http://localhost:3000/admin

### Current vs. Expected behavior

Turbopack fails to compile, and the terminal blows up with errors such as the following:

```
Package @libsql/client (serverExternalPackages or default list) can't be external
The request @libsql/client matches serverExternalPackages (or the default list), but it can't be external:
The request could not be resolved by Node.js from the project directory.
Packages that should be external need to be installed in the project directory, so they can be resolved from the output files.
Try to install the package into the project directory.
```

If you install dependencies with Yarn, or with `npm i --legacy-peer-deps`, the dependencies are located correctly with Turbopack.

Note that all dependencies which error are indeed installed as dependencies of installed packages. Webpack works, but Turbopack does not.


### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.0.0: Wed Jul 31 21:51:10 PDT 2024; root:xnu-11215.0.199.501.2~1/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 10
Binaries:
  Node: 20.11.1
  npm: 10.2.4
  Yarn: 1.16.0
  pnpm: 8.15.7
Relevant Packages:
  next: 15.0.0-canary.111 // Latest available version is detected (15.0.0-canary.111).
  eslint-config-next: 15.0.0-canary.104
  react: 19.0.0-rc-06d0b89e-20240801
  react-dom: 19.0.0-rc-06d0b89e-20240801
  typescript: 5.5.4
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Turbopack

### Which stage(s) are affected? (Select all that apply)

next dev (local)

### Additional context

This appears to have broken in `next@15.0.0-canary.84`. Worked before that.
Repository: pytorch
Issue: Shared memory out of resource when using flex attention
Labels: triaged,oncall: pt2,module: inductor,module: flex attention

### 🐛 Describe the bug

When I use flex attention on one RTX 4090, I got some error.
A minimal repro:
```python
import torch
from torch.nn.attention.flex_attention import flex_attention
flex_attention = torch.compile(flex_attention, dynamic=False)

B = 1
H = 16
S = 2048
D = 128

query = torch.randn(B, H, S, D, device="cuda", dtype=torch.bfloat16, requires_grad=True)
key = torch.randn(B, H, S, D, device="cuda", dtype=torch.bfloat16, requires_grad=True)
value = torch.randn(B, H, S, D, device="cuda", dtype=torch.bfloat16, requires_grad=True)
gradOut = torch.randn(B, H, S, D, device="cuda", dtype=torch.bfloat16)

flex_out = flex_attention(query, key, value)
flex_out.backward(gradOut, retain_graph=True)
```
It works with D=64 or without compile.
(I see https://github.com/pytorch/pytorch/issues/132075, while this happens during backward)

### Error logs

```
triton.runtime.errors.OutOfResources: out of resource: shared memory, Required: 131074, Hardware limit: 101376. Reducing block sizes or `num_stages` may help.
```

### Versions

torch==2.5.0.dev20240810+cu121

cc @ezyang @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire @drisspg 
```[tasklist]
### Tasks
```
Repository: godot
Issue: Signal panel gets visible/invisible when i double click filesystem items 
Labels: discussion,topic:editor

### Tested versions



 i only tested on v4.3.rc3.official [03afb92ef]

### System information

windows 11 pro 22h2

### Issue description

Node(signal) menu gets blank in a specific situation.
![Ekran görüntüsü 2024-08-12 194922](https://github.com/user-attachments/assets/200c678d-b0cf-4fd9-b889-43c5c07b966f)
![Ekran görüntüsü 2024-08-12 194959](https://github.com/user-attachments/assets/82d68bf6-ed91-487f-983a-b531f5c90c62)


### Steps to reproduce

Steps.

1.download Godot v4.3.rc3.official [03afb92ef] and run the application
2.download squash the creeps 3d from assetslib (will say it is created on older verison 4.2 ,need conversion. click ok)
3.in inspector click "node" to make signal screen visible to us.
in file system double click on Main.gb ,then double click on main.tscn. main signal menu disappears.(gets lost)

double click Mob.tscn then double click main.tscn. signal menu of main.tscn  gets visible.

i dont know if it is a regression or not.

### Minimal reproduction project (MRP)

(i just downloaded "squash the creeps 3D" on fresh installation and made minimal changes.) 
[squash-the-creeps-(3d)-demo.zip](https://github.com/user-attachments/files/16591003/squash-the-creeps-.3d.-demo.zip)
Repository: pytorch
Issue: torch.export ExportedProgram from GPU cannot be loaded on a CPU only machine
Labels: export-triaged,oncall: export

torch.export ExportedProgram from GPU cannot be loaded on a CPU only machine. The call to `torch.load` needs to use `map_location` to map the weights to cpu.

cc @avikchaudhuri @gmagogsfm @zhxchen17 @tugsbayasgalan @angelayi @suo @ydwu4 @penguinwu
Repository: pytorch
Issue: Having `pynvml` installed and `cuda.hip == True` will crash on use of `amdsmi` which might not exist
Labels: triaged,rocm

### 🐛 Describe the bug

I was training on an AMD GPU in WSL, and accidentally install DeepSpeed by running `pip3 install deepspeed`, and then weird things happened: `NameError: name 'amdsmi' is not defined` raised when calling `torch.cuda.device_count()`, which should work just fine.

It's said to be fixable by `cd /opt/rocm/share/amd_smi && pip3 install --user .`, which will not work in my case because `rocm-smi` is broken in WSL right now.

After some digging, I discover that DeepSpeed has installed `nvidia-ml-py` for me as written in their [requirements.txt](https://github.com/microsoft/DeepSpeed/blob/master/requirements/requirements.txt#L4). Then in this file, `_HAS_PYNVML` will become `True`:

* https://github.com/pytorch/pytorch/blob/main/torch/cuda/__init__.py#L59

Coincidentally, `amdsmi` also use `_HAS_PYNVML` for availability check, and `except amdsmi.AmdSmiException as e:` everywhere doesn't really prevent crashes because `amdsmi` doesn't exist in the first place.

### Versions

torch==2.4.0+rocm6.1
Repository: flutter
Issue: An open string annotation API
Labels: design doc,:hourglass_flowing_sand:,:scroll:

### Document Link

https://flutter.dev/go/string-annotation

### What problem are you solving?

-  The ability to add styles to an already styled string is needed for system / 3rd party text service integrations such as https://github.com/flutter/flutter/issues/150068
- `InlineSpan` only supports capabilities defined by its static interface. Custom annotations defined outside the `painting` library are currently not very well supported.
Repository: pytorch
Issue: export error when tracing tensor subclass tensors: `'FakeTensor' object has no attribute 'get_plain'`
Labels: triaged,oncall: export

### 🐛 Describe the bug

TORCH_LOGS="+export" result: https://gist.github.com/jerryzh168/58f5afc3e8884be7e3f55025a6187fa2

Repro:
1. install torch 2.4
```
pip install torch==2.4.0
```
2. install torchao from source

```
git clone https://github.com/pytorch/ao
```

3. run test
```
TORCH_LOGS="+export" python test/integration/test_integration.py -k test_get_model_size_autoquant_5_cuda
```






### Versions

pytorch 2.4

cc @avikchaudhuri @gmagogsfm @zhxchen17 @tugsbayasgalan @angelayi @suo @ydwu4 @penguinwu