---
robots: noindex, nofollow
tags: meetings
---

# Cargo team meeting notes 2025 Q3

## 2025-08-26

- https://github.com/rust-lang/cargo/issues/15882 -- Turning cargo into a git subtree in rust-lang/rust
- Weihang: we had a discussion a couple months ago, we wanted to get more motivation for this beyond just the failure in our assertion that people need to contribute to cargo rather than just the submodule. I think Kobzol provided other usecases
- being able to experiment with nightly rustc feature, being able to have a corresponding cargo change when e.g. changing `--json=timings` output
- Eric: The benefits are pretty clear. The processes and drawbacks are where the problems were before
- can we list those out?
- collect the actual problems and solutions to those
- Ed: I ran into the existence of subtrees recently -- got confused where to contribute
- Eric: switch this to "needs-design" status and proceed once we know how to solve them
- Ed: We need to know what the problems are and then decide which ones are blocking
- Eric: I'll try to dig up my old notes

- (backlog) https://github.com/rust-lang/cargo/issues/15839 -- -sys crates invoking autoconf configure scripts inherit CONFIG_SITE environment variable
- Eric: First impression: there's this config.site that's used by autoconf. Sounds like auotoconf thing rather than Cargo thing
- Ed: Their proposel is: if Cargo did this, then it would be applied automatically for everything and no one would have to touch this. But we need to see what the impact is, whether this is something that makes sense to enable
- Eric: The user said that `CONFIG_SITE` would never be desired but there are situations where people want to point their sys- crates to point to their own stuff. I wouldn't be as confidend to say that nobody would ever want to use an environment variable like this
- Jacob: I'd say 99 out of 100 cargo experts don't know that cargo build overrides exist
- Eric: In the solution, they'd like to document that there's this potential interraction. But this isn't cargo's issue at all. There's this huge chain of third-party dependencies doing all this stuff.
- Ed: It would be great to have a build script book somewhere. I was just talking to Guillaume that it's great to have doc aliases for C names in sys crates so you can look them up in the docs
- Eric: If we document this, there's low chance that people will actually see this. Being able to make a leap between "I have config.sys and I'm building jmalloc-sys" is not trivial
- Arlo: If we enable this, it will break things and it'll be difficult for us to justify why we did it in the first place
- Josh: the intersection of people in this situation may literally be this one person who reported it. It seems extremely likely that touching this will break more people than help
- Arlo: The best thing to do would have some stabilization between crate processes
- Josh: My first reaction to "not being to see why anyone would use CONFIG_SITE" is that the user's use case doesn't want it but others easily could
- Ed: I'd close this and say this may be worth documenting with a tool closer to these build script interactions
- Josh: Right. A specific script that's related to autoconf might list all the env vars but that's not Cargo's business
- Eric: I don't know what the actual failure is, but if it came out of jemalloc-sys it still likely wouldn't help because this is coming out of autoconf
- Arlo: That's why I suggested they follow-up with the `cc` crate
- Eric: `cc` (the crate) just runs `cc` (the compiler), it doesn't run autoconf

- (backlog) https://github.com/rust-lang/cargo/issues/2775 -- Accept hyphen in crate name in place of underscore
- Eric: I don't remember if we're talking about the `dependencies` table specifically, or is it everywhere?
- Ed: Looks like this is dependencies/patches. Things like that
- I think crates.io treats them in an agnostic fashion but other registries don't have to
- Arlo: This can result in many more HTTP requests
- Josh: This comes up many times and I think at most it's 1-2 extra requests. The common case would be you wrote it with all `-` and it uses all `_`. We sholudn't try every possible combination.
- Jacob: We changed that some time back -- we only do the original case and all the other `_`/`-`
- Arlo: We don't cache nonexistance so this has to happen every time
- Josh: If we wanted to see this go away is to ask the crates.io folks if they want to start more actively steering in one direction and starts refusing the other one
- Ed: There's vocal people on both sides
- Jacob: One of the google API ecosystems carefully and intentionally uses mixed case for... reasons
- Arlo: If you went by the number of downloads it'd mostly be dashes given that's what most of the most-downloaded crates use. But if you go down the list you'd start seeing the underscores more
- Josh: I suspect the appetite of Crates.io chosing a side is not high
- Eric: The top crates it's close to 50/50
- Arlo: I think the only way to solve this is some agreement between us and crates.io to only make one request which would involve changing the protocol.
- Ed: Or we could add tombstones in the index
- Jacob: We'd still have to handle the other registries
- Josh: Any new registry should at minimum say you're not allowed to update a crate that only differs in the separator
- Eric: do we want to change anything here? `cargo add` normalizes this. The only case where this matters is when you're manually editing cargo.toml
- Scott: cargo add, clicking from crates.io etc. all handle this.
- Ed: What happens if you have two dependencies? serde-json and serde_json?
- Eric: Yeah, cargo would have to do more normalization here
- Josh: As much as I'd like to see more, it sounds that the answer may be just "cargo add" solves is
- Ed: Plus now on the error path we check three failure cases
- Eric: How much appetite we have for making a change here?
- Arlo: The only way I'd fix this is with a time machine
- Josh: The actual technical change would be small but the policy and coordination work would be enormous. Decide which way to cannocanize to, coordinate with registries, document the new behavior cargo has.
- Jacob: Alternatively: we just modify the config file we read it from. We could just edit the file to fix the case.
- Ed: I wouldn't want to edit it automatically, I'd like it to be cargo fix with an error message
- Arlo: We could run this command to fix it and that would simplify this for a lot of people
- Ed: I'll write up the message.
- Ed: But it'd be blocked on us having cargo-fix for Cargo code
- Eric: If everyone's okay with closing this, I know there's a lot of interest in the issue, but a lot has changed as well.

- (backlog) https://github.com/rust-lang/cargo/issues/3946 -- Environment variable for Cargo Workspace
- Ed: There's multiple needs. Some are legitimate. They're a developer on a non-published workspace and they'd like to have a shared directory, but then they can't publish it so how do we make that work? We could bring CARGO_RUSTC_CURRENT_DIR back. I wonder if people would pick a name and instastable it or let it be unstable for a while?
- Jacob: I believe the objection is that this increases a chance that you'd have a test that runs with cargo but fails if you run it directly.
- Ed: We had similar discussion about making binpaths available. We may be ok moving that forward. Doing that could also improve our CI caching.
- Arlo: If we document the set of environment variables and what they should be set when you're executing test standalone, that makes sense to me.
- Scott: Is this building a test?
- Ed: Tests and benches.
- Scott: And local binaries?
- Ed: If you do a test or bench you're building a local binary.
- Eric: can you define what's a local binary?
- Scott: cap-lints.
- Eric: In cargo we used to look up the target directory and that was done in a separate crate and that didn't get the environment variable set. We set this for tests and benches but not for dependencies. If we set this in absolute path that would bo something peopele could use.
- Ed: these are thins I ran into https://github.com/rust-lang/cargo/issues/3946#issuecomment-2468442091
- https://github.com/rust-lang/cargo/issues/3946#issuecomment-1820152830
- We have users who are using registries and they want to have everything isolated and there are others who want external access
- How do we separate the two?
- Josh: If there is no workspace, this wouldn't be set?
- Ed: There's always a workspace, it's just sometimes implicit
- Josh: What would this be set to if it a crate was just downloaded from crates.io
- Ed: We could say `publish = false` and `local = true`. Or `publish = false` and its the the workspace of the package being loaded -- that would work for git dependencies.
- Eric: These sound like reasonable suggestions and ideas.
- how about we move this to "needs-design" and summarize what we talked about
- Ed: List accepted problems vs. rejected problems and show the solutions we may have here
- Ed: I'll write that up

- (backlog) https://github.com/rust-lang/cargo/issues/4049 -- Allow skipping of specific dependencies in 'cargo doc'
- epage: close in favor of https://github.com/rust-lang/cargo/issues/2025 ?
- Ed: we have a nodeps flag and they wanted to skip windows-sys?
- Once we have public dependencies, we can change cargo doc to generate documentation for direct dependencies
- That's the issue I've opened and we can close this
- Eric: we could use `rustdoc --map`
- it's unstable
- Ed: Does that have a path to stabilization?
- Eric: There was this bug around the root URL attribute. It was on my todo list to write down a design document for that particular doc but I never got to it.
- Jacob: It's also an unstable feature with one user who's happy to be on nightly
- Ed: I wonder how viable this is.
- Eric: I think it's largely viable, I remember there was a handful of bugs that needs to be fixed
- who has control of the root URL? The author of the crate or person generating the documentation?
- There are people on both sides that have legitimate arguments
- There are mutually exclusive usecases and I wasn't sure how to fix that
- Ed: My suggestion was to close this in favor of the public dependency issue that we have
- Eric: I'm also in favor of closing it but more because of `rustdoc --map`
- Josh: I can imagine `cargo tree` also having an option for to exclude large portion of the tree
- Eric: Josh, there is a `--prune` option for `cargo tree`
- Jacob: If we do this for other commands, it should also be called `--prune` then.
- Ed: Let's close this as we have these better options that don't even requrie the user to think about this.
- Eric: I agree with that.
- Jacob: Sounds good.

- Build scripts slow on macOS due to SIP / developer tool execution policy. https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/build.20scripts.20slow.20on.20macOS.3F/with/536245777
- josh: Should we add detection for this?
- Josh: On MacOS, if you don't have the terminal explicitly marked as developer tool, it will go through all the machinery to verify a signed binary. It's possible to detect this and find out if it's too slow. They're askind if it'd be worth sending a PR that adds logic that says: if this protection is turned on this system give a warning this could make things incredibly slow.
- Scott: Sounds it should be in rustup
- Ed: Rustup is difficult because any invocation there will slow things down for everyone. It's very performance-sensitive.
- Arlo: We could do this when you install rustup.
- Ed: You're blessing your terminal to run your binaries. If you change terminals, you need to bless the new terminal.
- Weihang: If we notarize all the binaries, would it go away?
- Ed: We won't be notarizing build scripts
- Jacob: Could we do this in timings?
- Josh: Would anybody object to the author propose a PR?
- Eric: I think it'd be great to have more discussion. Thisk risks making the users less secure.
- Eric: Windows has the same problem if you have runtime Defender scanning enabled. Because it's scanning any binary that you're creating.
- Josh: For windows the recommendation is to use dev drive, right?

## 2025-08-18

- epage: multi-line build scripts
- https://github.com/rust-lang/cargo/issues/13233#issuecomment-3185855839
- Rendering proposal:
- Output always contains a `error:` / `warning:`
- No guarenteed width of that prefix for alignment to first line, making the assumption that its a header and that compared content would go on a following line
- No extra indentation for subsequent, like with rustc output
- Support ANSI escape codes
- Pass `rustc --diagnostic-width` to build scripts as `COLUMNS` for them to wrap the same way
- Whatever we pass to `rustc` is what we'll pass to the build script.
- Directive proposal:
- Multiple options
- My framing was centered on HTML-style recovery on syntax errors (gracefully degrade rendering to the best you can except when it risks hiding serious bugs), reducing the hard errors
- 1. `cargo::error+=<text>`
- jacob: How would we know there are two print statements between each other?
- ed: Any other directive that is not += will resolve it. Including non-directives (garbage or other text). They can't be intermixed.
- jacob: What about the buffering problem?
- ed: have the user pass in the multi-line thing to build-rs, and it would print an empty line to flush it/end it.
- jacob: documentation would be good to make it clear the behavior.
- 2. `cargo::error_start=<id>` `<text (no prefix)>` `cargo::error_end=<id>`
- 3. `cargo::error_lines=<N>`
- 4. `cargo::error_start=` … `cargo::error=<text>` … `cargo::error_end=`
- ed: I would expect in most cases that these would be wrapped up in a function that takes a multi-line string. The choice doesn't really matter there other than ....
- josh: Likes the idea of having an `end` statement that closes the message out, and can be conveyed as a complete unit. And if you have a `start` as well, you know that if you *don't* have a start then you have a single-line message.
- epage: change of semantics for `error=` to need buffering rather than being complete
- eric: Curious how this would work with multi-threaded build scripts.
- Would likely need to lock the stdout to avoid interleaving.
- `+=` wouldn't fail, but would be mixed.
- arlo: Currently prefer the `+=` (1)
- weihang: Nested build script output?
- This is similar to the multi-threaded scenario. You want to output the error message all at once (with the output locked).
- eric: process of elimination, anyone like option 3?
- ...nobody says yes
- dongpo: What's the downside of option 2?
- ed: Extreme corner case, if there is a `cargo::` directive printed in the middle, it will not be processed.
- josh: goes away from our "cargo ignores non-prefixed"
- arlo: between one and four
- epage: graceful degrade on poor script or clear end of buffering
- arlo: prefer clear end of buffering
- eric: also prefer clear end of buffering. 2 or 4 seems ok.
- josh: surprised by blank line, not just directive, impacting things
- josh: Prefer option 4 at this point; seems like we need a start and end to know when we're buffering up an error, and once we have that, don't see the value of `+=` in between.
- dongpo: can we combine 2 and 4? Have an explicit ID for the start and end
- Essentially, option 4 with an `id` in the start/end.
- scott: Individual lines could also be marked with the id they are associated with. `cargo::error_<ID>=…`.
- ed: A simpler solution might be to just be to lock. They'll need to do that anyways.
- josh: Concerned there could be a failure mode where someone assumes `cargo::error_start=<takes a message here>`. Could we just allow that to avoid that mistake?
- josh: Could have `cargo::error_opts=...` to make changes to how the error is rendered.
- arlo: Does this also apply to warnings?
- yes
- ed: Random potentially bad ideas: could also have `cargo::error_buffer=start`, or `cargo::start=error`
- ed: What would a directive in-between be handled?
- josh: Would prefer that to be a failure.
- scott: Could imagine what happened if something happened in the middle.
- Should be fine if the documentation and errors are clear if it does fail in the middle.
- eric: Would be interesting to see what it would look like to do this with something like `cc` crate.
- ed: kornel had the argument that libraries should not be printing `cargo::error` since you want the caller to decide what to do with it.
- Leaning towards option 4.
- josh: `cargo::error_start=first line` followed immediately by `cargo::error_end=last line` should be accepted.
- josh: `cargo::error_start=` followed by `cargo::error_end=` should give "error: build script emitted empty error".
- ed: For warnings? Should it be a blank warning, or an error that it was missing the warning?
- josh: Would prefer a warning of having a blank warning.
- ed: Would get an error for an unclosed warning.

## 2025-08-11

* Weihang: `target=host` as an alias of host target.
* https://github.com/rust-lang/cargo/issues/13051
* Weihang: whenever peple pass "host" either to --target or target.host dependency, Cargo just overrides it
* epage: where do people specify where they set the target?
* May be weird to do it for the target dependencies table? Sounds more like a new kind of config for this
* This seems like a workaround to `target-applies-to-host`
* do we want this workaround?
* if we give someone a workaround to `target-applies-to-host`, no one will step up to fix it, but we also haven't had anyone step up for a long time
* Weihang: Agreed. I pointed out `target-applies-to-host` but people want this
* maybe we can start this with `--target` but that would not make things consistent
* only allowing it from the CLI but not other places
* epage: workaround: cargo check --target `rustc --print host-tuple`
* if it's convenient for people on the command-line only I'm not opposed to this
* Weihang: or should we ask more about usecases?
* I understand the usefulness of `--target=host` but not sure about other options
* epage: we need to consider all the places and make a decision for each one
* I think this is a user-facing alias and setting this in host's target dependencies doesn't make sense
* Eric: Agreed
* epage: Maybe the target config table too?
* this is a substitution that initiates a cross-compilation
* Josh: The second bullet says "build for the host and some other target" and we'd need to allow building for another target
* epage: Would we want this to be `host` or put curly braces around it (to make clear it's a substitution)
* `--target {host}`
* Josh: I think it's clear that the compiler will never have a target whose name is going to be literally `host`
* we can also reach out to the compiler saying that we are making this assumption
* epage: We could use this to make the substitution explicit
* and also clarify that you're in the "building a host" mode
* Josh: I've just verified that we de-duplicate the target
* Eric: sounds like there's a weak +1, no major concerns
* does that sound reasonable to everyone?
* Weihang: or should we just go with `--target` first and not the config?
* Ed: I think build.target has the same semantic meaning so we can do that too
* although I think we'll have to put this deep enough in the workspace that we'll need to rely on a cache
* Eric: I think rustc knows what the target is
* Josh: for the CLI I'd express a mild preference against curly braces becaues to make it easier to type

* epage: what is the intended behavior for target-dir and `cargo package` verify step? (follow up to 2025-07-29)
* See https://github.com/rust-lang/cargo/issues/14125#issuecomment-3127467689
* https://github.com/rust-lang/cargo/pull/15783#pullrequestreview-3103416589
* epage: You talked about while I was gone, sounds like you didn't come to a consensus
* Eric asked: should we just do it?
* There are going to be some corner cases similar to check vs. build
* I think it's fine to go ahead and make the change
* There will be no incremental build cache use for different packages so we shouldn't have issues here
* Maybe we could even turn off incremental compilation for this?
* Anyone having concerns mowing forward with reusing user's build-dir?
* Eric: We can also revert this if there's issue
* Ross: Looking at the git history I was shocked to see how far we got with no reasons for this given
* Weyhang: Is there any desire to be able to verify multiple packages in parallel?
* Scott: would cango's locking make that impossible?
* epage: I think we could make it package. They all get individual locks so they could be doene in parallel
* but then you're building all the dependencies in parallel
* if we want to build the packages in parallel, we'll have the issue the locking the target directory
* Eric: doesn't sound like there are strong objections and we can revert it if we need to
* sounds like it'd be wortthwhile to do

* epage: do we need to a follow up on `cargo install --git` and branch/tag names due to it making an immutable cache mutable? (follow up to 2025-07-15)
- https://github.com/rust-lang/cargo/issues/15467
- epage: another follow-up. People were in favor while I was out
- one concern is that we'd need to have the cache branch references mutable
- because a branch may have moved since checkout
- Eric: in the checkout, we'd still use the hash of whatever the branch points at currently
- so the directory structure shouldn't move
- each time the branch moves that should be a new checkout
- epage: But we'll have the top-level checkout directory
- if we do a git checkout and then we want to reference the same location but now using a branch, are there any risks associated with that?
- basically, the state could change from run to run around cache
- Eric: currently there's the main repo and the clone of it
- the clone is in a separate directory with the hash
- I think it's feasible to do but it's definitely something worth exploring and being cautious about
- epage: I'm good with moving the conversation forward

* josh: Reviewing proposed change to git2 to disable the default feature flags. Many users of the git2 crate want to operate exclusively on local repositories, but if they don't use `default-features = false` they'll get a large set of additional dependencies they don't need. This bumps git2 to 0.21 to avoid any potential compatibility issues.
* https://github.com/rust-lang/git2-rs/pull/1168
* Josh: This was impactful enough so I wanted to bring it up
* most of what's been happening to git2-rs has been self merges but this is big enough
* the change started out with the premise that it noticed that a lot of tools use git as a library
* diffing tools etc. only care about accessing the local repository
* and a lot of these ended up with a lot of dependencies like curl for things that never even needed to touch the network
* I've tried to trim the default dependencies, I bumped the version
* I've removed the SSH and HTTPS features
* epage: to double check for the "cred" feature -- that's a reference on a type
* Josh: I believe there are specific items that only exist if you turn them on
* but if you pass a URL, it'll work the file URL but not accept an HTTPS URL because you don't have the feature enabled
* epage: The "cred" feature is great because if you try to use it and not have it, compilation will fail and suggest enabling the cred feature
* great discoverability
* I'm concerned about the other features -- will they be compile-time or runtime errors? How clear is the error message?
* Josh: there are two sets of dependencies to get rid of
* a lot of them come from URL handling international characters etc.
* the other thing is it pulls in native libary for things like curl and SSL
* that may not take the longest to compile
* but it's the one that's most likely to hit potential missing system dependencies
* Eric: I wondered whether we could just get rid of the international domain stuff separately
* Josh: Unfortunately, once you have support for HTTPS URLs and don't only accept URLs you control, you will have to have the international support
* epage: If we were using the URL crate, that has a hard dependency on IDNA -- you can't disable it
* Eric: seems good to go, other than the CI errors

* TUF update: https://github.com/rust-lang/rust-project-goals/issues/271#issuecomment-3133590786
* epage: that makes it sound like there are no open questions on performance?
* Eric: Walter gave an update on the TUF progress
* Eric: Jacob you were out too, haven't heard anything in the past month?
* Jacob: I was out
* Eric: I was confused by them saying that they said they'd have a public MVP in the end of July and it's now mid August
* Scott: I've explicitly not read this to keep the goal
* epage: I thought there was still an open question about the performance being resolved on the Merkle tree
* Eric: I wanted to bring that exact point up -- this also surprised me
* in other communication they said there was consensus built on TAP-16
* but my understanding was to go experiment with TAP-16 and see if they can reach the performance needs that they need
* Jacob: my recolection was that TAP-16 was the only thing that even looked viable
* but that doesn't mean it's the thing that it's going to work
* Josh: I have the impression that it was more consensus that this is what we should try first not that this is the definitely the right answer
* the other things had scalability issues that we were going to hit
* I think everyone involved is clear that this will need sneveral iterations
* Eric: The wording they provided was not clear this was the case which is why I wanted to bring this up

* epage: ANSI escape codes from build scripts?
* see https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/Sanitization.20of.20ANSI.20escape.20codes.20from.20build.20scripts.3F/near/532990676
* epage: Someone opened up a security thing for env-logger
* people are doing scare statements around ANSI escape codes
* there's no actual attack, jsut a potential for one
* a build script could do funky things like rename people's title bars
* other tools have done stripping of ansi escape codes or sanitizing them
* wanted to check people's thoughts
* Scott: we sholudn't allow people to arbitrarily rewrite cargo warnings with the escape codes
* someone could arbitrarily rewrite a link that cargo outputs
* it wouldn't be easy to do but in theory you probably could
* until we have a more stable API it's wrong to allow arbitrarry output
* stripping everything allows us to go back in and add things we know are good
* Josh: I think it's perfectly reasonable to start down this road and make best effort to filter out things people shouldn't be doing
* but we're also talking about something that's able to run arbitrary code
* so maybe the worries are a bit overblown here
* I'm generally in favor to make a mild effort to do some filtering but more to handle the annoyance factor showing people this isn't okay
* rather than treating this as something that would protect against malicious build scripts
* epage: agreed
* Josh: We're not protecting against malicious build scripts, we're trying to prevent obnnoxious scripts
* epage: we'll also need to check for `\r` not just ansii escape codes
* Josh: This is something where positioning matters
* if build-print came out as them being playful
* but the fact that they described this as a solution to the problem and not show any caveat to the end users, that's when we should start doing some filtering
* Weihang: should we have an official way for people to reprint what they wanted to print?
* epage: one of the things I worry about is advertisement
* there's also the question of info where I've not seen a lot of advertisement there
* there's also the multiline thing out of Cornell
* Scott: I think stopping this thing from happening is probably good for now
* but there is a lot of open questions of how we should go forward with this
* Josh: FWIW I would like to have multi-line in some fashion
* this would be great for annotate-snippets
* epage: That shouldn't be a problem
* you could use this with carco multiline syntax
* multiline and people being able to diagnostic message are things that people want that I think we should support some subset of ansi escape codes
* Scott: should this be another create people could use?
* I know we talked about generic CLI output tools type of crate
* Eric: I think that's what we used to use -- a library for stripping ansi codes
* epage: yes, for stripping. But what we can do with ?? is stripping ansi codes and then re-output things in a way we want
* Eric: do we have a consensus?
* Weihang: what is an actual usecase where people want to print something in the middle of a build?
* epage: People would want to report diagnostic through build scripts
* Weihang: Why would peole want to build something in the middle of the build rather than at the end? That is something that could be missed by the user
* epage: That sounds like a new topic to open up
* we're talk about "should we strip" and if so what should we strip?
* Eric: I'm in favour of blocking
* I don't like people trying to circumvent whatwe're doing here
* Scott: We can just start with stripping everything and then allow specific things later
* that would help start conversations about what's a reasonable thing people would want to support
* epage: We do have some context
* it's sensible to want to have color and links
* anything else, yes: open an issue and discuss it
* I'm going to reply

* weihang: remove x86_64-apple-darwin from Cargo's CI.
* see https://rust-lang.github.io/rfcs/3841-demote-x86_64-apple-darwin.html
* Eric: that got approved, we have to do it
* Weihang: I'll do it

## 2025-08-04

- Weihang got a question from someone about wanting to work on a Cargo goal but being sponsored by the Rust Foundation
- Eric: Rust Foundation sponsorship is delayed, they're hiring a new person
- once that's open, they can apply
- and the sponsorship will be decided later on
- Weihang: the contributor wanted explicitly use the cargo goal work to be sponsored on
- are we in the loop of who decides to get the sponsorship? Should we put their name on the project goal?
- Eric: We can be roped in for the discussion. With clippy we had multiple people applying so we went to the clippy leads
- it's always case-by-case basis
- Who decides: last time it was Eric, Jack Huey and Paul Lens
- this time it'll likely be a different set of people
- it's a combination of someone from the Foundation, people from Leadership Council or we ask/appoint

- epage: Answer for Jakub about whether enabling timings on rustc on nightly without a feature is ok
- https://github.com/rust-lang/cargo/pull/15780
- epage: I wasn't sure what our bar for this is. Jakub is asking about enabling rustc timings on nightly without enabling a rustc feature
- Josh: in the past we haven't wanted to do this and we invited provided a global `-C` flag
- Eric: that's my general impression as well
- Josh: have `-C json-timings` or `-Z rustc-json-timing`
- Eric: this is a user interactive command so it's a bit of a grey area but yeah
- Weihang: I know some people use memory sanitizer specific options
- Arlo: having unexpected rustc changes just by unsetting bootstrap would be bad
- Josh: Having a flag for bypassing the rustc feature check would be useful
- epage: you're concern is mismatch between nightly cargo and what rustc is being used?
- Josh: Yes. If the rustc changes in a way we haven't updated yet. Or if they have a locally-compiled rustc and they want cargo to use it
- epage: I'll update Jacob on this
- Josh: I seriously considered something like this for the rustc -Z hint-mostly-unused, but ultimately keyed it off the "have you enabled the cargo nightly feature"

- request for help for rustwide change
- https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/rust-lang.2Frustwide.20review.20request/near/531115207
- Eric: someone asked for help reviewing a change for rustwide: https://github.com/rust-lang/rustwide/issues/98
- Does anyone have time for this?
- Just scanning error messages from Cargo
- epage: parsing the text output?
- Josh: If we had a list of a things to do when someone showed up, having json output would be next on that list
- epage: We can do a gradual stepping stone on ??
- Eric: I'll try to look when I can, it'll be a while

- (backlog) Add a common location for custom target spec files
- https://github.com/rust-lang/cargo/issues/1813
- Eric: they're asking for a common location for custom carget spec files (.json files for custom targets)
- When you say `--target foo.json` you have to specify the full path
- They're asking if they can have them in e.g. their home directory etc.
- sounds sort of reasnoble to me
- epage: I wonder if we should be finding way in the config to register custom targets to register verifiers instead of this
- how can we extend the config syntax to allow registering the files in there
- Josh: something like a custom target in configs that has a section ??
- epage: could even be `target.custom-identifier = { file = $PATH }`
- Eric: that sounds good to me to
- Josh: Should we try to repurpose this issue to be that or close this with having someone file a custom config for a target than reusing something that didn't have a comment in 9 years
- Eric: I'm happy reusing this and leaving it as "needs design"
- I'll leave a comment to that direction

- (backlog) SPDX dual-license inconsistency
- https://github.com/rust-lang/cargo/issues/2039
- Cargo's custom `/` syntax is ambiguous
- Eric: people found the `/` confusing because it's not clear whether it's `and` or `or`
- epage: The situation evolved a lot since the original issue
- slash is deprecated now and `and` and `or` are now deprecated
- how much of this is being done on cargo side vs. crates-io
- Josh: more or less none of it is being done on either
- I'd suggest introducing a lint saying "we tried to parse this as an spdx expression and couldn't, noticed it had a slash in it" and show a warning
- We should separate the problem of "syntax was invalid" vs. "not knowing what the license was"
- we can deny the "syntax invalid" case over an edition
- Eric: crates.io does parse the license and verifies it's a valid SPDX expression
- Josh: I was just saying it doesn't stop you if the syntax isn't valid
- Eric: They check syntax and names
- Josh: But when they don't know name, they still let you publish
- Eric: I believe it's an error
- Josh: That's great!
- Weihang: crates.io uses this crate: https://crates.io/crates/spdx
- Eric: would it make sense to drop the slash over an edition?
- epage: Currently we don't have any parsing of this in Cargo, we'd have to add it
- Arlo: our doc says it must be a valid license from the list but we don't validate it
- epage: Given the linting system this shouldn't be a problem
- we were looking for a good lint to get the linting system stabilized
- Arlo: This seems like a good first unstable lint to me
- I'll leave a note to that effect
- epage: I added the `A-new-lint` label to the issue
- Josh: I looked at the spdx crate and it seems it's not supporting the slash at all
- (dongpo showed a parse mode setup that shows this)
- Josh: having that, we can drop allowing slashes and add operators over an edition
- Eric: we want to make sure if we pull in the SPDX crate we need to make sure we stay in sync with crates.io
- Arlo: What do you mean by staying in sync
- Eric: If they and we used incompatible versions
- Arlo: It would be impossible to stay completely in sync
- Eric: New licenses are being added so we can't block Cargo publish on that. But if we show a warning that would be good.

- (backlog) Consider breaking some of the utils out into separate modules
- https://github.com/rust-lang/cargo/issues/2259
- Eric: They were writing custom cargo commands and they wanted to link against smaller libraries rather than the large monolithic cargo library
- epage: We should have minimal crates we publish and mostly plumbing commands. Interested to see how we can use the plumbing commands to solve that problem
- my experience using cargo as a library before switching cargo metadata was getting all these unused fields messages
- it was really annoying
- switching the cargo metadata was much better
- there are different policy questions around managing all these utility crates
- we have a 'locate-manifest' plumbing command implemented, `read-manifest` too, `read-lockfile` is resolving dependencies
- https://github.com/crate-ci/cargo-plumbing
- Weihang: I'm in favor of cargo-plumbing to let us evolve the cargo API
- Eric: I'd like to propose we close this for now, post we're working on plumbing initiatives, and we may have smaller crates we pull out
- Weihang: do you want to have a for people to make a wish on which commands they'd like to expose?
- epage: cargo-plumbing issues could point us to repos that could use specific features
- one thought on how to direct people to this:
- what if we had a small placeholder section in our unstable documentation that goes to cargo plumbing?
- Eric: sounds good
- epage: I'l add it

- (backlog) Consider being able to disable `--emit=link` option?
- https://github.com/rust-lang/cargo/issues/2304
- Eric: there was a very recent issue about something similar
- they were trying to do `--emit=obj` and they were linking at the same time and causing issues
- https://github.com/rust-lang/cargo/issues/15771
- not sure they're related or not
- we've added `cargo rustc --emit`, didn't we?
- or is it just crate-type?
- Weihang: only crate-type
- Josh: looking at the history of this issue
- there was some back and forth in 2016
- then intentionally left open
- then over the course of the time was people listing similar (but differnt) problems
- unclear what this is even asking for
- the most recent one is: when you run `cargo rustc --emit` it doesn't do anything that's not listed
- that's a different ask from asking to emit static lib to get a `.o` out
- we could repurpose this to dedicate it to one of the other things
- Eric: one minor issue with that is that we don't parse the arguments we're passing to rustc
- epage: knowing how complex argument parsing is I'm always cautios parsing another program's CLI
- Josh+Arlo: that's super valid
- Eric: any thoughts?
- we could just close it and say this isn't a use case we'll support at this time?
- and in the future if there's some workflow where someone needs to do something with custom emits that interacts with linking that we provide an actual workflow for that specific thing
- Josh: another option: rather tahn supporting --emit as a rustc option, we could support a cargo option that's emit/dont-emit
- and then we decide whether to pass it or not
- then we don't get into the business of parsing rustc options
- Eric: I'm warm to your idea of adding an emit flag
- but I don't want to promise that we'll take it right awy
- Josh: I just meant we'd post a vague description of this and then if someone's interested, they can propose a design later
- Eric: that sounds good to me
- I can post that

- epage: cargo-fixit update
- bench results: https://github.com/crate-ci/cargo-fixit/blob/main/benchsuite/runs/2025-07-31-af6627c.md
- epage: I have a GSoC person working on cargo-fixit and they created a bench suite for it and the numbers are great
- they're working on a build unit at a time and fixing it until it's all done or hit a max iteration limit
- there a re potential optimizations for us to look into
- in most cases the performance is order of magnitude or faster than `cargo fix`, in the rest is about the same performance
- this is a wrapper over `cargo check`
- wanted to share the update

- (backlog) cargo install <library_name> --library
- https://github.com/rust-lang/cargo/issues/2552
- epage: I assume this is if they have a `cdylib`
- oh, they're trying to make it so they can install all of their dependencies for caching purposes
- Weihang: they're a nixos user but they want to use Cargo to install something?
- Eric: They want cargo to copy the rlibs to that directory? Is that right?
- Arlo: this looks like a request to having a global cache rather than anything
- eric: people like fasterthanlime and bevy have been experimenting to switching to dylibs to speed up build time
- this might be best developped as a third-party tool to experiment with
- Josh: seems like the proposal for having a per-user cashe would fully address their issue
- https://github.com/rust-lang/cargo/issues/5931
- Eric: sounds like this is something we want to close, point to some of our caching work
- epage, can you write the comment please?
- epage: sure

- (backlog) `cargo rustdoc` should build docs for dependencies
- https://github.com/rust-lang/cargo/issues/2594
- Eric: if you say "cargo rustdoc" it builds just one crate. This is about building all the dependencies too
- I'm concerned about the stability
- if someone's using cargo rustdoc they're probably not building the dependencies
- epage: there's cargo rustdoc and cargo doc
- it feels cargo rustdoc is more lower-level
- I think we should instead let users specify the crate `cargo rustdoc` should build
- https://github.com/rust-lang/cargo/issues/15733
- Weihang: I think the differenc between `cargo rustdoc` and `cargo doc` is much less than between `cargo build` and `cargo rustc`
- most people wouldn't know
- maybe we want to document it better and guide people towards one or the other
- or maybe just deprecate cargo rustdoc entirely
- Eric: seems someone from 2016 asked for a `RUSTDOCFLAGS` option which now has been added
- epage: We can close it as `RUSTDOCFLAGS` and there's this other issue we can use

## 2025-07-29

* epage (maybe not present): what is the intended behavior for target-dir and `cargo package` verify step?
* See https://github.com/rust-lang/cargo/issues/14125#issuecomment-3127467689
* @ranger-ross opened a PR that seems to cover what epage was asking for: https://github.com/rust-lang/cargo/pull/15783
* tests and making the behaviour change explicit (and therefore open for duscission)
* Scott: Not certain at this point. Ed's point to verify that everything's correct is good. But also the current behaviour is weird.
* Tomas: This was added in: https://github.com/rust-lang/cargo/pull/2912
* Scott: Looking at this, it feels like it's a regression.
* Weihang: It's either that or a new feature. It doesn't match the old behaviour.
* Scott: Without looking at it in depth, the intent of the original PR was to move target-dir to the workspace.
* if that's the case, having it be split up per package feels odd
* Jacob: Also it's from 2016.
* Scott: What I'm saying is that it seems we've regressed since that PR.
* Weihang: I think the comment from Ed about the final artifact worry -- is that an actually issue for verification?
* We don't use the final artifacts from the verification. We just verify they compile.
* Oh, probably artifats in dependencies could impact the final target
* Scott: Is there any reason why everything wouldn't share a target directory?
* Just trying to think if there's anything wrong about everything using one of them
* I don't think it is
* Weihang: Cargo is usually very bad for cache reuse so typically we want to make sure nothing is shared accidentally. Maybe you're right Scott?
* Scott: Wait, this has nothing to do with workspaces, does it?
* This is only happening with host packages. The only reason this has anything to do with workspaces is that it's going to be treated as a workspace because it's not in one
* In that case this is a very odd change to make
* I think this is something that needs more investigation.
* Weihang: Given some folks are not available today, should we just do a FCP?
* Scott: Ed responded, I think it's fine to give them 7 days for him and us to look at it at more depth.
* Josh: Based on seeing people trying to apply hings, it seems a lot of people are going to potentially misuse it
* When you're writing a profile hint, it's tempting to write `profile.release.hint_mostly_unused = true` -- without specifying the package.
* I wonder if we could lint on not providing the lints on specific packages
* Either of these is almost certainly a mistake (you really want to apply this selectively):

    [profile.release]
    hint-mostly-unused = true
    [profile.release.package."*"]
    hint-mostly-unused = true

* Scott: We probably can show them a warning. But if this is set in config, we're not sure how we're going to lint anything in the config.
* Josh: Right now this only works in the manifests.
* Scott: Then yeah, you should be abl et odo this. What stage do we know teh concrete profile for something?
* Josh: Could we detect this when we apply a profile and say that this stanza is almost certainly a mistake?
* Scott:
* Scott: When you're doing a lint pass, I think you should be able to handle it at that point. Would an individual package have the profile for it? Would we have it at that time?
* Josh: I'd expect you'd only want this warning when the profiles are used. So you'd only want this for the top-level crate.
* Josh: This is setting a profile for the packages. For the hints subsystem that only applies for the packages you set up, I don't think we need to warn.
* Scott: We can look at it at the manifest level.
* Josh: That's true if we suppress the warning when you're not on the top-level crate.
* Scott: If we know the workspace is a virtual workspace,
* Josh: I don't know how we handle profiles in workspaces vs. package
* Scott: I thought the cargo book has it documented. "Cargo only looks for the profile settings in the Cargo.toml manifests"
* If you're a solo package it'd be just that package. We can determine that easily.
* So you can do this by just looking at the manifest.
* Josh: Makes sense. Where would be looking at that?
* Scott: The curent plan is to put it in the `emit_lints` function: https://github.com/rust-lang/cargo/blob/9b296973b425ffb159e12cf3cd56580fd5c85382/src/cargo/core/workspace.rs#L1242-L1242
* Scott: That's an extension of the `emit_warnings`. It tries to detect things that shouldn't be there (any unknown lints etc.)
* Josh: I just realised one funciton above this is package_manifest_warnings which is probably the right mechanism for that.
* Scott: That's for the old way of doing this. Eventually everything we'll want to transition to where we have the linting stuff. This speeds up our parsing time so it helps to have everything a little bit later. Look around the `check_im_a_teapot`
* Josh: So we add analyses directly to the emit_lints?
* Scott: If you give me a rough idea I can probably put something together.
* Josh: I'd appreciate the help.
* Weihang: Do we want to handle profile in config?
* Josh: I don't remember if you can set profile defaults in config. [reads docs] So yeah, theoretically you could.
* Scott: It get's into the whole idea of how we know what to lint because we don't have the config.lint configuration right now. But because it's nightly I don't think it's a problem adding something like this.
* Weihang: Setting it in config is certainly wrong because it overrides everything.
* Scott: Yeah, so I think at this point warning on config is something we certainly want to do. Until it's stabilized at which point you can disable it.
* Jacob: Also in the process of stabilization we'll have a mainline blog post and release notes so we'll have lots of opportunities to tell people how to use it correctly.
* Scott: We'll at least be able to keep it for the manifests. Doing it for the config is kind of an open question right now.
* Scott: If you can give me a name of the lint, I can probably do it really quickly. Adding things is easy. The more difficult thing is figuring out when we should be showing this. And configs because we don't have anythnig for linting configs.
* Josh: `global_mostly_unused`
* Scott: I've been trying to standardise the verbiage around clippy. Rustc dev guide may have some of the stuff on linting.

* weihang: Inconsistent relative path behavior between config include and other fields
* https://github.com/rust-lang/cargo/issues/15769
* weihang: It's about inconsistent path behaviour between our normal config.toml discovery for the target-dir and the config include field.
* Josh: So include is relative to the config file and target-dir is relative to the place where you're running?
* weihang: The target-dir is relative to the parent directory of the target directory
* Josh: Is it always relative to the workspace root?
* weihang: It put under cargo/something. So it will walk upward one more directory.
* Josh: At the very least this looks inconsistent.
* weihang: The only blocker for config inclued is the syntax problem. But that was cleared up recently with the `[[include]]` syntax. But now give this inconsistency, should we put this as a blocker for stabilizing the feature?
* Cargo wants to prevent people walking one directory up to not be able to walk up a dir.
* Josh: Yeah, if you have a config file, it makes sense to include other things next to your directory. But for target-dir it should be where that dir is. So it's inconsistent, but also kind of makes sense in that inconsistency.
* weihang: Maybe we can do a template?
* Josh: Yeah, didn't we already have a proposal for templating build-dir?
* weihang: But I can't see it'll fix the inconsistency. Normally you'll write a string there but you also need to write the default relative path here.
* Josh: The other thing: if you do config.get it will give you the relative value rather than resolving the path. I wonder if we can give you an option to resolve the path. `cargo get-config --path` and it would give you the path.
* weihang: Do people think this is a blocker for config include stabilization?
* Josh: I don't think it's a blocker, but we have to decide if we are okay with the difference of what we're relative to. And we should evaluate that as part of the stabilization.
* Josh: So this should go into the stabilization report.
* weihang: Okay, I'll add the comment to the tracking issue.

## 2025-07-22

- weihang: Should we make gix curl backend optional
- https://github.com/rust-lang/cargo/pull/15653
- argument: more flexibility in libcargo
- counterargument: libcargo isn't meant to be use directly
- Any opinion on using the `default` feature?
- eric: No strong opinion, seems like a reasonable thing to experiment with.
- josh: we're not stuck with this, since we essentially do breaking changes every release.
- No objections raised to trying this.

- (backlog) https://github.com/rust-lang/cargo/issues/15683 -- Cargo Tree should be able to show dependency platforms
- Add `{cfg}` in cargo-tree to show the target platform.
- Josh: It would help to be able to distinguish duplicates for situations like proc-macros, or dev-dependencies, or such.
- scott: Using this for parsing for Bazel seems like it should be using something like a plumbing command.
- If it would be possible to add a plumbing command within a relatively short period of time, would it make sense to do that instead?
- arlo: Would josh's motivation be a better reason to do this?
- josh: I use multitarget support, except cargo-tree picks up on it, and it is useless without `--target` with just one target. With multiple targets, it picks everything up as a duplicate.
- I'd love if cargo tree forced you to pick a target or have a default
- arlo: that almost sounds like a bug between cargo tree and multitarget
- josh: I'd also find it really helpful if cargo tree automatically flagged if something was coming from a build/dev dependency (like a proc macro)
- I don't mostly care about those depencencies
- I can't pass `-i normal`
- it'd be great if it would tell me "this is coming from a dev dep" vs. coming from a normal dependency
- I think there's a way to print the deps through the format string but it's not documenting
- but I thought this should be the part of the default output of cargo tree so you know where your dependency is coming from
- eric: things can get complicated -- e.g. you can have a shared dev and build dependency
- josh: that's fair. It would be great if it could tell you from which edge this was reached by
- for the thing they're asking for here, cfg sounds really useful
- eric: and for where there would be multiple targets, it would be comma-separated?
- I'm thinking multitarget or binary dependencies
- where you have a dependency that shows up multiple times for different targets
- maybe we could just print them out on multiple lines
- josh: I think in that case our default should be what we already do: print the dependency for each target
- that's what they show in the issue
- eric: does everyone feel this would be OK to add?
- arlo: conrecn -- this could get really long
- arlo: another: you can use build scripts to add cfgs
- we don't want to be executing build scripts to run cargo tree
- eric: I understood this to be printed just whatever targets are in your manifest
- arlo: so we're not talking about cfgs in general, just target cfgs. I thought they wanted all cfg flags
- eric: maybe we can name the option better
- arlo: I think in their request they want all cfg flags. So we should be clear on what we're accepting
- josh: the edge mechanism we could filter on could be the edge that would show up in the flags
- eric: sounds like this needs a little more design
- doesn't sound like what they're proposing is going to be enough
- and also that they shouldn't be parsing this
- I'll add 'needs design' and try to summarize the notes here
- we don't have a good solution on the horizon. Maybe we could stabilize `--unit-graph`?
- arlo: unit-graph is actually pretty close to this, but there's a lot of work converting that into a cargo tree
- eric: if you do `cargo test --unit-graph` it will show you all the test units
- but there's a disconnect between what that shows and how to execute `rustc`
- because e.g. LTO is a complicated thing to compute because of pipelining and things like that, overflow checks etc.
- there's hundreds of lines in Cargo to do that
- I planned to implement cargo tree in terms of the unit-graph but I gave up becauese it was too difficult to shoehorn one paradigh into the other
- arlo: I do think that unit-graph is quite close to the plumbing command that they're asking for
- eric: that's the direction I'd suggest but the question is is this too low level. We didn't get a lot of feedback on it IIRC

- (backlog) https://github.com/rust-lang/cargo/issues/15473 -- Cargo Tree HTML Output
- An interactive tree output to make it easier to navigate a large tree
- eric: The default cargo-tree output is relatively terse
- maybe you want to enable/disable features
- HTML could be powerful in that sense
- but then people will ask a bunch of features to implement
- e.g. I worked on a graph visualizer using graphviz (which I don't think we want to use)
- but then the question is how do we want to visualize it
- arlo: I used graphviz for the SBOM work
- but building it into cargo might not be the right thing
- people will want to do a lot of customization
- might be better done as a plugin
- but if someone's really passionate, it could be useful
- eric: sounds like a great suggestion
- if someone wants to do it, go implement it as a third-party command
- and if it's useful we may take it in
- there were similar things built in the past: cargo-dep, depgraph
- I can link those and recommend them to look at those as an inspiration
- arlo: yeah I'd like to see that as a third-party subcommand first
- cargo-tree also started its life that way
- we should also talk to Ed as he's looking into doing the TUI stuff
-

- https://github.com/rust-lang/cargo/issues/15210
- Add doc comments and doctests to lib.rs generated by cargo init
- Weihang: my feeling is we don't want to add any more stuff to cargo new. But people seem quite enthusiastic.
- Josh: FWIW I'm enthusiastic about our usual conclusion about not turning cargo new into a generalized template / showcase of everything. But in this case we're already showing people how to write tests with `cargo new --lib` so it seems reasonable to add a one-line doc comment and example of calling a function.
- we shouldn't show adding more files in the template
- but in the single file, adding doc comment is not that bad
- Scott: we could give new users the file that has everything and then add something like `--empty` that would be empty.
- if we're going to add more output to the base usecase, letting them adding a more programatic way of creating projects
- Weihang: What if we just ship a basic version of "cargo template" so people can discuss what to add there
- instead of cramming everything into cargo new
- Scott: is there a good templating tool currently?
- there's cargo-generate, cargo-cookie, cargo-wizard
- Arlo: givew we already have tests, adding doctests isn't that bad. You're already going to be deleting the entire file
- maybe we also want to add the `--empty` option
- as long as we're not adding a new file
- Josh: That's my feeling as well. Having a simple example showing how you do doc comments seems in the spirit of what we do now.
- Scott: I'm really hesitant for adding anything
- if we do, people will ask for more
- that will blow up our CI
- Arlo: We can still say no to that later but you're right it might make it harder
-

## 2025-07-15

- FCP reminder
- https://github.com/rust-lang/cargo/issues/14125#issuecomment-3029073591 -- stabilize `build.build-dir`

- josh: regression: cargo 1.88 nondeterministically hangs with nested parallel builds
- https://github.com/rust-lang/cargo/issues/15744
- Consider a stable release?
- eric: Seems fine, but I wouldn't make a stable release just for this. There has only been one person reporting it.
- jacob/weihang: Seems reasonable, open thread with infra.

- josh: Inside Rust blog post: [Call for Testing: Speeding up compilation with `hint-mostly-unused`](https://github.com/rust-lang/blog.rust-lang.org/pull/1662)

- (backlog) https://github.com/rust-lang/cargo/issues/15467 -- When cargo install --git checks out a commit, also set the branch and tag refs
- A build.rs that inspects the git info is unable to get the correct info.
- eric: Setting the branch name should be fine, but fetching all of the git tags may be very expensive.
- josh: git cli can maybe fetch every tag that you are already fetching? This may be the default (see `--no-tags`).
- jacob: Be careful about requests that follow, like fetch all the tags (like "is the latest version?"), etc.
- weihang: Fetch tags for entire dependency tree, or just primary install?
- josh: Would expect the same behavior with git dependencies.
- eric: This all sounds reasonable if it can be implemented. Needs some investigation.

- (backlog) https://github.com/rust-lang/cargo/issues/12456 -- Alternative to cargo publish --allow-dirty: cargo publish --exclude-untracked
- epage: how transient (CLI) or permament (manifest, config)
- weihang: This is probably not a workflow that we should encourage, shouldn't be publishing from your personal work directory.
- josh: Recommend closing due to lack of response, ...
- weihang: https://github.com/rust-lang/cargo/issues/9398 is potentially more important since it talks about possibly publishing sensitive information.
- jacob: Could `--allow-dirty=…` change how you feel (as opposed to adding a new flag).
- 9398 suggests removing `--allow-dirty` and splitting it into `--include-dirty` `--include-untracked`.
- josh: `--include-dirty` would have been nicer in hindsight.
- Not worth the churn to deprecate, but we could add `--include-dirty` and keep `--allow-dirty as an alias`
- eric: conclusion, will close this but leave 9398 open, still with some open design considerations.

- (backlog) https://github.com/rust-lang/cargo/issues/12437 -- profile-rustflags are not propagated to CARGO_CFG_TARGET_FEATURE or CARGO_ENCODED_RUSTFLAGS
- eric: Seems reasonable to include in these env vars.
- weihang: also ok with it.
- Conclusion: needs mentor

- (backlog) https://github.com/rust-lang/cargo/issues/12431 -- official API for reading cargo env variables
- josh: seems reasonable. Might need to split up API for compile-time versus parsing at runtime.
- conclusion: broadly in support, needs a little design work.

- (backlog) https://github.com/rust-lang/cargo/issues/15735 -- '.' is not allowed in crate name for "cdylib" crates
- Could [bin filename](https://github.com/rust-lang/cargo/issues/9778) be extended for this?
- There are related issues like [soname support](https://github.com/rust-lang/cargo/issues/5045)
- josh: for rust dylib, would want to keep it restricted, but cdylib seems reasonable to have more flexibility.
- eric: Only concern is about having multiple lib types.
- josh: could be as restrictive as the most restrictive one.
- jacob: Also consider setting `--crate-type` on the CLI.
- weihang: Maybe the field could specifically be something like `cdylib-name` to distinguish which crate type it is for.
- `crate-type = ["cdylib:myname"]`
- jacob: Can something like soname be processed after the fact?
- josh: in theory yes, but probably not.
- eric: In order to handle symbol names, this would require changes in rustc.

## 2025-07-08

- eric: Council survey reminder: https://blog.rust-lang.org/inside-rust/2025/06/30/2025-leadership-council-survey/

- FCP reminder
- Stabilize `build.build-dir` config option: https://github.com/rust-lang/cargo/issues/14125#issuecomment-3029073591
- epage: if there are questions, either do it in a meeting, office hours or on the issue

- jacob: Signing discussion review
- jacob: meeting went pretty well. We went over various updates, discussed the ways plain TUF isn't going to work. We'll need an extension
- jacob: Discussed what we're going to need for quorum, discussed filesizes a bit - no conclusion yet. We'll need to do experiments and come back to infra.
- josh: we got explicit assurances from the TUF folks (including primary maintainer of the TUF standard). We're the first folks trying to solve the total size of the update problem. Whatever we come up based on modifying TAP-16, they'll likely adopt that as the standard.
- epage: even TAP-16 seems to be a risk in terms of addressing the sizes.
- jacob: Yes, that's why we need to do the experiments. But if we figure out how to make TAP-16 work for our problems, that's what it'll be.
- Arlo: Are there other groups using TAP-16 or is it just a document?
- jacob: It's a document. Other groups may have differnt needs.
- Eric: How do you feel about how things are progressin?
- jacob: It was a good and encouraging meeting. Informed the stakeholders about the work that's happening.

- tomas: 2025h1 goal timelines
- Final updates to the tracking issues by 2025-07-27
- Final H1 blog posted by 2025-07-31
- Unclear whether you'll be able to post updates to the H1 goals
- unsure about the interaction with the ping-goals bot

- 2025h2 goal review
- https://github.com/rust-lang/rust-project-goals/pull/316
- cargo-plumbing (epage)
- cargo-script (epage, likely no significant team asks right now?)
- libtest-json (epage)
- pub-priv dependencies (epage)
- cargo caching improvements (ranger-ross)
- https://github.com/rust-lang/rust-project-goals/pull/317
- epage: Large in scope, Selina (??) or Weihang as the implementors?
- Might need a way to reduce the scope to something that can be done in 6 months
- We need to have the target-dir layout done and that's a blocker for all the follow-up work
- Maybe we might want to just keep the goal to the target-dir layout
- Waihang: I'll be available for ~6 months to help with Cargo goals, expect to be able to do this
- Eric: Uncertain around the relationship with the builder
- You're proposing stabilizing the builder and using it for the cache.
- epage: Just like you can have shared directory for target-dir, you can have a shared directory for the builder.
- But this is more about being smarter about user-wide cache
- If you have a shared build directory right now, the lock is ??
- The original though was to cache on the individual build units
- Making sure `cargo clean` doesn't destroy the entire cashe, protect against cache poisoning
- You can only share things that are non-local and that either have a build script or depend on a proc macro as the first step
- Next we could provide a plugin system to attach to e.g. a CI system
- https://github.com/rust-lang/cargo/issues/5931
- In the past been concerned about how much value we can give for users with build scripts or proc macros
- But hooking it to the CI service would make it more useful -- the cache could automatically pull at the start of your day and have all the dependencies set up for you.
- The build dependencies: we want to make clearer the compatibility guarantees. We already talked about doing this for the build directory.
- Eric: This seems ambitious for the planned goal for the next 6 months.
- epage: That's why I was talking about scaling this to just the build directory and locking scheme.
- I may have posted a note in the issue.
- Wondering what the Amazon folks can do here.
- Josh: Enthusiastic support for making this a less ambitious goal and doing additional work if that's done early.
- epage: Agreed, better to underpromise than overpromise.
- Josh: I see people have pushback on the idea of sharing the cache because a lot of languages don't have the concept of the fingerprinting like we have. And so you end up with "I have a build of that, reuse it and it's not the configuration we wanted". Haskell's Cabal has that problem. But we wouldn't share things that aren't identical.
- Better to not cache something than to cache something and have things go wrong. If that means not caching build scripts that can push people away from build scripts.
- open namespaces (epage, eholk)
- https://github.com/rust-lang/rust-project-goals/pull/322
- likely focusing on compiler and crates.io this term
- epage: There may be a couple of things we could do.
- How do we name the `.crate` file and how do we handle the index layout?
- That's a cross cargo and crates.io decision
- cargo-semver-checks (obi1kenobi)
- Contacted, is intending to continue.
- mirroring (walterhpearce)
- https://rust-lang.github.io/rust-project-goals/2025h1/verification-and-mirroring.html
- Josh: We're going to need to put together a new description for the next 6 months. But they want to continue assuming there aren't objections. Expect to get that done by the headline. I have a meeting with Walter today.
- Arlo: Is this separate from the signing goal?
- Josh: Same goal. Signing before mirroring.
- rust-for-linux
- https://rust-lang.github.io/rust-project-goals/2025h1/rfl.html
- epage: overlapping interest: build-std and looking at extracting doc tests for source code. And for DevX is to ??.
- Josh: I see asks for most of the teams they list. The only ask I see on cargo is "discussion and moral support". I don't think there's anything for us on build-std. Worth messaging them and asking.
- Josh: They're interested in having Rust folks to be on the meeting.
- build-std (davidtwco, ehuss)
- https://rust-lang.github.io/rust-project-goals/2025h1/build-std.html
- proposal will be posted soon
- epage: I'm going to be meeting with David later today.
- any missing?
- epage: Someone reached out to me, said they wanted to work on cargo. But I don't know them, feel a little hesitant at sending a project goal their way.
- If I wanted to send one their way I'd send XDG paths.
- Do some code history on when we agreed on CARGO_HOME with Cargo and Rustup.
- Arlo: We have notes from that meeting.
- epage: We need to find the versions that are going to be the problem. We even talked about maybe separating our `bin` dirs. That requires Rustup not deleting their directory.
- After the All Hands discussion it's not *that* bad I feel.
- Josh: Every separate piece of XDG we adopt is a separate piece of pain. But in case of bin dirs, but in cargo install, we want to install to `~/bin/` which is `XDG_..._BIN`.
- epage: What is the right behaviour for uninstalling Rustup? What should be cleaned up? Should we have separate bin dirs or not?
- Weihang: epage, @ojuschugh1 reached out to me as well, they're a past GSoC participant. I'll talk to them.
- Josh: Cargo has a bunch information about what it installed (so it can do `cargo uninstall`). Does `rustup` have the same information?
- epage: I think they either can't or aren't track what they've installed.
- Arlo: All their binaries are the same file so they can track it.
- Scott: Should I renew my project goal?
- consensus: renew it.
- epage: I didn't renew my cargo-script goal because it was almost done and that bit me several times.
- Josh: On the hints stuff, sounds like that may be a reasonable scope for a goal to do the end-to-end (docs, blog posts, explanations).

- epage: mdbook + rustdoc integration and cargo
- Is there any updates from Eric? Guillaume Gomez is interested in integrating rustdoc. Has he reached out to you?
- Eric: The prototype added a link to rustup docs to an mdbook on the sidebar and being able to host that on docs.rs as well.
- epage: I worry about us solely becoming an mdbook hosting service. If mdbook becomes a part of our compatibility guarantees? And if they're really just co-locating the documentation, I find that might be somewhat harmful without having a proper documentation of doctest running and intra-doc links. If the plan is only colocating the documentation I worry about that.
- Eric: The plan is to support intra-doc links and mdbook does that. I think the intent is to make it more cohesive but I don't know what that looks like. The stability is a really good point. It's not stable right now.

- arlo: Cargo's changelog continuation from 2025-06-24
- What would work for automation?
- epage: The process of automatically creating issues for our PR so people can ??. Since releases.md has a lot fewer entries than the ??. There may be a lot of issues created that can overwhelm our process.
- Jacob: Weihang, what's the hard part of maintaining the changelog and how can other people take it over when you're not available.
- Weihang: The hard part is removing unnecessary parts of the PRs (typos, tests, tweaks).
- Arlo: Is that something we could do by tagging the PRs?
- Weihang: I think so but it's still a manual process. You can't avoid it.
- Arlo: But this might let us spread the load.
- Weihang: Or the PR review can tag it and add a changelog entry.
- Arlo: Or add a changelog section into the PR template.
- epage: That's what Clippy does. Also we need to understand when and how e.g. nightly stuff should be included in the changelog.
- Weihang: There's a separate final review of the changelog so we can include more and then remove it later.
- Weihang: Requiring a changelog entry may put too much pressure on the contributor. But it seems to be working fine for clippy.
- epage: Or we can fill in a template saying "to be filled in by author or reviewer".
- epage: Weihang and Eric: you just had the experience recently. Would it have been helpful for you to have that section in the PR description.
- Eric: I think it would incur more time overall but it would spread it across multiple people. It took me 45 minutes to do that. If it's more people it may be way over 60 minutes total (but spread out). I don't find it to be difficult myself.
- Arlo: As long as people are doing it are happy, then we don't need to change it.
- Eric: If someone's willing to do this every 6 weeks then the overall voice is better.
- Josh: Does the one person doing this have the larger context. There may be value in contributing the text that this person can do that.
- Eric: That's a good point. Having the changelog entry in and the tool pulling out the entry if it's there instead of just pulling out the issue title.
- *neither Weihang or Eric have time to work on the automation*

## 2025-07-01

- ehuss: build-std PR to configure per-target: https://github.com/rust-lang/cargo/pull/15670
- ehuss: in our build-std we're actually moving away from this proposal. Thoughts?
- Josh: Is this: "when I'm building for this target I want build-std, when I build for another target I don't".
- Broadly desirable but at a later step when build-std is ready and stable
- For the moment having a way to configure it seems premature
- Can we deffer this? Or make it nightly-only?
- (multiple people): build-std is nightly only
- epage: I feel at this point people were just hacking on this and it might make more sense to rip out the code and re-implement it
- it's hard to follow what's happening and it's very brittle
- the code needs major clean-up
- Eric: I don't think these things are hacks. They were written deliberately
- epage: Some of the original things may not have been hacks, but there's code on top of code and top of code that seems hacky and hard to review.
- Maybe better to say it's very organically grown. Without a strategy or a goal
- Eric: another challenge: this particular person hasn't been in contact with us. We want to have a discussion first before we jump on the PR. I'm constantly pushing back on this person. This is their third attempt and it's not been going very productively so far
- There were several issues for per-package target support. I put a bunch of information on what needs to be done. They're having trouble following them.
- But this is not something we wanted to do
- Josh: The fact that the current direction of build-std is "can we try to get it into a shape we can stabilize" means: even if we are excited about this, we still want to ask to wait until build-std is closer to stabilization
- epage: Sounds like there are other alignment issues on per-package stuff so we want to have that resolved yet
- has there been any update we can give on the build-std work?
- Eric: The main thing there's been progress is the overview of all the approaches that have been done
- Josh: I imagine none of this was new for people deeply involved with build-std, but for other people it's really helpful to understand everything.
- Eric: The document says: these are the kinds of problems we're considering -- large spectrum of differnet things. It's not necessarily saying here are the different configurations or options. It says: here's this problem, we're aware of it. But it doesn't necessarily list all the options.
- epage: But having the historical contect of "in past history of build-std we did this and we've decided to go in this direction instead".
- Eric: Sort of but not really. It talks about the old RFCs and why they were rejected. Some were rejected before they were too ambitious. When we move to 2019 when I did the build-std that's currently in Cargo. There was no intent for this to be the user experience. Just to enable people. There was no UX plan.
- epage: The specific one for me was: expressing this in terms of dependency tables.
- Eric: That's what we're focusing right now. It might be nice for the end-users, but the level of complexity on Cargo would be huge.
- Eric: Getting back to this PR: I'll follow-up saying pretty much what Josh said: we're currently working on this, we want to wait until that's resolved.
- Arlo: I'm a bit confused because rather than fixing it, they're building a whole new feature.

- epage: can/should `toml` changing output to not work with old versions?
- See also https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/TOML.20basic.20strings.20with.20tabs/near/525963704
- epage: Apparently being able to not escape tabs in TOML was added in the TOML RFC. That translates to Cargo 1.47 was the first time that Cargo was actually been able to read it.
- At what point want to be able to use these vs. supporting old parsers.
- Eric: Are there any crates.io `Cargo.toml` files that would actually be affected?
- Arlo: This has to be a case-by-case basis. If we can consider this a bugfix and it won't impact a bunch of crates it's fine.
- Jacob: How hard is it for you to put a knob in your public API that Cargo can use?
- epage: My primary use for toml is Cargo. The stream parsing is done in such a way that I just want to add a knob for this. I'd like it to be one way or the other.
- Josh: Is there a rationale for wanting to emit raw tabs?
- epage: Prettier output of having fewer escapes in the string.
- Arlo: also following the TOML spec
- epage: The TOML spec allows both.
- Josh: If there were a rationale other than purely aesthetic considerations, I'd say maybe we should consider trying to find a way to evolve this further. But in the absence of that, it doesn't make sense to have a breaking change that could break older Cargo and other parsers.
- epage: There's also the inline tables.
- A standard table has a square-bracketed table
- An inline table is `{key = value, ...}`
- When we convert it to the canonical form for crates.io we normalise it to square bracketed tables
- It's not trying to follow a style guide, just a very straightforward output
- Josh: I wonder whether this leads to it taking more bytes
- epage: TOML writes out a very dumb output of TOML. The output is compatible with that version of TOML but not necessarily with the older versions (because we may be using newer spec features)
- Josh: I think we should be conservative in our output, but we should accept new *input* additions from the spec
- epage: I prefer to be more oppiniated rather than adding knobs.
- Jacob: It's worth us asking you but it's on you to push back if you disagree.
- Jacob: We could align this with an edition. It's not necessarily a part of an edition, but a breaking change during time when people are also looking at editions.
- Scott: The version came out a long time ago. It seems reasonable to be able to do this (but it's worth looking at how many things we'd potentially break).
epage: I'm happy to do the research but I'm mostly asking about the general principle.

- (backlog) https://github.com/rust-lang/cargo/issues/2373 -- rename [`profile.*.debug`](https://doc.rust-lang.org/cargo/reference/profiles.html#debug) to `profile.*.debuginfo` (which maps to `-Cdebuginfo`)
- Alex assumed it did more, like enable debug assertions
- In reality, only controls `-Cdebuginfo`
- Resolving confusion vs momentum
- Maybe some confusion on recent reddit thread? See https://www.reddit.com/r/rust/comments/1lcskhg/rust_compiler_performance_survey_2025_rust_blog/my58kl6/
- Eric: the `debug` field in the `profile` section can be confusing. It's just debug info, not optimization level
- Scott: Does rustc use `debuginfo`? It seems if it's only controlling the one thing to align it. The only question is: do we check bot of them? How do we let peple know this is what they should be using. How do we notify this is deprecated?
- Sounds like we could use the linting system
- Arlo: I do think the other name is better, just unsure whether it's worth the effort
- Josh: Agreed. It would be clearer, but the cost of changing it might be too high.
- epage: There's also the question of the usability cost of the people adopting Rust in the next decade or so (as compared with the transition cost we'd have to make)
- Josh: This will become more commonly set if we change the default to `dev`
- epage: So if we make that change, it'll become even more important for the future.
- Josh: Arguably more peole need it now rather than more people are setting it now.
- Arlo: I was confused by this.
- Scott: Alex is in the thread being confused by this.
- Josh: It's worth at least adding the alias. That's a feature. In the course of doing so, do we drop support for "debug=0/1/2" and just keep the descriptive ones (none/full/limited).
- Scott: Would we drop false/true?
- Josh: That one's more debatable. But the numbers should drop.
- epage: Should we deprecate the numbers separately?
- Josh: Support all of them for both and deprecate the numbers.
- epage: We could do a soft deprecation: update the documentation suggesting to use the names.
- Scott: We could also add a lint.
- Josh: Eric, in your giant `Cargo.tomls` crates.io download -- does that include dates? I'd love to see how say the last year's includes this.
- Eric: I don't have that but you can get it from the crates.io data dump.
- epage: Someone might have the profile set locally but it doesn't make it to the crates.io
- Josh: Can we confirm what we want to rename it to? The most common suggestion is `debuginfo`.
- Consensus: We should match `rustc`.
- Scott: In general, making the CLIs for Cargo match Rust is probably a good thing.
- Eric: Sounds like people are generally in favour of `debuginfo`. The main question is how we'll phase it in.
- epage: No one's pressing for quick phase-in.
-