sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Tracking Issue for NEON dot product intrinsics
Labels: O-Arm,T-libs-api,A-SIMD,C-tracking-issue,O-AArch64

<!--
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_neon_dotprod)]`

This is a tracking issue for NEON intrinsics under the `dotprod` feature.

<!--
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::{arm,aarch64}

fn vdot*(..);
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [ ] Implementation: #...
- [ ] 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: ollama
Issue: Locally-hosted library
Labels: question

Organizations that want to use Ollama in their enterprise will want some sort of control over the models that are available for use and where the trained models go when they get pushed.  For instance, most implementers outside AI research won't necessarily want "uncensored" models on half the laptops in the company.  And, if someone trains a model on corporate data, they will want to control where that model goes when someone pushes it, and won't want it made available to the general public.

So...

1. As an enterprise implementer, I want to be able to host a local library.
2. As an enterprise implementer, I want to be able to control the configuration of the Ollama instances on my network.
3. As an enterprise implementer, I want to ensure that locally-developed libraries don't get pushed to a public repository.

I think that about covers it.
Repository: rust
Issue: Tracking Issue for AArch64 SHA3 intrinsics
Labels: T-libs-api,A-SIMD,C-tracking-issue,O-AArch64

<!--
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_neon_sha3)]`

This is a tracking issue for NEON intrinsics under the `sha3` feature.

<!--
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

fn veor3q*(..);
fn vbcaxq*(..);
fn vrax1q*(..);
fn vsha512*(..);
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [ ] Implementation: #...
- [ ] 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: rust
Issue: Tracking Issue for AArch64 SM3 and SM4 intrinsics
Labels: T-libs-api,A-SIMD,C-tracking-issue,O-AArch64

<!--
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_neon_sm4)]`

This is a tracking issue for NEON intrinsics under the `sm4` feature.

<!--
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

fn vsm3*(..);
fn vsm4*(..);
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [ ] Implementation: #...
- [ ] 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: rust
Issue: Tracking Issue for NEON FRINTTS intrinsics
Labels: T-libs-api,A-SIMD,C-tracking-issue,O-AArch64

<!--
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_neon_frintts)]`

This is a tracking issue for NEON intrinsics under the `frintts` feature.

<!--
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

fn vrnd32*(..);
fn vrnd64*(..);
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [ ] Implementation: #...
- [ ] 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: Quick pick: Support alternate representation of French/European characters
Labels: feature-request,quick-pick

This should also match `tache`:

![Image](https://github.com/microsoft/vscode/assets/2193314/4f0df7f1-b411-420d-9cfd-28a8b6c045f7)

See https://github.com/microsoft/vscode/issues/196203 which this would be built upon.

cc @aiday-mar
Repository: rust
Issue: E0308 arising from unary/binary `-` grammar ambiguity
Labels: A-diagnostics,T-compiler

### Code

```Rust
fn f(x: bool)->i32 {
    if x { 5 } else { 10 } - 3
}
```


### Current output

```Shell
Compiling playground v0.0.1 (/playground)
error[E0308]: mismatched types
 --> src/main.rs:2:12
  |
2 |     if x { 5 } else { 10 } - 3
  |     -------^--------------
  |     |      |
  |     |      expected `()`, found integer
  |     expected this to be `()`
  |
help: you might have meant to return this value
  |
2 |     if x { return 5; } else { 10 } - 3
  |            ++++++  +

error[E0308]: mismatched types
 --> src/main.rs:2:23
  |
2 |     if x { 5 } else { 10 } - 3
  |     ------------------^^--
  |     |                 |
  |     |                 expected `()`, found integer
  |     expected this to be `()`
  |
help: you might have meant to return this value
  |
2 |     if x { 5 } else { return 10; } - 3
  |                       ++++++   +

For more information about this error, try `rustc --explain E0308`.
error: could not compile `playground` (bin "playground") due to 2 previous errors
```


### Desired output

```Shell
help: parentheses are required to parse this as an expression
  |
2 |     (if x { 5 } else { 10 }) - 3
  |     +                      +

help: a semicolon is required to discard this value
  |
2 |     if x { 5 } else { 10 }; - 3
  |                           +
```


### Rationale and extra context

This arises from a grammar ambiguity regarding block expressions and unary vs. binary `-`.

A brief search of open issues found #116128 which arises from a similar ambiguity between boolean or and an empty closure parameter list.

This issue was discovered during an [URLO conversation](https://users.rust-lang.org/t/rust-parser-reduce-reduce-conflict/101697/5)

### Other cases

If another operator, like '+', is used, a `help` message about adding parens is already emitted:

```
fn f(x: bool)->i32 {
    if x { 5 } else { 10 } + 3
}
```

***Partial output:***
```
error: leading `+` is not supported
 --> src/main.rs:2:28
  |
2 |     if x { 5 } else { 10 } + 3
  |                            ^ unexpected `+`
  |
help: parentheses are required to parse this as an expression
  |
2 |     (if x { 5 } else { 10 }) + 3
  |     +                      +

error[E0308]: mismatched types
 --> src/main.rs:2:12
  |
2 |     if x { 5 } else { 10 } + 3
  |     -------^--------------
  |     |      |
  |     |      expected `()`, found integer
  |     expected this to be `()`
  |
help: you might have meant to return this value
  |
2 |     if x { return 5; } else { 10 } + 3
  |            ++++++  +

error[E0308]: mismatched types
 --> src/main.rs:2:23
  |
2 |     if x { 5 } else { 10 } + 3
  |     ------------------^^--
  |     |                 |
  |     |                 expected `()`, found integer
  |     expected this to be `()`
  |
help: you might have meant to return this value
  |
2 |     if x { 5 } else { return 10; } + 3
  |                       ++++++   +
```

### Anything else?

_No response_
Repository: pytorch
Issue: [Tracking] torch.compile + torch.distributed + set_grad_enabled/autocast
Labels: oncall: distributed

### 🐛 Describe the bug

FSDP
- [ ] FSDP, autocast (MosaicML Diffusers) https://github.com/pytorch/pytorch/issues/110797
    - **Error raised:** aot_autograd, r.grad = self.meta_tensor
- [ ] FSDP, autocast (LlamaForCausalLM) https://github.com/pytorch/pytorch/issues/111317
    - **Error raised:** fsdp/flat_param.py, flat_param.grad = flat_param_grad
- [ ] FSDP, autocast (Llama2, LlamaRotaryEmbedding) https://github.com/pytorch/pytorch/issues/108211
    - **Error raised:** dynamo/variable_builder, tx.fake_mode.from_tensor( -> r = self.meta_tensor

DDP:
- [ ] DDP, autocast (elastic DDP) https://github.com/pytorch/pytorch/issues/111794

Previous related issues
- https://github.com/pytorch/pytorch/issues/105348
- https://github.com/pytorch/pytorch/issues/105499
- https://github.com/pytorch/pytorch/issues/103862
- https://github.com/pytorch/pytorch/issues/102731
- https://github.com/pytorch/pytorch/issues/96372

Possibly related:
- [ ] FSDP, grad_enabled (not torch.compile) https://github.com/pytorch/pytorch/issues/111958
- [ ] FSDP, grad_enabled (not torch.compile, InternLM) https://github.com/pytorch/pytorch/issues/111552

Likely the same root cause - improper global state / side-effects handling when splitting the graph

### Solution

May not be solvable by tackling the same code path. 
- `DDPOptimizer` utilizes `fx.passes.split_module`. (fixed: https://github.com/pytorch/pytorch/pull/112231)
- Offending code path for FSDP has yet to be diagnosed. 
    - Root cause may or may not be https://github.com/pytorch/pytorch/issues/112072

### Versions

main

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu
Repository: rust
Issue: Borrow checker unhelpful diagnostic
Labels: A-diagnostics,T-compiler

### Code

```Rust
fn confusing_diagnostic() {
    let r0_members = std::collections::BTreeSet::from(["m0", "m1", "m2", "m3"]);
    let mut rooms = std::collections::BTreeMap::from([(0, ("m0", r0_members))]);
    let for_removal = vec!["m1", "m3"];

    let room = rooms.get_mut(&0).unwrap();
    for_removal
        .iter()
        .filter(|&member| *member != (*room).0)
        .for_each(|member| {
            rooms.get_mut(&0).unwrap().1.remove(member);
        });
}
```


### Current output

```Shell
error[E0499]: cannot borrow `rooms` as mutable more than once at a time
  --> src/main.rs:24:19
   |
20 |     let room = rooms.get_mut(&0).unwrap();
   |                ----- first mutable borrow occurs here
...
24 |         .for_each(|member| {
   |          -------- ^^^^^^^^ second mutable borrow occurs here
   |          |
   |          first borrow later used by call
25 |             rooms.get_mut(&0).unwrap().1.remove(member);
   |             ----- second borrow occurs due to use of `rooms` in closure
```


### Desired output

```Shell
error[E0499]: cannot borrow `rooms` as mutable more than once at a time
  --> src/main.rs:24:19
   |
20 |     let room = rooms.get_mut(&0).unwrap();
   |                ----- first mutable borrow occurs here
...
23 |        .filter(|&member| *member != (*room).0)
   |         ------                        ^^^^ first borrow used here
   |         |
   |         first borrow later used by call
...
24 |         .for_each(|member| {
   |                   ^^^^^^^^ second mutable borrow occurs here
25 |             rooms.get_mut(&0).unwrap().1.remove(member);
   |             ----- second borrow occurs due to use of `rooms` in closure
```


### Rationale and extra context

The mention "first borrow later used by call" to `for_each` is misleading. It would be more helpful to point to the `filter` closure, as a fix consists in using a reference to the field of `room` we need in `filter` instead:

```rust
fn fixed() {
    let r0_members = std::collections::BTreeSet::from(["m0", "m1", "m2", "m3"]);
    let mut rooms = std::collections::BTreeMap::from([(0, ("m0", r0_members))]);
    let for_removal = vec!["m1", "m3"];

    let room = rooms.get_mut(&0).unwrap();
    let owner = (*room).0;
    for_removal
        .iter()
        .filter(|&member| *member != owner)
        .for_each(|member| {
            rooms.get_mut(&0).unwrap().1.remove(member);
        });
}
```

@nirbheek
@sdroege 

### Other cases

_No response_

### Anything else?

_No response_
Repository: flutter
Issue: flutter_tool hotkey to dump `dart:ui` calls
Labels: c: proposal,P2,c: tech-debt,team-engine,triaged-engine

Some Dart language tests in the flutter/engine repo run in the `flutter_tester` headless command line embedder. These tests can make calls against `dart:ui`, but don't have access to the full Flutter framework. (Potentially making the framework available in the engine repo for running tests is a separate topic not being considered in this issue.)

However, it may be useful to capture a "trace" of the `dart:ui` calls made by a test written against the full framework in order to import the test into the flutter/engine environment. A user-friendly way to do that would be to add a hotkey to the flutter_tool to dump such a trace, similar to how dumping the widget and layer trees works.
Repository: excalidraw
Issue:  Elements are not adding on cursor position in popup modals
Labels: needs-reproducible-example

I am using excalidraw in a popup. But I am facing issues while adding elements (Line, Rectangle etc), Elements are not adding on the cursor position and also need to move cursor away from actual position in popup to change the position of controls
Repository: excalidraw
Issue: How to  add horizontel scroll bar in excalidraw
Labels: More information needed / cannot reproduce,package:excalidraw

I am using excalidraw . I want to add horizontal scrollbar in excalidraw. How Can I do that
Repository: flutter
Issue: Ensure DevToolsSecurity is enabled
Labels: team-infra,P2,infra: device lab,triaged-infra

### Is there an existing issue for this?

- [X] I have searched the [existing infra issues](https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Aissue+label%3Ateam-infra)

### Type of Request

bug

### Infrastructure Environment

Devicelab

### What is happening?

When downloading Xcode, `DevToolsSecurity` must be enabled otherwise it will error.

```
 Developer mode is currently disabled! Please use `sudo /usr/sbin/DevToolsSecurity -enable` to enable.
 ```
 https://chromium-swarm.appspot.com/task?id=658596f8b4b02810
 
 We should either automate this or make it part of setup steps.

### Steps to reproduce

_No response_

### Expected results

Xcode to download properly
Repository: pytorch
Issue: Implement clip grad value on FSDP
Labels: feature,triaged,module: fsdp

### 🚀 The feature, motivation and pitch

Gradient clipping is a popular technique to scale gradients and avoid exploding gradients issues in RNNs/very deep networks. PyTorch offers a util [torch.nn.utils.clip_grad_value_](https://pytorch.org/docs/stable/generated/torch.nn.utils.clip_grad_value_.html) that enables users to clip gradients such that they collectively have a capped maximum value.

While the torch.nn.utils.clip_grad_value_ should work, it is not ideal to have different apis (torch.nn.utils.clip_grad_value_ vs self.clip_grad_norm_) when handling the same feature. In that sense, adding clip_grad_value_ could contribute to a clearer

Call self._lazy_init to ensure stream synchronization is done appropriately
Apply inplace clamp on all gradients
Ensure that this works with nested FSDP instances as well.

That would also help for clearer design over distributed training tools built over PyTorch.

### Alternatives

Use clip_grad_value_ from torch.nn.utils.clip_grad_value_ and self.clip_grad_norm_ when handling gradient norms on FSDP.

### Additional context

_No response_

cc @zhaojuanmao @mrshenli @rohan-varma @awgu @fegin @penguinwu
Repository: rust
Issue: target_arch and target_os documentation for supported platforms
Labels: A-docs

The [platform support](https://forge.rust-lang.org/platform-support.html) site is _great_. 

However, it is hard to extract from it which `target_arch` and `target_os` macros to use to detect each platform. Is this documented anywhere?

Maybe one could expand this site with the information about how to extract the value of `target_arch` and `target_os` from the triples, or better even, expand the tables with a column for each of these macros, and show which values to use for each platform.
Repository: PowerToys
Issue: Maximized Window not maximal (still resizable )
Labels: Issue-Bug,Product-Settings,External Dependency,Status-Blocked

### Microsoft PowerToys version

0.74.1

### Installation method

PowerToys auto-update

### Running as admin

No

### Area(s) with issue?

General

### Steps to reproduce

start Powertoys (Preview). this will open 'Powertoys Settings'. Maximize this window. 

### ✔️ Expected Behavior

This should maximize the window. If i go to borders of my screen / the window i won't have the little arrows to resize. I can close the window by going to the top right corner and left clicking. 

### ❌ Actual Behavior

the resize arrows appear on the maximized window. Now i cannot conveniently close the window at the top right corner anymore. 

### Other Software

Windows 11 Version 22H2