sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: ant-design
Issue: Select has aria-required on the wrong element
Labels: help wanted,Inactive,⌨️ Accessibility,unconfirmed

### Reproduction link

[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/s/hdm23z)

### Steps to reproduce

1. Put a Select inside a FormItem
2. Make FormItem required

### What is expected?

aria-required should not be added to a div tag at the root of Select. It should be added to the input among its children.

### What is actually happening?

aria-required is being added to a div tag. It is likely that other aria-* attributes passed to Select will also just be added to the root element in the Select, instead of the input element.

| Environment | Info |
| --- | --- |
| antd | 5.11.3 |
| React | 18.2.0 |
| System | Windows 10 |
| Browser | Firefox 119 |

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: PowerToys
Issue: Mapping to square brackets not possible
Labels: Issue-Bug,Product-Keyboard Shortcut Manager,Needs-Triage

### Microsoft PowerToys version

0.75.1

### Installation method

PowerToys auto-update

### Running as admin

No

### Area(s) with issue?

Keyboard Manager

### Steps to reproduce

I tried to remap two key combos (in my case `CTRL`+`#` and `CTRL`+`SHIFT`+`#`) to 

`CTRL`+`]` respectively `CTRL`+`[`

As I use the German keyboard layout (QWERTZ), I don't have `[` `]` keys natively. Instead, those have to be accessed by `ALT`+`8` respectively `ALT`+`9`.

### ✔️ Expected Behavior

Keys can be chosen in the UI and key combos are working like any other.

### ❌ Actual Behavior

Keys cannot be chosen in the UI. 

I also tried to edit the `defaults.json` file under `"%LOCALAPPDATA%\Microsoft\PowerToys\Keyboard Manager"` to manually set the key codes `221` (for `]`) and `219` (for `[`) for the specific combos but it had no effect.

### Other Software

_No response_
Repository: pytorch
Issue: Respect user-specified USE_ROCM/USE_CUDA
Labels: module: build,module: rocm,low priority,triaged,enhancement

### 🚀 The feature, motivation and pitch

The current treatment of `-DUSE_ROCM`/`-DUSE_CUDA` is to _attempt_ locating the dependencies required to support the respective back-ends, and to fall back to `USE_CUDA = OFF`/`USE_ROCM = OFF` in case the user has failed to provide them.

This is a somewhat error-prone default, complicates debugging, and overall makes things more obscure

### Alternatives

The alternative would be to use `find_package(... REQUIRED)` whenever the user is passing `-DUSE_XXXX=ON`, and to `message(FATAL_ERROR "Requested the XXXX back-end support, but the required YYYYs are missing")` as early in the configuration as is possible

Thanks!

### Additional context

Cf. e.g.

- https://github.com/pytorch/pytorch/blob/9d68cfee0dec46be44732667466303a36155f144/aten/CMakeLists.txt#L63
- https://github.com/pytorch/pytorch/blob/9d68cfee0dec46be44732667466303a36155f144/cmake/public/cuda.cmake#L35

cc @malfet @seemethere @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang
Repository: terminal
Issue: settings dropdown menu doesn't respect system wide "make text larger" setting
Labels: Help Wanted,Issue-Bug,Product-Terminal,Priority-3,Area-SettingsUI

### Windows Terminal version

_No response_

### Windows build number

_No response_

### Other Software

Setting this to 200%

![image](https://github.com/microsoft/terminal/assets/148152939/dc369b13-19ea-4ebf-81b2-013c44e62411)

causes this:

![image](https://github.com/microsoft/terminal/assets/148152939/376c77f2-8209-4f78-ae39-ded3375daf2f)


### Steps to reproduce

1. setting system wide "make text size larger" to 200%
2. navigiate to Settings > Startup > Default terminal application dropdown menu

### Expected Behavior

legible rendering

### Actual Behavior

illegible rendering
Repository: go
Issue: cmd/compile,runtime: race support for riscv64
Labels: RaceDetector,NeedsDecision,arch-riscv,compiler/runtime

There was a previous issue requesting support for riscv64 (https://github.com/golang/go/issues/58739), but it was closed because upstream support in LLVM was lacking.

On Oct 6 support for riscv64 was finally [merged into the LLVM tree](https://github.com/llvm/llvm-project/commit/cd0a8245b0fe).

I propose we reconsider adding race detector support to Risc-V. From the top of my head this would require:

- Update the compiler to recognize -race on linux/riscv64
- clone llvm and compile a race_linux_riscv64.syso file, push the necessary changes upstream
- linux-riscv64-race builder?
- Add a new platform to [x/build/cmd/racebuild](https://pkg.go.dev/golang.org/x/build/cmd/racebuild) to build syso files  for riscv64
- Add race instrumentation (race_riscv64.s) to runtime
- Document support on https://go.dev/doc/articles/race_detector
- freebsd/riscv64 support is possible in the future?

Happy to work on this for the early stage of Go 1.23.

cc @golang/runtime @golang/riscv64
Repository: PowerToys
Issue: What's the Name of the Service "Mouse without Border" in US and German?
Labels: Idea-Enhancement,Issue-Docs,Product-Mouse Without Borders

### Provide a description of requested docs changes

Hello,

On the information page is written "Wenn PowerToys als Benutzer installiert ist. muss der Dienst "Maus ohne Rahmen" möglicherweise zu einem späteren Zeitpunkt manuell entfernt werden." But what ist the name of the service in German. I haven't found the service yet. The is no service "Maus ohne Rahmen" or "Mouse without Border".

Thank you very much

BR
Gerd
Repository: pytorch
Issue: [BUG][pytree] equal `dict`s do not imply equal leaves and equal treespecs
Labels: triaged,module: pytree

### 🐛 Describe the bug

Currently, the Python pytree does not guarantee "equal `dict`s imply equal leaves and equal treespecs".

```python
In [1]: import torch.utils._pytree as pytree

In [2]: {'a': 1, 'b': 2} == {'b': 2, 'a': 1}
Out[2]: True

In [3]: pytree.tree_leaves({'a': 1, 'b': 2})
Out[3]: [1, 2]

In [4]: pytree.tree_leaves({'b': 2, 'a': 1})
Out[4]: [2, 1]

In [5]: pytree.tree_structure({'a': 1, 'b': 2})
Out[5]: 
TreeSpec(dict, ['a', 'b'], [*,
  *])

In [6]: pytree.tree_structure({'b': 2, 'a': 1})
Out[6]: 
TreeSpec(dict, ['b', 'a'], [*,
  *])

In [7]: pytree.tree_leaves({'a': 1, 'b': 2}) == pytree.tree_leaves({'b': 2, 'a': 1})
Out[7]: False

In [8]: pytree.tree_structure({'a': 1, 'b': 2}) == pytree.tree_structure({'b': 2, 'a': 1})
Out[8]: False
```

See https://github.com/pytorch/pytorch/pull/114947#issue-2020717108 for more explanation.

### Versions

<details>
<summary>Versions</summary>

```text
Collecting environment information...
PyTorch version: 2.2.0.dev20231121
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.7.1 (x86_64)
GCC version: Could not collect
Clang version: 17.0.5
CMake version: version 3.27.8
Libc version: N/A

Python version: 3.11.5 (main, Sep 11 2023, 08:19:27) [Clang 14.0.6 ] (64-bit runtime)
Python platform: macOS-10.16-x86_64-i386-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz

Versions of relevant libraries:
[pip3] flake8==6.0.0
[pip3] flake8-bugbear==23.3.23
[pip3] flake8-comprehensions==3.12.0
[pip3] flake8-executable==2.1.3
[pip3] flake8-logging-format==0.9.0
[pip3] flake8-pyi==23.3.1
[pip3] flake8-simplify==0.19.3
[pip3] mypy==1.6.0
[pip3] mypy-extensions==1.0.0
[pip3] numpy==1.26.0
[pip3] optree==0.10.0
[conda] blas                      1.0                         mkl  
[conda] mkl                       2023.1.0         h8e150cf_43560  
[conda] numpy                     1.26.0                   pypi_0  
[conda] optree                    0.10.0                   pypi_0  
[conda] torchfix                  0.2.0                    pypi_0
```

</details>

cc @zou3519
Repository: ollama
Issue: Status endpoint needed
Labels: feature request,api

Hello!

I found a non-urgent issues in the API that makes UX much worse when working with models from web or with remote servers because we can't see current state of a ollama: is it downloading model? did it fail downloading model? is it doing inference? how much RAM/VRAM is used? Also lack of such status endpoint it is not clear what to do if connection was aborted during pull - how to check the status of pull operation? 

Lack of this endpoint ends up in a weird UI in most projects i have seen so far.
Repository: pytorch
Issue: is PGNCCL abortCommsFromMap working correctly?
Labels: oncall: distributed,module: nccl

Branching off from a thread that started in https://github.com/NVIDIA/nccl/issues/1013, I wanted to clarify whether pytorch is doing something wrong with use of commAbort APIs leading to a hang.

Specifically, (1) are we required to abort all communicators (even ones we didn't use for a collective), (2) does not aborting one of them somehow lead to a hang?

RE a comment from @kaimingouyang https://github.com/NVIDIA/nccl/issues/1013#issuecomment-1823253942
>What I observed is pytorch does not abort pg obtained from distributed_c10d._get_default_group(). So it might mean pytorch won't free the default pg group until the end of the program. This just clarifies why we see hang in this example.


IIUC pytorch will only add processgroups that are used for a collective into the map of pgs which will then get aborted on exit or error.  This might go hand-in-hand with the fact that pytorch lazily initializes communicators on first use.

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @fegin @XilunWu @fduwjj
Repository: godot
Issue: Scaling the window to have a large width but a small height causes a crash
Labels: bug,platform:macos,topic:porting

### Godot version

v4.1.3.stable.official [f06b6836a]

### System information

MacOS 14.1.1

### Issue description

It crashes when you scale the window like this: 

https://github.com/godotengine/godot/assets/151787624/8a2f2b0c-de33-4007-a7b3-94a410a021bf


### Steps to reproduce

Open the project I have linked. In it you will see a charatcherBody2D that you can move with arrows or WASD. With the Fortnite map in the background. Run the scene and Scale the window

### Minimal reproduction project

Project
[ArcadeGame.zip](https://github.com/godotengine/godot/files/13444241/ArcadeGame.zip)
Repository: pytorch
Issue: __torch_dispatch__ + compile: run functionalization before the subclass
Labels: triaged,module: __torch_dispatch__,module: functionalization,oncall: pt2,module: pt2-dispatcher

Today,
* __torch_dispatch__ subclasses need to properly handle mutable ops like `aten.add_()`, even when used with torch.compile
* __torch_dispatch__ subclasses that use torch.compile are recommended to use this (private) helper method to properly maintain storage aliasing of their subclasses ([link](https://github.com/pytorch/pytorch/blob/main/torch/testing/_internal/two_tensor.py#L72)). This is mostly needed for correctness around some edge cases in torch.compile, so AOTAutograd knows to do the right thing when e.g. it sees an output of the graph that aliases an input

Both of these deficiencies would be fixed, if we had torch.compile run functionalization **before** we desugar the subclass's `__torch_dispatch__` implementation

cc @Chillee @ezyang @zou3519 @albanD @samdow @msaroufim @wconstab @anijain2305
Repository: pytorch
Issue: [BE] better testing for subclasses + compile
Labels: triaged,better-engineering,module: __torch_dispatch__,oncall: pt2,module: pt2-dispatcher

We have plenty of tests for tensor subclasses with compile today [here](https://github.com/pytorch/pytorch/blob/main/test/functorch/test_aotdispatch.py#L3121)

But there are some areas that we could test better. A few that we don't test at all today include:

* torch.compile two different subclasses, e.g. `f(SubclassA(torch.Tensor), SubclassB(torch.Tensor))`

* torch.compile two *nested* subclasses, e.g. `f(SubclassA(SubclassB(torch.Tensor)))`

* torch.compile a function that uses both tensor subclass inputs, and an ambient mode:
```
with DispatchModeA():
    out = f(subclassBinput)
```

cc @Chillee @ezyang @zou3519 @albanD @samdow @msaroufim @wconstab @anijain2305
Repository: flutter
Issue: ExpansionTileController is not updated in didUpdateWidget
Labels: framework,f: material design,a: quality,P2,team-design,triaged-design

The `_tileController` should be checked in `didUpdateWidget` of `ExpansionTile` to see if the provided controller has changed and reassign it. Also, in the case where one had not been provided prior, and the update provides one, the internal one should be garbage disposed to prevent leaking.
Repository: pytorch
Issue: [BE] AOTAutograd, refactor `run_functionalized_fw_and_collect_metadata` to not take in `is_training` flag.
Labels: triaged,better-engineering,oncall: pt2,module: aotdispatch,module: pt2-dispatcher

There are a few places ([example](https://github.com/pytorch/pytorch/blob/main/torch/_functorch/aot_autograd.py#L1459)) where we use this flag, but they should all be unnecessary: the purpose of this function is to infer metadata about the forward, and we should be able to figure out this information without being explicitly told if we are creating a joint vs. inference graph.

This would also allow us to remove the flag from `ViewAndMutationMeta` (also unnecessary): https://github.com/pytorch/pytorch/blob/main/torch/_functorch/aot_autograd.py#L590

See the comment here for details on why/how: https://github.com/pytorch/pytorch/blob/main/torch/_functorch/aot_autograd.py#L1454

cc @ezyang @msaroufim @wconstab @anijain2305 @zou3519
Repository: pytorch
Issue: torch.compile + subclasses: input aliases another input
Labels: triaged,module: __torch_dispatch__,oncall: pt2,module: pt2-dispatcher

This is a tracker issue for https://github.com/pytorch/pytorch/blob/main/torch/_functorch/aot_autograd.py#L3016

cc @Chillee @ezyang @zou3519 @albanD @samdow @msaroufim @wconstab @anijain2305
Repository: pytorch
Issue: refactor TracingContext to take a more limited subset of ViewAndMutationMeta
Labels: good first issue,triaged,oncall: pt2,module: aotdispatch,module: pt2-dispatcher

Today, we add a `ViewAndMutationMeta` object to the TracingContext [here](https://github.com/pytorch/pytorch/blob/main/torch/_functorch/aot_autograd.py#L2122), that backends can use to ask for certain information about the graph, including information about how many / which inputs were mutated.

This technically exposes the `ViewAndMutationMeta` object to out-of-tree backends, which is bad because:
* we want to be able to add/remove fields to this object over time, and exposing this object to backends makes BC harder
* it probably exposes a lot more information than a backend actually needs

We should create a new object to represent the subset of `ViewAndMutationMeta` that inductor actually uses today, and expose that through the TracingContext instead.

cc @ezyang @msaroufim @wconstab @anijain2305 @zou3519
Repository: flutter
Issue: [Impeller] impellerc should make it opt-in to bundle SkSL for platforms that do not have a Skia fallback
Labels: engine,P3,e: impeller,team-engine,triaged-engine

Right now, all platforms have a Skia fallback, and the logic to use it may be decided at runtime.

However, if we get to a point where we're not shipping any Skia rendering code, we should avoid automatically bundling SkSL that will never get used when we compile runtime stage (FragmentProgram) shaders via impellerc.
Repository: flutter
Issue: [web:canvaskit] StrokeJoin.round triggers a slower draw path
Labels: engine,dependency: skia,platform-web,e: web_canvaskit,has reproducible steps,P2,team-web,triaged-web,found in release: 3.16,found in release: 3.17

### Is there an existing issue for this?

- [X] I have searched the [existing issues](https://github.com/flutter/flutter/issues)
- [X] I have read the [guide to filing a bug](https://flutter.dev/docs/resources/bug-reports)

### Steps to reproduce

Using a `round` strokeJoin is causing CanvasKit to abandon a batched `drawArrays` and instead binding a texture for each draw.
When other resources are filling up the CanvasKit resource limit, this causes each line draw to create and upload a texture for each draw on each frame, leading to thrashing. This specific example could be batched directly using `Canvas.drawPoints`. I'm curious to see if there is a way to restore the faster path for all stroke joins, or potentially mentioning the performance difference in documentation when not using the default join.

### Expected results

`drawElements` is used when `Paint.strokeJoin` is `StrokeJoin.round`

### Actual results

`bindTexture` + `drawArrays` is used when `Paint.strokeJoin` is `StrokeJoin.round`

### Code sample

<details><summary>Code sample</summary>

[DartPad](https://dartpad.dev/?id=1afcd9b1827ab42710f441938372a28c)

</details>


### Screenshots or Video

<details>
<summary>Screenshots / Video demonstration</summary>

Sample using the strokeJoin of `miter` captured using spectre.js:
![miter](https://github.com/flutter/flutter/assets/116017986/c9a0b8ae-ba04-41bd-8631-926328cf6535)

Sample using the strokeJoin of `round` captured using spectre.js:
![round](https://github.com/flutter/flutter/assets/116017986/2b2ebdfb-7d20-4a8d-95a6-7c0e6196cd7d)


</details>


### Logs

_No response_

### Flutter Doctor output

<details><summary>Doctor output</summary>

```console
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, 3.13.9, on Microsoft Windows [Version 10.0.19044.3324], locale en-US)
[√] Windows Version (Installed version of Windows is version 10 or higher)
[√] Android toolchain - develop for Android devices (Android SDK version 33.0.0)
[√] Chrome - develop for the web
[√] Visual Studio - develop Windows apps (Visual Studio Community 2022 17.3.5)
[√] Android Studio (version 2021.3)
[√] VS Code (version 1.84.2)
[√] Connected device (3 available)
[√] Network resources

• No issues found!
```

</details>
Repository: pytorch
Issue: higher order ops + torch.compile + __torch_dispatch__ subclasses
Labels: triaged,module: __torch_dispatch__,oncall: pt2,module: higher order operators,module: pt2-dispatcher

This is a placeholder issue for ensuring that the above 3 components all compose in a reasonable way.

In particular: today, every higher-order-op needs a brand new implementation for every `__torch_dispatch__` subclass/mode. Two pieces of work we should explore as part of this issue are:

(1) We have no subclasses working with higher order ops today. We should pick a subclass that needs higher order op support (e.g. DTensor, or the first major use case where this pops up), and attempt to implement rules for every higher order op + make sure this works smoothly.

(2) Ideally, we should have some infra that lowers the amount of boilerplate / footguns that a user might run into when they try to get their subclass working with every higher order op.

cc @Chillee @ezyang @zou3519 @albanD @samdow @msaroufim @wconstab @anijain2305 @ydwu4
Repository: pytorch
Issue: torch.compile <> __torch_dispatch__ support tracker issue
Labels: triaged,module: __torch_dispatch__,oncall: pt2,module: aotdispatch,module: pt2-dispatcher

Tracker issue for open bugs + missing features needed for using `__torch_dispatch__` based subclasses and modes with `torch.compile`.

Missing features:
* https://github.com/pytorch/pytorch/issues/114374 (improved dynamic shapes support)
* https://github.com/pytorch/pytorch/issues/114389 (need to proxy subclass constructor calls/methods)
* https://github.com/pytorch/pytorch/issues/117596 (need to proxy subclass attributes)
* https://github.com/pytorch/pytorch/issues/114397 (run functionalization before the subclass)
* https://github.com/pytorch/pytorch/issues/114411 (higher order op support + infra)
* https://github.com/pytorch/pytorch/issues/114413 (support subclasses that do not desugar, go directly to the compiler)
* https://github.com/pytorch/pytorch/issues/114410 (backward guards)
* https://github.com/pytorch/pytorch/issues/114975 (metadata mutation on subclass inputs)
* better docs

Known bugs:
* https://github.com/pytorch/pytorch/issues/114405 (lack of guards)
https://github.com/pytorch/pytorch/issues/114415 (inputs that alias each other below subclass desugaring)
* https://github.com/pytorch/pytorch/issues/114400 (input aliases input w subclasses)
* https://github.com/pytorch/pytorch/issues/114401 (input dupes another input w subclasses)

BE/testing
* https://github.com/pytorch/pytorch/issues/114398 (testing for compositions of subclasses, modes, etc)
* https://github.com/pytorch/pytorch/issues/114399 (refactor ViewAndMutationMeta to not need an is_training flag)
* https://github.com/pytorch/pytorch/issues/114403 (not exactly specific to subclasses but came up during the initial work)
* https://github.com/pytorch/pytorch/issues/114414 (PyInterpreter.cpp cleanup that came up during subclass support)

cc @Chillee @ezyang @zou3519 @albanD @samdow @msaroufim @wconstab @anijain2305
Repository: pytorch
Issue: Support sending __torch_dispatch__ subclasses in torch.compile that do not desugar
Labels: triaged,module: __torch_dispatch__,oncall: pt2,module: pt2-dispatcher

Today, you can implement a __torch_dispatch__ tensor subclass that works with `torch.compile`, by ensuring that the subclass's `__torch_dispatch__` implementation **desugars** into dispatcher operations on plain tensors.

Another valid use case for subclasses, though, is that you might want to **preserve** your subclass through the PT2 tracing infra, so that the compiler directly sees a graph, with tensor subclass inputs/intermediates/outputs.

This requires extra work on the compiler side, as the compiler now needs to understand the particular subclass and know how to generate code for it.

Most of the pieces for plumbing the subclass to the compiler should exist today, but we should probably have an example of it + test it to show that this can work.

cc @Chillee @ezyang @zou3519 @albanD @samdow @msaroufim @wconstab @anijain2305
Repository: pytorch
Issue: [BE] remove SmallVector optimization in PyInterpreter.cpp when storing custom sizes
Labels: triaged,module: __torch_dispatch__,module: dynamic shapes

See the comment here for more details: https://github.com/pytorch/pytorch/blob/main/torch/csrc/PyInterpreter.cpp#L616 - I originally landed this but Ed pointed out that we should clean this up.

The code there tries to maintain the same lifetime guarantees that `TensorImpl::size_and_strides` has. Technically it is backed by a `SmallVector`, which means that if you have a tensor with 2 dims, and you resize it to be 3 dims, the SmallVector will re-use the same buffer instead of resizing and allocating a new one. This is an implementation detail though - code in core shouldn't be relying on this detail, so if there are any tests that fail when we remove that optimization, we should just fix the tests.

cc @Chillee @ezyang @zou3519 @albanD @samdow