rr
Clippy
rr | Clippy | |
---|---|---|
102 | 120 | |
8,703 | 10,920 | |
1.5% | 2.2% | |
9.6 | 10.0 | |
5 days ago | 4 days ago | |
C++ | Rust | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
rr
- rr: Lightweight Recording and Deterministic Debugging
-
Hermit is a hermetic and reproducible sandbox for running programs
I think this tool must share a lot techniques and use cases with rr. I wonder how it compares in various aspects.
https://rr-project.org/
rr "sells" as a "reversible debugger", but it obviously needs the determinism for its record and replay to work, and AFAIK it employs similar techniques regarding system call interception and serializing on a single CPU. The reversible debugger aspect is built on periodic snapshotting on top of it and replaying from those snapshots, AFAIK. They package it in a gdb compatible interface.
Hermit also lists record/replay as a motivation, although it doesn't list reversible debugging in general.
- Rr: Lightweight Recording and Deterministic Debugging
-
Deep Bug
Interesting. Perhaps you can inspect the disassembly of the function in question when using Graal and HotSpot. It is likely related to that.
Another debugging technique we use for heisenbugs is to see if `rr` [1] can reproduce it. If it can then that's great as it allows you to go back in time to debug what may have caused the bug. But `rr` is often not great for concurrency bugs since it emulates a single-core machine. Though debugging a VM is generally a nightmare. What we desperately need is a debugger that can debug both the VM and the language running on top of it. Usually it's one or the other.
> In general I’d argue you haven’t fixed a bug unless you understand why it happened and why your fix worked, which makes this frustrating, since every indication is that the bug exists within proprietary code that is out of my reach.
Were you using Oracle GraalVM? GraalVM community edition is open source, so maybe it's worth checking if it is reproducible in that.
[1]: https://github.com/rr-debugger/rr
-
So you think you want to write a deterministic hypervisor?
https://rr-project.org/ had the same problem. They use the retired conditional branch counter instead of instruction counter, and then instruction steeping until at the correct address.
-
Is Something Bugging You?
That'll work great for your Distributed QSort Incorporated startup, where the only product is a sorting algorithm.
Formal software verification is very useful. But what can be usefully formalized is rather limited, and what can be formalized correctly in practice is even more limited. That means you need to restrict your scope to something sane and useful. As a result, in the real world running thousands of tests is practically useful. (Well, it depends on what those tests are; it's easy to write 1000s of tests that either test the same thing, or only test the things that will pass and not the things that would fail.) They are especially useful if running in a mode where the unexpected happens often, as it sounds like this system can do. (It's reminiscent of rr's chaos mode -- https://rr-project.org/ linking to https://robert.ocallahan.org/2016/02/introducing-rr-chaos-mo... )
-
When "letting it crash" is not enough
The approach of check-pointing computation such that it is resumable and restartable sounds similar to a time-traveling debugger, like rr or WinDbg:
https://rr-project.org/
https://learn.microsoft.com/windows-hardware/drivers/debugge...
- When I got started I debugged using printf() today I debug with print()
- Rr: Record and Replay Debugger – Reverse Debugger
-
OpenBSD KDE Plasma Desktop
https://github.com/rr-debugger/rr?tab=readme-ov-file#system-...
Clippy
-
More than you've ever wanted to know about errors in Rust
I couldn't find it in the API guidelines either. From what I understand, the idea is that any trait bounds, which includes generic type parameter bounds and lifetime bound on a type (struct or enum) would be repeated back in the impl block
there is a nice discussion on this issue here: https://github.com/rust-lang/rust-clippy/issues/1689
-
New clippy lint: detecting `&mut` which could be `&` in function arguments
You should not blindly follow clippy lints. They are sometimes wrong. Another example https://github.com/rust-lang/rust-clippy/issues/9782 .
- Let else will finally be formatted by rustfmt soon
-
My deduplication solution written in Rust beats everything else: casync, borg...
I often write () = f() to assert that f() is unit. Unfortunately clippy warns on such code ( https://github.com/rust-lang/rust-clippy/issues/9048 ). There are very recent pull requests for this bug, so hopefully this bug will be fixed very soon. But meanwhile I invented this workaround: [()] = [f()] :)
-
Any open source projects willing to take in juniors?
Apart from running clippy on many projects being essential, clippy is also an exceptionally welcoming project, no matter your prior knowledge.
-
Any new Opensource projects in (rust) looking for contributors. I want to start my journey as an OSS contributor.
clippy is a great place to get started :) though it isn't exactly new.
-
I want to contribute in a big project
clippy is also pretty compiler-adjacent and unlike rust-analyzer uses rustc's internal APIs. Don't let the size of the code base scare you off! It's actually feasible for a newcomer to contribute even such a substantial change as a new lint, and we have issues labeled as "good first issue" that come with mentorship, so you don't need to go it alone.
-
rustc-plugin: A framework for writing plugins that integrate with the Rust compiler
Yes, you could use it to write a lint. Although you might find it easier to just fork Clippy and add your own lints to their existing framework.
-
Reading Rust
Check out the readme for more information.
-
Rust Tips and Tricks #PartOne
They are two of my favorite Rust tools. If you haven’t tried them yet, I highly recommend giving them a try. Clippy can detect various lints in your code and guide you towards writing more idiomatic code. To install Clippy, simply run rustup component add clippy, and to run it within your workspace, execute cargo clippy. For more details, visit Clippy’s GitHub repository.
What are some alternatives?
CodeLLDB - A native debugger extension for VSCode based on LLDB
rustfmt - Format Rust code
rrweb - record and replay the web
vscode-rust
gef - GEF (GDB Enhanced Features) - a modern experience for GDB with advanced debugging capabilities for exploit devs & reverse engineers on Linux
rust.vim - Vim configuration for Rust.
Module Linker - browse modules by clicking directly on "import" statements on GitHub
rust-analyzer - A Rust compiler front-end for IDEs [Moved to: https://github.com/rust-lang/rust-analyzer]
nbdev - Create delightful software with Jupyter Notebooks
Rust for Visual Studio Code
clog-cli - Generate beautiful changelogs from your Git commit history
intellij-rust - Rust plugin for the IntelliJ Platform