Tools Team: tell us your sorrows

[Xymist]

Lots of people looking at debugging and thinking GDB or LLDB. That’s not really enough, as far as I’m concerned - step-into, step-over, run-till-end-of-function, breakpoint and breakpoint counter are useful, but it also needs a full-featured REPL for exploration. Ruby’s pry-byebug + irb is the bare minimum required feature set here; drop a single keyword in at any point in the code and get a REPL with full information about the current scope where you can execute and inspect essentially anything, change things, set variables, declare entire new variables, data structures and methods if you feel the need, and then let it get back to running. This is doubly vital because of Rust’s compile times; changing a few lines and recompiling takes seconds or minutes, so the ability to try things within a scope and get instant (or at least imperceptibly fast, say < 100ms) feedback would be extremely valuable.

IDE integration not necessary, really; command line alone would be sufficient for most use cases.

[bascule]

In my Rust 2019 blog post I wrote about a particular problem in cargo which particularly impacts no_std developers, where bad interactions in the cargo feature dependency calculation involving build-dependencies and dev-dependencies can inadvertently “flip on” the std cargo feature in dependencies of the target:

Rust in 2019: Security, Maturity, Stability • Tony Arcieri

Some relevant open issues:

Issue: Build Deps getting mixed in with dependencies

Issue: Don't pass `--features` from `dev-dependencies` to `dependencies`

Issue: build-dependencies and dependencies should not have features unified

It seems like all my heavily bolded text got the core team’s attention and @alexcrichton had suggested a potential fix to the way Cargo does the dependency calculation.

[theduke]

A small tipp that could help your workshops:

Have you investigated using https://github.com/mozilla/sccache? It’s a build artifact cache that supports Rust and has distributed storage (S3, Redis, …).

You could have Redis running on a presenter notebook. The participants would have to install the sccache binary (binary releases are available) and configure the remote host, but this could cut down the build times very significantly if you have the cache populated.

---

That said, it would be awesome if cargo had this functionality built in: a) sharing crate builds between projects b) distributing builds for the architecture via crates.io

[passcod]

Area: RLS and running cargo commands

(I’m the author of cargo-watch.)

Increasingly I am finding myself running an RLS via my IDE, and a cargo watch incantation. Both are useful: the RLS provides IDE services like type discovery, linking, in-context errors/lints; the watch incantation can run other things (test suite…) but also presents results differently (all check results in one place, particularly, which is useful in various ways e.g. when an issue is the result of something spread out over many files, or as a way to see the scale of breakage a change introduced, or even because of UI dislike/preference).

My issue is in the duplicated effort when both the RLS and cargo check run. That hurts in two ways: firstly it’s wasteful and uses twice as much CPU (and battery, etc) as really needed. Secondly the RLS has the tendency to run first and take a lock, blocking other cargo processes until it’s done — if the RLS runs several analyses, it and manual cargo contend for time and the entire thing slows down to unusable.

Ideally it should be possible to have a tool that discovers and interrogates a running RLS for the latest results (I’m aware that’s not really how the LS protocol works, though), then displays them in the same or similar format as cargo check. Or some other way to share the results between both approaches.

[rubberduck203]

Have you tried IntelliJ’s CLion? Some co-workers of mine were using it for Rust dev and it seemed very good. Intellisense, debugging, etc.

[crlf0710]

Yes, i’m using it personally. It’s usable, but still less than satisfying.

First it only works with -gnu flavor and doesn’t support msvc flavor on a windows box. And it only integrate with gdb debugging and not msvc-flavor debugging. And there’re quite a few annoyance with debugging experience(many included in the comment i posted above), significantly worse than MSVC C/C++ debugging experience.

The overall feeling is that: at its current status, i can use its debugging facility if i have to, but i’ll avoid it if i can. And no, i’m not advertising it to my C++ programmer colleagues (most are currently visual studio users) this time. It’s good in some ways, but i feel it’s not good enough (yet).

[mgattozzi]

• GDB is unusable on Mac without patching it (SIGSEGV that’s not Rust’s fault), but even if you do nothing pretty prints because the rust-gdb wrapper doesn’t work.
• LLDB “works” but it has no way to distinguish between mod.rs files that it’s not fun to use. Even then I find LLDB to just not be a usable debugger to work with
• RLS/Racer/Any tool that uses rustc to check things is unusable. My work codebase is 200K+ lines before macro expansion. It adds so much latency that my editor grinds to a halt. Rust analyzer so far is alright, but still some false positives and it’s just young

No I do not want to use CLion, my work flow is fairly integrated into my current editor, I’m not going to switch for one lang. What I’ve learned in the past 7 months is we optimized for the hobbyist in tooling. It was good enough, but we have nothing for production use cases basically

I get why this is the current state of things. I’m not angry at people, especially since it’s being worked on in people’s spare time. I’m just frustrated by the lack of usable tools. I spend a lot of time compiling just to print stuff out. If we can reduce that cycle even a bit it would be amazing.

[Dushistov]

RLS/Racer/Any tool that uses rustc to check things is unusable. My work codebase is 200K+ lines before macro expansion. It adds so much latency that my editor grinds to a halt. Rust analyzer so far is alright, but still some false positives and it’s just young

Racer does not use rustc. Order of magnitude of my code base is similar to your, so RLS is also unusable for me, that’s why I use only racer. In future I hope to find some time to look at https://github.com/rust-analyzer/rust-analyzer , it should be more accurate then racer with comparable speed with racer.

[johnthagen]

Installing rust-doc on Windows is very slow. This makes for a less than ideal experience on Windows, especially if you track nightly.

Windows CI is also greatly affected. Checkout the difference in time to build "Hello, World" on Travis for Windows:

[petrochenkov]

Installing rust-doc on Windows is very slow

This one is a pretty critical issue if the tools team has any kind of prioritization.

[azriel91]

Area: Cargo / Cargo.toml – checking for unused dependencies

Sometimes there are dependencies that may be in Cargo.toml that do not have to be there, such as when a crate was previously used, and is no longer used, but only the use statements have been removed from .rs files, and it still remains in Cargo.toml. Haven’t verified, but it may result in unnecessary compilation of those dependencies.

In addition, there are dependencies that may be in the [dependencies] section when they could reside in [dev-dependencies] (e.g. only used by code in #[cfg(test)]). Meaning they are unnecessarily compiled for library consumers. This situation inadvertently happens when a crate initially uses a library, then no longer depends on it, but has tests that check that both the crate and the library work together.

• Is there a tool for this already?

  No

  • If not: did you write one?

    Attempted to use rustc-ap-syntax to try and do this, but haven’t had enough time to dedicate to it. Can see how it’s possible though – have got a hacky program that traverses a rust file’s syntax tree. Would need to build the logic to:

    • traverse the whole crate’s source files
    • group item usages – always, used with #[cfg(test)], used with #[cfg(feature = "something")]
    • intersect these with info from Cargo.toml (dependencies, dependencies (optional = true), dev-dependencies, feature)
    • output in a human understandable format

  • If not: which tool do you think it should be included in?

    Perhaps cargo itself, or clippy.

• Did you manage to work around the lack of tooling?

  No not yet.

[jan_hudec]

No. Editions switch some syntax options in otherwise compatible language, while this is about features added over time. Adding std or core as explicit dependencies seems like a good option here as that is what it basically is, taking the compiler with it as rustc and std versions are always the same. The version of std (or core) should also be written to Cargo.lock. And if current version of cargo chokes on it, it is the right thing in this case.

[Lokathor]

Problem: There’s no way to make examples and tests have different dependencies, so you can’t make a set of cross-compiled example programs if you also want to have any sort of quickcheck / fuzzing / etc because those all use std.

Even their no_std mode does not compile on my target device because they still use atomics and stuff that my target device doesn’t have (GBA). So I’m just stuck not having the fancy test crates at all.