Cargo team meeting notes 2026-01-20

--- robots: noindex, nofollow tags: meetings --- # 2026-01-20 Attendees: Eric, Ed, Weihang, Arlo, Josh, Dongpo, Jacob, Scott ## FCP Reminders - docs(report): enhance man pages for `cargo report *` -- https://github.com/rust-lang/cargo/pull/16430#issuecomment-3697735409 - build-std: always -- https://github.com/rust-lang/rfcs/pull/3874#issuecomment-3715844925 - build-std: explicit dependencies -- https://github.com/rust-lang/rfcs/pull/3875#issuecomment-3715845871 ## Completions epage: looking for input from a major user of clap's new completion system: Some shells (powershell, fish) and some completers for bash (git) will: - `foo \t`: only completes the next argument - `foo -\t`: only completes short flags - `foo --\t`: only completes long flags clap's new completion engine matches all possibilities, so - `foo \t`: completes arguments and flags - `foo -\t`: completes all flags, preferring shorts - `foo --\t`: only completes long flags See https://github.com/clap-rs/clap/issues/6219 For cargo, most subcommands exclusively use flags, making the powershell/fish/etc behavior less desireable Ideas: - Don't adopt it - Adopt it - Make it configurable (I try to avoid this, if something is better, we should all use it) - Only offer flags if there are no arguments Dongpo: From [6081](https://github.com/clap-rs/clap/pull/6081#issuecomment-3729832252): > 2. In fish and zsh, the clap-generated completion scripts already works that way. In bash, the completion script returns all possible completions (both values and flags), same as in PowerShell. So, the current state is inconsistent. Why is it different on different shells? josh: What others do: Bash completions depends on the command and what type of positional arguments it takes. `rm` `ls` completes a filename unless you put a dash. A command that exists to take options, `git` does subcommands. `git add \t` gives filenames (not options of `git add`). ed: If a flag is required, show it, and if there are no positionals, show the flags. josh: Positionals that are not josh: Tricky: no positionals, go ahead and complete options makes sense. Conversely, positionals and optionals make sense for `cargo \t`. Options for top-level cargo and subcommands makes sense. Then some cases just positionals makes sense. Come up with a heuristic default. ed: Want to establish a basic pattern, and then discuss a need for customization and why. dongpo: regarding comment above. Why different behavior? ed: Some shells built-in logic. Bash/pwsh is manually implemented by the completion author. In our case, we're controlling the behavior on all of the shells, so we get to decide. arlo: It depends on whether it is more likely I am looking for a positional. Listing everything together doesn't allow the ability to control which. Also whether it is an open or closed namespace (filenames/crate names, vs a smaller fixed set). It depends, and would need to see some examples. josh: Lots of completions don't complete short options at all. Doesn't seem useful to show all single dash options and be done. ed: Current show one completion per argument (if there is short/long, shows one, but if there is just a long, shows the long). arlo: May want to consider the opposite, being able to see the long options. ed: Some shells show descriptions, and may want to lean on that when it is supported. josh: Sometimes tab-completing the description in bash works poorly. josh: No matter what you do, you're going to annoy some people. Maybe do a semi-survey of ~100 commands in bash to get a sense of how common different behaviors are. If it is 80-90% consistent, that could let you know. ed: Not familiar with commands with no positionals or required flags. If people have suggestions for those, please let me know. weihang: fish matches clap does. Dash tab shows both short and long with description. ed: If there are positionals or required, then show those and not the flags.\ dongpo: What is meant by positional? ed: Position-sensitive argument. Example, `rm` takes filenames. `cp` is a good example `cp src dst` the order of the arguments matters. josh: Couldn't see a way in bash to show descriptions. The hacks people use tend to complete the descriptions. Ed: Thought there was a way to strip them? josh: Looked, but couldn't find it. arlo: Not enthusiastic about trying to do unusual things, and dealing with the bugs. jacob: Wonders if it should be consistent across shells, or if it should be more native for each shell? arlo: Shouldn't do extremely weird things just to be consistent. ## build script wrapper * https://github.com/weihanglo/cargo/pull/66 weihang: Just check in whether we still want to have this Ran out of time. Choosing a runtime like wasm might not be viable at that moment. Wondering if needing a rustc-wrapper like thing to be able to do something new. Or do other things like changing tmpdir, openssl include dir, etc. Would it be helpful for nightly users to see how to make build scripts better? Just need an execution wrapper. The user is responsible for doing all the work to figure out how to run things. arlo: How does it work for targeting different platforms? ed: Would help with bubble wrap or sid box to control what a subprocess can do. Different isolation mechanisms. This isn't about running the build script as wasm. josh: Is this expected to be stable? Or just experimentation, and then figure out what is actually wanted later? weihang: For feature parity, I think it would be nice to have the wrapper just like we do for rustc. josh: Hesitant to stabilize as the default sandboxing mechanism. ed: Suspect we won't ever stabilize a sandbox thing. How do different packages need different permissions. Is there some way for the wrapper to know what it is running for to look up any configuration? For ex, some package is allowed to do certain things (env lookup, file access, network access, etc.). While we have rustc wrapper, would it make sense to generalize this as a host runner? Then the host runner would have higher precedence than rustc wrapper. weihang: And cargo test/run? ed: Those would be target runners? josh: What else? ed: proc-macros. Could use rustc-wrapper for that, but if you want to sandbox everything, a "host runner" could sandbox everything. arlo: For experimentation purposes, it seems like the runner would be responsible for looking up config and such. Ed: Yes, but..How does the runner know what package is currently being run. arlo: Yes, we'd want that information available to the runner. jacob: A second use case? Build-fleet something? Where my runner copies the executable to a separate machine and brings back the results. josh: WOuld like to be able to hook into cargo, when running something, would like to run those on other systems. Normally wouldn't want to do that with a wrapper, but that would be sufficient. Ideally would like to hand it something to execute, instead of forking off a process which then does the handoff. Depends on what you are doing: distributing builds of crates is a little different from sandboxing the running of build scripts. There's a fairly high overhead forking a large number of helpers (dist-cc has this problem, and sccache). But that is more invasive. Arlo: Also about replacing what a build script is doing. I know there is build-script overrides, but those are not dynamic. Wrappers could handle that. weihang: For that use-case, Nix, bazel, buck, patch build scripts. With this wrapper, they could in theory use it instead of patching (though I don't expect them to). Jacob: Would be good to ask them. Would those tools like to use it to crash if a package has not yet been ported to Nix, as opposed to the subtle breakage that the system didn't yet know existed. weihang: Another experiment is, due the stdin/stdout, the wrapper could print some messages earlier rather than at the end of the build. Or maybe not, not sure. arlo: Seems generally useful enough, but need to be careful, since if we stabilize could never get rid of it. ed: Would like to get away from build scripts and proc macros. weihang: If no strong objection, post a basic implementation of the wrapper. eric: Getting input from people who would actually use it would be helpful. But it can be difficult with nightly. ed: Also concerned about messaging, as people getting excited by an experiment for sandboxing. josh: Would it make sense to have an exp option to when building for a host, actually build for this target? For example, override to build for wasm. ed: Seems to recall the abillity to have a `--host` - https://github.com/rust-lang/cargo/issues/3915 josh: not blocking, this is an idependent feature, but they fit well together. jacob: Is there some synergy with the use case of doing as much locally, but behaving as if running on a remote computer? weihang: Will post a new issue (or see if there is an existing one to update). arlo: Also target-applies-to-host, things that never had a path forward, but may be intertwined with something like this. ## (backlog) Cargo confused about broken `Cargo.toml` in $HOME https://github.com/rust-lang/cargo/issues/6706 Dongpo: Can we add more context to the error message to explain to the user why we are searching this directory? Eric: Thinking adding more to the error message could be nice. And then later other things like 7871 could help the user control the search. ed: Had toyed with `package.workspace=false` is different from just adding empty `[workspace]`, there are slight differences like the fallback resolver. Which of those seem good? scott: Suggesting `[workspace]` for now seems good. weihang: What kind of people run into this situation. They may not understand Cargo workspaces. If adding `package.workspace` not defaulting to false, they wills till run into this situation, look at documentation and then fix it. josh: Re the workspace discovery. If we were designing it today, would it be the same, or would it be opt-in? Scott: One nice thing about not having to do that is that in the workspace you can use globs and not have to list every crate. ed: How much do we emphasize putting things in a package vs multiple packages in a workspace, and having the current behavior is less friction. Would be nice to have implicit boundaries, outside of the home directory stop, some fixed situations that help in some of these cases for common failure modes. (like cargo-rustup discovery rfc). scott: Instead of `package.workspace=false`, would configure where to stop searching. For example, I have separate configurations for home vs work. ed: Only breaks if you `cd` into the submodule. ed: How does the rfc work? eric: It errors if it finds something owned by the wrong user. And then there is a config to override (say "yes, allow reading from other users in these directories"). Explain why..searching for workspace, explain can set `[workspace]` or some such. dongpo: I can help with the error message. ## (backlog) Nightly features in a parent Cargo.toml causes build in unrelated sub-crate to fail when building with beta or stable cargo https://github.com/rust-lang/cargo/issues/6646 (continue from last week) ## (backlog) Cyclic dev-dependencies can cause confusing errors https://github.com/rust-lang/cargo/issues/6765 ## (backlog) `--artifact-dir` (nee `--out-dir`) Tracking Issue https://github.com/rust-lang/cargo/issues/6790 ## (backlog) Local Git dependency using relative file path https://github.com/rust-lang/cargo/issues/6859 ## (backlog) Canonicalize src path for fingerprint https://github.com/rust-lang/cargo/issues/7078 ## (backlog) "cargo install" apparently ignores "Cargo.lock" as opposed to "cargo build" https://github.com/rust-lang/cargo/issues/7169