sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Tracking issue for rename from "object safe" to "dyn compatible"
Labels: T-lang,A-docs,C-tracking-issue,A-dyn-compatibility

This is a tracking issue for the change to call traits that are compatible with `dyn` from "object safe" to "dyn compatible".

### About tracking issues

Tracking issues are used to record the overall progress of implementation.  They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.  A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.  Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

### Steps

- [x] Decide to do this.
  - https://github.com/rust-lang/lang-team/issues/286
- [x] Update rustdoc.
  - #126554
  - #131594
  - #131595
  - #135858
  - #135898
- [ ] Update the compiler.
  - #130826
  - #131475
  - #133372
  - #135860
  - Update `compiler/rustc_codegen_cranelift` (out of tree, not in-tree)
  - Update `compiler/rustc_codegen_gcc` (out of tree, not in-tree)
- [x] Update the standard library.
  - #130827
  - #135856
- [x] Update the Reference.
  - https://github.com/rust-lang/reference/pull/1512
  - https://github.com/rust-lang/reference/pull/1666
- [x] Update the dev guide.
  - https://github.com/rust-lang/rustc-dev-guide/pull/2083 
- [x] Update rust-analyzer.
  - https://github.com/rust-lang/rust-analyzer/pull/18205
- [ ] Update Miri.
- [ ] Update the Book?
- [x] Update all open issues on this issue tracker (title, description).
- [x] Fix all `FIXME(dyn_compat_renaming)` (mostly concerns URLs to the Reference).
- [ ] Add an entry to the **relnotes** (`RELEASES.md`).
  To do so, consider opening a new [relnotes tracking issue](https://github.com/rust-lang/rust/labels/relnotes-tracking-issue) with the relevant details.

cc @rust-lang/lang @fmease
Repository: pytorch
Issue: [triton_op] Automatically `tl.constexpr` user-written kernel params when they are static integers
Labels: triaged,oncall: pt2,module: dynamic shapes,module: inductor,module: user triton

### 🚀 The feature, motivation and pitch

This feature request is inspired by @davidberard98's recent bugfix: https://github.com/pytorch/pytorch/pull/136512

Let's say I write a custom Triton kernel which takes in a tensor shape `M`. I have two options:
* I can make it a normal param, which forces Triton to generate slower PTX code
* I can make it a `tl.constexpr` param, which will force recompilation of the entire model for each value of `M`

This forces me to gamble on whether `M` is static or dynamic in real-life usage. If I lose the wager, I could hurt performance or explode compile time.

But Dynamo already knows whether `M` is dynamic (represented by a SymPy integer) or static (part of the input constraints). Why force the user to make the `tl.constexpr` decision, when Inductor already has sufficient information to make that decision?

Proposal: have `triton_op()` automatically convert static params to `tl.constexpr`. Users can omit `tl.constexpr` and be assured that Inductor will add it whenever possible. If users really want to force full-model recompilation, they still have the option to add `tl.constexpr` manually: Inductor will add it when possible, but never remove it.

cc @ezyang @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire @oulgen @aakhundov @zou3519
Repository: ollama
Issue: Please add OrdalieTech/Solon-embeddings-large-0.1 / OrdalieTech/Solon-embeddings-base-0.1
Labels: model request

Best French embedding models. By far.

https://huggingface.co/OrdalieTech/Solon-embeddings-base-0.1
https://huggingface.co/OrdalieTech/Solon-embeddings-large-0.1
https://ordalie.ai/research/solon
Repository: flutter
Issue: [monorepo] update the process of syncing shared web artifacts to gstatic
Labels: team-infra,P2,triaged-infra,monorepo

At some point in time while we're merging the repos, we have to update the process that syncs static web engine artifacts to gstatic.google.com. Currently, the process takes advantage of asynchrony between changes landing in `flutter/engine` and `flutter/flutter`, as follows:

1. Commit lands in `flutter/engine`.
2. Post-submit bots build web engine artifacts and upload to the cloud buckets.
3. Asynchronously an internal process syncs the artifacts from the cloud buckets to gstatic.
4. Autoroller creates a roll PR in `flutter/flutter`, which can only land if [web_resources_cdn_test.dart](https://github.com/flutter/flutter/blob/master/dev/integration_tests/web/lib/web_resources_cdn_test.dart) passes.

Technically there's a race between steps 3 and 4, but because step 3 is so fast that by the time you get to `web_resources_cdn_test.dart` CDN resources are ready.

I don't know exactly what changes with the monorepo case, but we need to be aware of the following things:

1. Are the cloud buckets changing after the merge? If yes, the internal sync process needs to be updated to pull from new buckets, which may also require updating pub-sub queues that need to listen to different buckets.
2. After the merge, the same CI job will be performing all steps. Since there's no asynchronous gap any more, we need to make sure we sequence all the steps correctly. In particular, the assumption that artifacts will be ready before `web_resources_cdn_test.dart` runs may no longer be true. We may want to have the test wait for artifacts to appear.
3. gstatic resources won't be available at pre-submit, so any tests that rely on gstatic will have to be made post-submit only. Hopefully, we have few of these. Tests should avoid relying on non-local resources because that tends to make things flaky. However, we do want a couple of smoke tests to make sure Flutter Web functions well when using the CDN.
Repository: deno
Issue: WebGPU adapter.info call fails after device creation
Labels: needs investigation,webgpu

Hi! I wasn't too sure if this was a bug, but I got an unexpected error for this WebGPU program: 
```js
async function main() {
  const adapter = await navigator.gpu.requestAdapter();
  const device = adapter.requestDevice();
  console.log(adapter.info);
}
main()
  .then(() => {})
  .catch((error) => {
    console.log(error);
  });
```

When you run the program with:
```console
DENO_WEBGPU_BACKEND=metal deno run --allow-read --unstable-webgpu --allow-write webgpu.js
```

It outputs this on both versions 1.46.3 and 2.0.0-rc.5: 
```console
TypeError: The adapter cannot be reused, as it has been invalidated by a device creation
    at GPUAdapter.get info (ext:deno_webgpu/01_webgpu.js:520:13)
    at main (file:///Users/test_case.js:14:22)
```

But this error doesn't show up if you replace the `adapter.info` call with any of other other `adapter` attributes such as:
```js
adapter.limits
adapter.features
adapter.isFallbackAdapter
```

I was wondering if there was a specific reason only `adapter.info` would be disabled after `requestDevice` is called or if this might be some sort of bug. Thanks!
Repository: rust
Issue: Tracking issue for `proc_macro` in non-`proc-macro` crates
Labels: A-macros,T-compiler,E-medium,C-tracking-issue,T-libs,A-proc-macros,WG-macros

This is a tracking issue for making `proc_macro` usable in all crates, not just those with crate type `proc-macro`. Advantages:

- Simplified testing of procedural macros
- Examples in the [API docs](https://doc.rust-lang.org/proc_macro/index.html) can get checked or run. Development of `proc_macro` would probably get a bit easier in general
- Fewer crates would need a dependency on [`proc_macro2`](https://docs.rs/proc-macro2/latest/proc_macro2/), which exists to solve these problems
- This would be a step toward same-crate proc macros, if we ever decide we want them

`proc_macro2` does this by selecting between the actual bridge implementation and a fallback, https://github.com/dtolnay/proc-macro2/blob/9c1d3eb1b6bddc5b86522bf3af98c2fb3de8e30a/src/lib.rs#L154-L158.

Zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/404510-wg-macros/topic/Using.20proc_macro.20outside.20of.20proc.20macro.20crates (also some around https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Future.20macro.20possibilities.20.28e.2Eg.2E.20inline.20procedural.20macros.2E.2E.2E/near/472781328)

### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

### Steps

- [ ] ACP https://github.com/rust-lang/libs-team/issues/406
- [ ] Implementation
- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide])
- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide])

[stabilization-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs

### Unresolved Questions

ACP is not yet complete, design work needed

### Implementation history
Repository: pytorch
Issue: DISABLED test_pinned_memory_empty_cache (__main__.TestCuda)
Labels: module: rocm,triaged,skipped

Platforms: rocm

This test was disabled because it is failing in CI with a seg fault eg. https://github.com/pytorch/pytorch/actions/runs/11026453746/job/30623960471, but passes when rerun in a single process. It causes the xml reports for the previously-run tests in test_cuda to be lost and thus show up as missing in our analysis.

cc @jeffdaily @sunway513 @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang @naromero77amd
Repository: pytorch
Issue: Segfaulting/aborting unit tests do not show up in "Show Additional Test Info" section
Labels: oncall: releng,triaged

We are observing certain tests seg faulting or aborting the test process, which triggers a rerun (as expected) in the CI.
As discussed in https://github.com/pytorch/pytorch/issues/123882, the xml reports get overwritten and thus miss the tests run before the segfaulting/aborting test, and don't even capture the failure of the segfaulting/aborting test.

In this situation, the HUD page could at least surface these failures in the "Show Additional Test Info" section, but it doesn't. Eg.
https://hud.pytorch.org/pytorch/pytorch/commit/1cb265fafae115cc8acec28205e6244179a6b9c1#rocm

has some tests in shard [3](https://github.com/pytorch/pytorch/actions/runs/11026453746/job/30623959867#step:15:8934) and [6](https://github.com/pytorch/pytorch/actions/runs/11026453746/job/30623960471#step:15:4283) failing with a seg fault or aborting, but it doesn't show them in the  "Show Additional Test Info" section.
Repository: pytorch
Issue: NotImplementedError: The operator 'aten::linalg_matrix_exp' is not currently implemented for the MPS device.
Labels: triaged,enhancement,module: mps

### 🚀 The feature, motivation and pitch

Please implement 'aten::linalg_matrix_exp' for mps, thanks!

Full error:
NotImplementedError: The operator 'aten::linalg_matrix_exp' is not currently implemented for the MPS device. If you want this op to be added in priority during the prototype phase of this feature, please comment on https://github.com/pytorch/pytorch/issues/77764. As a temporary fix, you can set the environment variable `PYTORCH_ENABLE_MPS_FALLBACK=1` to use the CPU as a fallback for this op. WARNING: this will be slower than running natively on MPS.

### Alternatives

_No response_

### Additional context

_No response_

cc @kulinseth @albanD @malfet @DenisVieriu97 @jhavukainen
Repository: ollama
Issue: Adjust templates for FIM models to acknowledge existence of suffix
Labels: bug

### What is the issue?

CodeGemma (for example, it's not the only one) supports both FIM and chat. Ollama uses the FIM template for codegemma:2b and the chat template for codegemma:7b. This feels like the right default decision, but in cases where a suffix is provided, it can be confidently assumed that a FIM format is desired.

The solution to this would be a prompt template that is wrapped in an "if suffix", something like this:

```
{{- if .Suffix }}
{{ .Prompt }}
{{ .Suffix }}

{{- else }}<start_of_turn>user
{{ if .System }}{{ .System }} {{ end }}{{ .Prompt }}<end_of_turn>
<start_of_turn>model
{{ .Response }}<end_of_turn>
{{- end }}
```

One caveat I can see is it would make the prompt template slightly less readable for users browsing the Ollama template library.

### OS

macOS

### GPU

Apple

### CPU

Apple

### Ollama version

0.3.11
Repository: godot
Issue: `RemoteTransform3D` applies incorrect rotation when `Update Scale` is disabled
Labels: bug,topic:editor,topic:3d

### Tested versions

Reproducible in 4.3.stable, 4.4.dev2

### System information

Godot v4.3.stable - Windows 10.0.22631 - GLES3 (Compatibility) - NVIDIA GeForce GTX 1660 SUPER (NVIDIA; 32.0.15.6109) - Intel(R) Core(TM) i7-10700F CPU @ 2.90GHz (16 Threads)

### Issue description

`RemoteTransform3D` applies incorrect rotation to the remote object when `Update Scale` is disabled and the remote object is under a rotated parent. When `Update Scale` is enabled, or when the remote object has a parent with neutral transform or no parent at all, everything works as expected.
![spin_cube](https://github.com/user-attachments/assets/e6d6595d-4a8a-43f8-9530-a6cb7cabc31a)


### Steps to reproduce

- Open `test.tscn` in attached project
- Rotate the `remote_transform_3d` object around the X or Z axis
- Observe that the green cube does not rotate correctly

### Minimal reproduction project (MRP)

[bug-report.zip](https://github.com/user-attachments/files/17139556/bug-report.zip)
Repository: deno
Issue: node:tls: SecureContext.context.addCACert is missing
Labels: bug,node compat

Version: Deno 2.0.0-rc.5+c232ecc

There is a stable but undocumented `node:tls` API `SecureContext.context.addCACert()` (https://github.com/nodejs/node/issues/27079), which is not polyfilled.

Could we polyfill it?
Repository: kubernetes
Issue: Ephemeral storage exhausted by users not mounting the emptyDir
Labels: kind/bug,sig/storage,sig/node,triage/needs-information,needs-triage

### What happened?

A user requested/limited ephemeral storage, but forgot to mount the emptyDir volume. The application was writing data to the snapshot of the image in containerd, which went to mounted /var/lib/containerd folder and not /var/lib/kubelet. Kubelet is watching the size of /var/lib/kubelet and was not evicting the pod, which resulted in /var/lib/containerd overfilled and node not responsive.

### What did you expect to happen?

Not sure, but current ephemeral storage mechanism is not intuitive to users. The data goes in 2 different folders and there's no control over the containerd snapshots size from kubernetes side.

### How can we reproduce it (as minimally and precisely as possible)?

Limit ephemeral storage, not create the emptyDir volume, write some data to /tmp and see /var/lib/containerd getting overfilled.

### Anything else we need to know?

_No response_

### Kubernetes version

<details>

```console
$ kubectl version
Client Version: v1.31.1
Kustomize Version: v5.4.2
Server Version: v1.28.11
```

</details>


### Cloud provider

<details>

</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.6 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.6 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
$ uname -a
Linux k8s-epyc-01.sdsc.optiputer.net 5.4.0-195-generic #215-Ubuntu SMP Fri Aug 2 18:28:05 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>
containerd/now 1.7.2-0ubuntu1~20.04.1 amd64 [installed,upgradable to: 1.7.12-0ubuntu2~20.04.1]
</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>
Repository: transformers
Issue: Add support for Molmo
Labels: New model,Feature request,Vision,Multimodal

### Feature request

Hi,
Would it be possible to add support for [Molmo](https://huggingface.co/allenai/Molmo-7B-D-0924) (currently using custom code)?
Thanks!

### Motivation

Molmo is not supported

### Your contribution

N/A
Repository: ui
Issue: [bug]: Resizable, wrong resize cursor on hover over different resize direction after resize
Labels: bug

### Describe the bug

When resizing using the resizable demo at [Resizable Component](https://ui.shadcn.com/docs/components/resizable)
When resizing and after not clicking on any objects, wrong resize cursor is displayed.

When lets say resizing horizontally or vertically, and then finish resizing. if we don't click on anything using the mouse and hover over a different axis of resizer we get the originally used resize cursor instead.
So if we resized it vertically and after don't click on anything and hover over horizontal resize, we get vertical mouse resize icon.

### Affected component/components

Resizable, ResizableHandle

### How to reproduce

1. Resize horizontally or vertically (don't click or select anything after resize)
2. Hover over a different axis resize bar.
3. Last resized axis mouse cursor is displayed on hover instead of current resize axis. 


### Codesandbox/StackBlitz link

https://ui.shadcn.com/docs/components/resizable

### Logs

_No response_

### System Info

```bash
Google Chrome
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: rust
Issue: s390x vector facilities support
Labels: A-inline-assembly,T-compiler,A-SIMD,O-SystemZ,T-libs,A-ABI

This tracks the status of s390x vector facilities support in rustc and standard libraries.

- ABI support
  - [x] support z13 vector ABI: done in https://github.com/rust-lang/rust/pull/131586
      https://github.com/rust-lang/rust/blob/58420a065b68ecb3eec03b942740c761cdadd5c4/compiler/rustc_target/src/abi/call/s390x.rs#L1-L2
  - [x] remove explicit disabling of the vector feature (blocked on the above FIXME): done in https://github.com/rust-lang/rust/pull/131586
        https://github.com/rust-lang/rust/blob/58420a065b68ecb3eec03b942740c761cdadd5c4/compiler/rustc_target/src/spec/targets/s390x_unknown_linux_gnu.rs#L9-L11
- target_feature support
  - [x] support nightly-only `cfg(target_feature = "vector")` and unstable `target_feature(enable = "vector")` (under `feature(s390x_target_feature)`): done in https://github.com/rust-lang/rust/pull/127506
  - [ ] support other vector facility-related target features: vector-enhancements-1, vector-enhancements-2, etc. (see also https://github.com/rust-lang/rust/issues/88937); pending in https://github.com/rust-lang/rust/pull/135630
  - [ ] stabilize `target_feature = "vector"` (and other vector-related target features if available)
    ~~At least blocked until ABI support done~~ UPDATE: ABI support done
    And may be more things are needed given the [precedent of postponed stabilization of vector features in RISC-V](https://github.com/rust-lang/rust/pull/116485#issuecomment-1755499395).
- asm support
  - [x] support clobber-only vector registers: done in https://github.com/rust-lang/rust/pull/130630
  - [x] stabilize `feature(asm_experimental_arch)` on s390x: done in https://github.com/rust-lang/rust/pull/131258
  - [x] support `#[repr(simd)]` types in input/output of asm (i.e., fully support vector registers) under `feature(asm_experimental_reg)`: pending in https://github.com/rust-lang/rust/pull/131664
    Both [LLVM](https://llvm.org/docs/LangRef.html#supported-constraint-code-list) and [GCC](https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html) do not document `v` constraint, but actually [seem to be supported](https://github.com/llvm/llvm-project/blob/0dbc85a59f556736133019f655e7110fc7ae8847/clang/lib/Basic/Targets/SystemZ.cpp#L76).
    ~~Blocked until ABI support done.~~ UPDATE: ABI support done
  - [ ] stabilize `feature(asm_experimental_reg)` for s390x vector registers (https://github.com/rust-lang/rust/issues/133416)
- core_arch support (tracking issue: https://github.com/rust-lang/rust/issues/135681)
  - [ ] add unstable vector intrinsics to core::arch::s390x
    ~~Blocked until ABI support done.~~ UPDATE: ABI support done
- std_detect support (tracking issue: https://github.com/rust-lang/rust/issues/135413)
  - [x] support unstable `is_s390x_feature_detected!("vector")`: done in https://github.com/rust-lang/stdarch/pull/1699



@rustbot label +O-SystemZ
Repository: pytorch
Issue: Be smart about autograd formulas saving either the input or output, depending on context
Labels: module: performance,triaged,actionable,oncall: pt2,module: inductor

### 🚀 The feature, motivation and pitch

See https://github.com/NVIDIA/apex/pull/1715

The general idea is that for some operators, in principle the autograd formula can be written depending on *either* the input or the output.

For example, for the norm, usually `x_hat` is computed by saving the mean and rstd from the forwards, and then computing `(input - mean)  * rstd`. However, we can also compute it by recomputing it from the *output*, such as by doing `(output - bias) / weight`.

Which one is better is actually somewhat tricky to determine. For example, if the subsequent op requires the output of the norm  (like a matmul), then it would be better to save the output (i.e. `matmul(norm(x))`). On the other hand, if we already need to save the input of the norm, then saving the output would just require us to save more than necessary.

The general problem here is quite tricky, as it relies on "mathematical properties" (which autograd formulas can be rewritten?). But, I think if we choose a set of patterns we'd like to potentially rewrite, we could:

1. Do it as a pattern-matching pass on the joint graph.
2. Upon the pattern hitting, check if the input node or the output node already has other users. If so, we use the autograd formula that allows us to "reuse" the existing saved node.

Example:
```
import torch.nn as nn
import torch.nn.functional as F

torch.set_default_device('cuda')

class CustomLayerNormModule(nn.Module):
    def __init__(self, input_dim, hidden_dim, output_dim):
        super().__init__()
        self.linear1 = nn.Linear(input_dim, input_dim)
        self.layer_norm = nn.LayerNorm(input_dim)
        self.linear2 = nn.Linear(input_dim, input_dim)

    def forward(self, x):
        x = self.linear1(x)
        x = self.layer_norm(x)
        x = self.linear2(x)
        return x

# Example usage
batch_size = 1000
hidden_dim = 10000

# Create an instance of the custom module
model = torch.compile(CustomLayerNormModule(hidden_dim, hidden_dim, hidden_dim))
x = torch.randn(batch_size, hidden_dim)

# Forward pass
output = model(x)
```
<img width="1395" alt="image" src="https://github.com/user-attachments/assets/767f6522-ebdf-4c8e-86d4-2c5c88b90afd">

Of the non-inputs it saves, `addmm` and `add_1` are the nontrivial ones. But if we do the rewrite here, we could avoid saving `addmm` and only save `add_1`.


cc @msaroufim @ezyang @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire