docs: Add documentation for BPF targets #135107

vadorovsky · 2025-01-04T21:08:03Z

No description provided.

rustbot · 2025-01-04T21:08:13Z

rustbot has assigned @GuillaumeGomez.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

src/doc/rustc/src/platform-support/bpf-unknown-none.md

workingjubilee

You need to add the page to the SUMMARY.md

src/doc/rustc/src/platform-support/bpf-unknown-none.md

workingjubilee

Thank you very much for signing up as maintainer contact by the way, this is definitely one of our... odder... targets and it will probably benefit a lot from having someone to talk to about it.

tamird

Thanks for getting this going!

src/doc/rustc/src/platform-support/bpf-unknown-none.md

tamird

Weird I can't resolve comments :(

src/doc/rustc/src/platform-support/bpf-unknown-none.md

workingjubilee · 2025-01-05T20:53:55Z

src/doc/rustc/src/platform-support/bpf-unknown-none.md

+BPF targets require a Rust toolchain with the `rust-src` component and
+[bpf-linker][bpf-linker].


I think it is best to full stop here. The current phrasing seems easy to misinterpret as "bpf-linker is part of the Rust toolchain". Notably, we do ship custom linkers for many targets!

Suggested change

BPF targets require a Rust toolchain with the `rust-src` component and

[bpf-linker][bpf-linker].

BPF targets require a Rust toolchain with the `rust-src` component.

In addition, you must install the [bpf-linker].

On a side note, I would love to see bpf-linker eventually being included in the Rust toolchain. I'm happy to help with that. I suppose it would be one of requirements of updating BPF targets to Tier 2?

Probably!

Also uh, probably would need them to support more than 5 arguments in Rust functions.

Who is "them"?

@tamird The BPF targets.

I see. Do I understand you correctly that such support would be a requirement for promotion to Tier 2?

It would be... difficult for me to imagine that we would accept a tier 2 target that cannot accept a dozen arguments to its Rust functions, yes. Generally, for tier 2 targets, we want them to feel like fairly "normal" targets, even if they don't have first class support (yet?).

Note how I am saying "Rust functions" very specifically: if you want to impose some peculiar constraint on the extern "C" ABI, that's less likely to be a blocker.

But what would be the point of supporting more than 5 args if the eBPF spec mandates max 5 and the vms don't support more?

It would be possible to handle more than 5 arguments by passing the rest on the stack, right? That is what regular targets do too when they run out of argument registers.

The default response to upstreaming changes - even a lot less invasive than changing the calling convention - so far has been "if clang and the kernel don't need it, it doesn't belong to the target". Then there's the issue that the verifier would have to be made aware too, or Fn(u8, u8, u8, u8, u8) and Fn(u8, u8, u8, u8, u8, u8) would look like the same type to it. But nothing in the kernel uses more than 5 args, so the chance of getting that merged seems very slim too.

Technically yes this is a very easy thing to fix (and in fact at work we have a LLVM fork that already does all this and more), but socially it's much harder (and at work we've given up on upstreaming).

workingjubilee · 2025-01-05T20:56:04Z

src/doc/rustc/src/platform-support/bpf-unknown-none.md

+BTF, which can be enabled by adding `-C link-arg=--btf` to `RUSTFLAGS`. With
+that feature enabled, [bpf-linker][bpf-linker] does not only link different
+crates/modules, but also performs a necessary sanitization of debug info, which
+is required to produce valid [BTF][btf] acceptable by the Linux kernel.


Accepted by what, exactly? You mean a specific component of the kernel, right? Does the eBPF verifier also check debuginfo? Or is it that the debugger requires a specific debuginfo format?

AFAIK the BPF dynamic linker uses BTF to do things like checking for compatibility of the BPF module with the type layouts of the kernel itself. And through special relocations it can fill in the offsets of fields for kernel types such that the BPF module can run on multiple kernel versions even if the layout of types used by the BPF module changes across those kernel versions. The latter almost certainly will require explicit rustc support to get wired up.

@workingjubilee the kernel validates the BTF info as part of calling bpf_program_load. Producing valid BTF right now means... generating whatever clang generates for C code. Non-C symbols in type names are not allowed (eg < in Foo<u8>), and there are some other annoying constraints.

@bjorn3 we discussed implementing BTF relocs on zulip a couple of years ago. Long term, you're correct it requires explicit rustc support if only because what debuginfo rustc generates with -C debuginfo is unspecified, so going from DI => relocs is fragile. In the meantime we think we can probably hack it up in bpf-linker tho.

src/doc/rustc/src/platform-support/bpf-unknown-none.md

workingjubilee · 2025-01-05T21:04:16Z

src/doc/rustc/src/platform-support/bpf-unknown-none.md

+
+BPF bytecode needs to be executed on a BPF virtual machine, like the one
+provided by the Linux kernel or one of the user-space implementations like
+[rbpf][rbpf]. None of them support running Rust testsuite. One of the reasons


is this referring to our UI testsuite, or is it referring to #[test] functions, or both?

workingjubilee · 2025-01-05T21:05:06Z

src/doc/rustc/src/platform-support/bpf-unknown-none.md

+Currently the best way of unit testing the code used in BPF programs is
+extracting it to a separate crate, which can be built and ran on a host target,
+and using it as a dependency.


huh...

wouldn't #[cfg_attr(not(target_arch = "bpfel"), test)] work?

#[cfg(all(not(target_arch = "bpf"), test))]

works. I updated the paragraph accordingly.

bjorn3 · 2025-01-06T18:48:42Z

src/doc/rustc/src/platform-support/bpf-unknown-none.md

+[uprobes][uprobe] allow dynamic function tracing and lookup into registers.
+Registers and calling convenctions are different across architectures. Due to
+`char` in C being signed or unsigned on different architectures, the signatures
+of [BPF helpers][bpf-helpers] and [kfuncs][kfunc] also end up different.


Doesn't Linux compile with -funsigned-char nowadays?

From relatively recently right? 6.1 or 6.2 can't remember. But we need to support older kernels.

But I agree that it seems a detail I wouldn't single out char here.

workingjubilee · 2025-01-10T19:19:38Z

src/doc/rustc/src/platform-support/bpf-unknown-none.md

+expected to handle errors in a recoverable manner. Therefore most BPF programs
+written in Rust use the following no-op panic handler implementation:
+
+```rust


I believe this has to be one of these in order for CI to stop complaining:

Suggested change

```rust

```rust,ignore

Suggested change

```rust

```rust

#![no_std]

rustbot · 2025-01-19T21:30:43Z

Some changes occurred in src/doc/rustc/src/platform-support

cc @Noratrieb

rust-log-analyzer · 2025-01-19T21:40:20Z

The job mingw-check-tidy failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

info: removing rustup binaries
info: rustup is uninstalled
##[group]Image checksum input
mingw-check-tidy
# We use the ghcr base image because ghcr doesn't have a rate limit
# and the mingw-check-tidy job doesn't cache docker images in CI.
FROM ghcr.io/rust-lang/ubuntu:22.04
ARG DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y --no-install-recommends \
  g++ \
  make \
---

COPY host-x86_64/mingw-check/validate-toolstate.sh /scripts/
COPY host-x86_64/mingw-check/validate-error-codes.sh /scripts/

# NOTE: intentionally uses python2 for x.py so we can test it still works.
# validate-toolstate only runs in our CI, so it's ok for it to only support python3.
ENV SCRIPT TIDY_PRINT_DIFF=1 python2.7 ../x.py test \
           --stage 0 src/tools/tidy tidyselftest --extra-checks=py,cpp
# This file is autogenerated by pip-compile with Python 3.10
# by the following command:
#
#    pip-compile --allow-unsafe --generate-hashes reuse-requirements.in
---
#12 2.931 Building wheels for collected packages: reuse
#12 2.932   Building wheel for reuse (pyproject.toml): started
#12 3.142   Building wheel for reuse (pyproject.toml): finished with status 'done'
#12 3.142   Created wheel for reuse: filename=reuse-4.0.3-cp310-cp310-manylinux_2_35_x86_64.whl size=132719 sha256=be6760d5849de4a58bbe52b85ca57a55f2b32b518b17029a5ad2e530db0d4303
#12 3.143   Stored in directory: /tmp/pip-ephem-wheel-cache-orb9ydt4/wheels/3d/8d/0a/e0fc6aba4494b28a967ab5eaf951c121d9c677958714e34532
#12 3.145 Installing collected packages: boolean-py, binaryornot, tomlkit, reuse, python-debian, markupsafe, license-expression, jinja2, chardet, attrs
#12 3.549 Successfully installed attrs-23.2.0 binaryornot-0.4.4 boolean-py-4.0 chardet-5.2.0 jinja2-3.1.4 license-expression-30.3.0 markupsafe-2.1.5 python-debian-0.1.49 reuse-4.0.3 tomlkit-0.13.0
#12 3.550 WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
#12 4.091 Collecting virtualenv
#12 4.091 Collecting virtualenv
#12 4.158   Downloading virtualenv-20.29.1-py3-none-any.whl (4.3 MB)
#12 4.316      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4.3/4.3 MB 27.6 MB/s eta 0:00:00
#12 4.378 Collecting filelock<4,>=3.12.2
#12 4.388   Downloading filelock-3.16.1-py3-none-any.whl (16 kB)
#12 4.432 Collecting platformdirs<5,>=3.9.1
#12 4.440   Downloading platformdirs-4.3.6-py3-none-any.whl (18 kB)
#12 4.462 Collecting distlib<1,>=0.3.7
#12 4.484      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 469.0/469.0 KB 35.7 MB/s eta 0:00:00
#12 4.484      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 469.0/469.0 KB 35.7 MB/s eta 0:00:00
#12 4.566 Installing collected packages: distlib, platformdirs, filelock, virtualenv
#12 4.750 Successfully installed distlib-0.3.9 filelock-3.16.1 platformdirs-4.3.6 virtualenv-20.29.1
#12 DONE 4.9s

#13 [7/8] COPY host-x86_64/mingw-check/validate-toolstate.sh /scripts/
#13 DONE 0.0s
---
DirectMap4k:      122816 kB
DirectMap2M:     6168576 kB
DirectMap1G:    12582912 kB
##[endgroup]
Executing TIDY_PRINT_DIFF=1 python2.7 ../x.py test            --stage 0 src/tools/tidy tidyselftest --extra-checks=py,cpp
+ TIDY_PRINT_DIFF=1 python2.7 ../x.py test --stage 0 src/tools/tidy tidyselftest --extra-checks=py,cpp
    Finished `dev` profile [unoptimized] target(s) in 0.05s
##[endgroup]
WARN: currently no CI rustc builds have rustc debug assertions enabled. Please either set `rust.debug-assertions` to `false` if you want to use download CI rustc or set `rust.download-rustc` to `false`.
downloading https://static.rust-lang.org/dist/2025-01-08/rustfmt-nightly-x86_64-unknown-linux-gnu.tar.xz
---
fmt check
fmt: checked 5786 files
tidy check
tidy: Skipping binary file check, read-only filesystem
##[error]tidy error: /checkout/src/doc/rustc/src/platform-support/bpf-unknown-none.md:74: unexplained "```ignore" doctest; try one:
* make the test actually pass, by adding necessary imports and declarations, or
* make the test actually pass, by adding necessary imports and declarations, or
* use "```text", if the code is not Rust code, or
* use "```compile_fail,Ennnn", if the code is expected to fail at compile time, or
* use "```should_panic", if the code is expected to fail at run time, or
* use "```no_run", if the code should type-check but not necessary linkable/runnable, or
* explain it like "```ignore (cannot-test-this-because-xxxx)", if the annotation cannot be avoided.


##[error]tidy error: /checkout/src/doc/rustc/src/platform-support/bpf-unknown-none.md:95: unexplained "```ignore" doctest; try one:
* make the test actually pass, by adding necessary imports and declarations, or
* make the test actually pass, by adding necessary imports and declarations, or
* use "```text", if the code is not Rust code, or
* use "```compile_fail,Ennnn", if the code is expected to fail at compile time, or
* use "```should_panic", if the code is expected to fail at run time, or
* use "```no_run", if the code should type-check but not necessary linkable/runnable, or
* explain it like "```ignore (cannot-test-this-because-xxxx)", if the annotation cannot be avoided.

removing old virtual environment
removing old virtual environment
creating virtual environment at '/checkout/obj/build/venv' using 'python3.10'
Requirement already satisfied: pip in ./build/venv/lib/python3.10/site-packages (24.3.1)
All checks passed!
checking python file formatting
28 files already formatted
checking C++ file formatting
checking C++ file formatting
some tidy checks failed
Command has failed. Rerun with -v to see more details.
  local time: Sun Jan 19 21:40:10 UTC 2025
  network time: Sun, 19 Jan 2025 21:40:10 GMT
##[error]Process completed with exit code 1.
Post job cleanup.

Support clobber_abi in BPF inline assembly This supports [`clobber_abi`](https://doc.rust-lang.org/nightly/reference/inline-assembly.html#abi-clobbers) which is one of the requirements of stabilization mentioned in the tracking Issue for `asm_experimental_arch` (rust-lang#93335). Refs: [Section 1.1 "Registers and calling convention" in BPF ABI Recommended Conventions and Guidelines v1.0](https://github.com/torvalds/linux/blob/v6.13/Documentation/bpf/standardization/abi.rst#11registers-and-calling-convention) > R0 - R5 are scratch registers and BPF programs needs to spill/fill them if necessary across calls. cc `@alessandrod` `@dave-tucker` `@tamird` `@vadorovsky` (target maintainers mentioned in platform support document which will be added by rust-lang#135107) r? `@Amanieu` `@rustbot` label +O-eBPF +A-inline-assembly

Rollup merge of rust-lang#136194 - taiki-e:bpf-clobber-abi, r=amanieu Support clobber_abi in BPF inline assembly This supports [`clobber_abi`](https://doc.rust-lang.org/nightly/reference/inline-assembly.html#abi-clobbers) which is one of the requirements of stabilization mentioned in the tracking Issue for `asm_experimental_arch` (rust-lang#93335). Refs: [Section 1.1 "Registers and calling convention" in BPF ABI Recommended Conventions and Guidelines v1.0](https://github.com/torvalds/linux/blob/v6.13/Documentation/bpf/standardization/abi.rst#11registers-and-calling-convention) > R0 - R5 are scratch registers and BPF programs needs to spill/fill them if necessary across calls. cc `@alessandrod` `@dave-tucker` `@tamird` `@vadorovsky` (target maintainers mentioned in platform support document which will be added by rust-lang#135107) r? `@Amanieu` `@rustbot` label +O-eBPF +A-inline-assembly

Support clobber_abi in BPF inline assembly This supports [`clobber_abi`](https://doc.rust-lang.org/nightly/reference/inline-assembly.html#abi-clobbers) which is one of the requirements of stabilization mentioned in the tracking Issue for `asm_experimental_arch` (#93335). Refs: [Section 1.1 "Registers and calling convention" in BPF ABI Recommended Conventions and Guidelines v1.0](https://github.com/torvalds/linux/blob/v6.13/Documentation/bpf/standardization/abi.rst#11registers-and-calling-convention) > R0 - R5 are scratch registers and BPF programs needs to spill/fill them if necessary across calls. cc `@alessandrod` `@dave-tucker` `@tamird` `@vadorovsky` (target maintainers mentioned in platform support document which will be added by rust-lang/rust#135107) r? `@Amanieu` `@rustbot` label +O-eBPF +A-inline-assembly

tamird

@vadorovsky looks like this needs minor updates to land.

tamird · 2025-02-03T22:42:17Z

src/doc/rustc/src/platform-support/bpf-unknown-none.md

+built from C code with [clang][clang]. It can be done using a `rustc-link-lib`
+instruction in `build.rs`. Example:
+
+```rust


I think this wants a no_run?

---- /checkout/src/doc/rustc/src/platform-support/bpf-unknown-none.md - Tier__3::C_code (line 127) stdout ---- Test executable failed (exit status: 101). stderr: thread 'main' panicked at /checkout/src/doc/rustc/src/platform-support/bpf-unknown-none.md:5:35: called `Result::unwrap()` on an `Err` value: NotPresent note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

tamird · 2025-02-03T22:42:57Z

src/doc/rustc/src/platform-support/bpf-unknown-none.md

+expected to handle errors in a recoverable manner. Therefore most BPF programs
+written in Rust use the following no-op panic handler implementation:
+
+```rust,ignore


Error: tidy error: /checkout/src/doc/rustc/src/platform-support/bpf-unknown-none.md:74: unexplained "```ignore" doctest; try one: * make the test actually pass, by adding necessary imports and declarations, or * use "```text", if the code is not Rust code, or * use "```compile_fail,Ennnn", if the code is expected to fail at compile time, or * use "```should_panic", if the code is expected to fail at run time, or * use "```no_run", if the code should type-check but not necessary linkable/runnable, or * explain it like "```ignore (cannot-test-this-because-xxxx)", if the annotation cannot be avoided.

tamird · 2025-02-03T22:43:11Z

src/doc/rustc/src/platform-support/bpf-unknown-none.md

+Therefore, unit tests need to run on the host system. That requirement can be
+enforced by the following conditional check:
+
+```rust,ignore


Error: tidy error: /checkout/src/doc/rustc/src/platform-support/bpf-unknown-none.md:95: unexplained "```ignore" doctest; try one: * make the test actually pass, by adding necessary imports and declarations, or * use "```text", if the code is not Rust code, or * use "```compile_fail,Ennnn", if the code is expected to fail at compile time, or * use "```should_panic", if the code is expected to fail at run time, or * use "```no_run", if the code should type-check but not necessary linkable/runnable, or * explain it like "```ignore (cannot-test-this-because-xxxx)", if the annotation cannot be avoided.

niklaskorz · 2025-02-09T09:58:16Z

src/doc/rustc/src/platform-support/bpf-unknown-none.md

+
+```toml
+[build]
+target = ["bpfel-unknown-none"]


This fails building the docs at stage2:

Documenting stage2 library {alloc, core, panic_abort, panic_unwind, proc_macro, std, sysroot, test, unwind} in HTML format (aarch64-apple-darwin -> bpfel-unknown-none)

The errors being, among others:

error[E0277]: the trait bound `System: core::alloc::GlobalAlloc` is not satisfied --> std/src/alloc.rs:220:43 | 220 | unsafe { GlobalAlloc::dealloc(self, ptr.as_ptr(), layout) } | -------------------- ^^^^ the trait `core::alloc::GlobalAlloc` is not implemented for `System` | | | required by a bound introduced by this call error[E0277]: the trait bound `System: core::alloc::GlobalAlloc` is not satisfied --> std/src/alloc.rs:270:52 | 270 | let raw_ptr = GlobalAlloc::realloc(self, ptr.as_ptr(), old_layout, new_size); | -------------------- ^^^^ the trait `core::alloc::GlobalAlloc` is not implemented for `System` | | | required by a bound introduced by this call error[E0599]: no method named `fetch_add` found for struct `AtomicUsize` in the current scope --> std/src/panicking.rs:395:47 | 395 | let global_count = GLOBAL_PANIC_COUNT.fetch_add(1, Ordering::Relaxed); | ^^^^^^^^^ method not found in `AtomicUsize` error[E0599]: no method named `fetch_sub` found for struct `AtomicUsize` in the current scope --> std/src/panicking.rs:419:28 | 419 | GLOBAL_PANIC_COUNT.fetch_sub(1, Ordering::Relaxed); | ^^^^^^^^^ method not found in `AtomicUsize` error[E0599]: no method named `fetch_or` found for struct `AtomicUsize` in the current scope --> std/src/panicking.rs:427:28 | 427 | GLOBAL_PANIC_COUNT.fetch_or(ALWAYS_ABORT_FLAG, Ordering::Relaxed); | ^^^^^^^^ method not found in `AtomicUsize

Could you also document how to prevent building docs for std and alloc here, which are not supported by the bpf targets? (without disabling docs entirely through --disable-docs, and without dropping other targets from the same rustc that do successfully build std docs)

rustbot assigned GuillaumeGomez Jan 4, 2025

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 4, 2025

vadorovsky commented Jan 4, 2025

View reviewed changes

src/doc/rustc/src/platform-support/bpf-unknown-none.md Show resolved Hide resolved

This comment has been minimized.

Sign in to view

workingjubilee requested changes Jan 4, 2025

View reviewed changes

src/doc/rustc/src/platform-support/bpf-unknown-none.md Outdated Show resolved Hide resolved

src/doc/rustc/src/platform-support/bpf-unknown-none.md Outdated Show resolved Hide resolved

src/doc/rustc/src/platform-support/bpf-unknown-none.md Outdated Show resolved Hide resolved

workingjubilee reviewed Jan 5, 2025

View reviewed changes

tamird reviewed Jan 5, 2025

View reviewed changes

vadorovsky force-pushed the docs-platform-bpf branch 2 times, most recently from e323a85 to 9397c4d Compare January 5, 2025 14:50

tamird approved these changes Jan 5, 2025

View reviewed changes

This comment has been minimized.

Sign in to view

vadorovsky force-pushed the docs-platform-bpf branch from 9397c4d to 9a6636d Compare January 5, 2025 20:22

workingjubilee assigned workingjubilee and unassigned GuillaumeGomez Jan 5, 2025

This comment has been minimized.

Sign in to view

workingjubilee reviewed Jan 5, 2025

View reviewed changes

bjorn3 reviewed Jan 6, 2025

View reviewed changes

vadorovsky force-pushed the docs-platform-bpf branch from 9a6636d to 28cf691 Compare January 7, 2025 11:34

This comment has been minimized.

Sign in to view

workingjubilee reviewed Jan 10, 2025

View reviewed changes

workingjubilee added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 11, 2025

vadorovsky force-pushed the docs-platform-bpf branch from 28cf691 to 00ddeac Compare January 19, 2025 21:18

This comment has been minimized.

Sign in to view

docs: Add documentation for BPF targets

33873b5

vadorovsky force-pushed the docs-platform-bpf branch from 00ddeac to 33873b5 Compare January 19, 2025 21:30

vadorovsky marked this pull request as ready for review January 19, 2025 21:30

taiki-e mentioned this pull request Jan 28, 2025

Support clobber_abi in BPF inline assembly #136194

Merged

tamird reviewed Feb 3, 2025

View reviewed changes

niklaskorz mentioned this pull request Feb 8, 2025

mitmproxy: 11.0.2 -> 11.1.2; mitmproxy-linux: init at 0.11.4 NixOS/nixpkgs#373425

Draft

13 tasks

niklaskorz reviewed Feb 9, 2025

View reviewed changes

		BPF targets require a Rust toolchain with the `rust-src` component and
		[bpf-linker][bpf-linker].

docs: Add documentation for BPF targets #135107

Are you sure you want to change the base?

docs: Add documentation for BPF targets #135107

Conversation

vadorovsky commented Jan 4, 2025

rustbot commented Jan 4, 2025

This comment has been minimized.

workingjubilee left a comment

Choose a reason for hiding this comment

workingjubilee left a comment

Choose a reason for hiding this comment

tamird left a comment

Choose a reason for hiding this comment

tamird left a comment

Choose a reason for hiding this comment

This comment has been minimized.

This comment has been minimized.

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

This comment has been minimized.

workingjubilee Jan 10, 2025 • edited Loading

Choose a reason for hiding this comment

This comment has been minimized.

rustbot commented Jan 19, 2025

rust-log-analyzer commented Jan 19, 2025

tamird left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

niklaskorz Feb 9, 2025 • edited Loading

Choose a reason for hiding this comment

workingjubilee Jan 10, 2025 •

edited

Loading

niklaskorz Feb 9, 2025 •

edited

Loading