Cargo team meeting notes 2025 Q2

--- robots: noindex, nofollow tags: meetings --- # Cargo team meeting notes 2025 Q2 ## 2025-06-24 - FCP reminders: - https://github.com/rust-lang/cargo/pull/15636#issuecomment-2944641679 -- multi-package publishing - https://github.com/rust-lang/cargo/pull/15673 -- `[hints]`. (This FCP is just for adding and ignoring the `[hints]` table; the specific hint being added is not stable.) - Tomas: 2025H2 project goals - Proposals open until 2025-07-18 - Submit proposals as PRs to: https://github.com/rust-lang/rust-project-goals/ - Flagship goals: smaller, more specific, bottom-up - What would you like to see as a flagship goal(s)? - More details in Niko's email or here: https://hackmd.io/@nikomatsakis/BkOXVTWNle - https://github.com/rust-lang/rust-project-goals/pull/316 -- contains a diff from last goal period - jacob: Will post update, may not have motivation to work on goal alone. - ed: Scott will likely carry over his. - Josh: something we may to weigh in on is signing and mirroring work - the work will continue - question around whether that's going to be accepted as H2 Goal - https://rust-lang.zulipchat.com/#narrow/channel/417663-tbd-signing/topic/Sync.20Discussion/with/525525832 - eric: Changelog? - Does anyone want to do the release notes? - Josh: rust-lang/rust has a bot that lets you tag an issue as a release note and it'll open a new issue where anyone can fill it in and automate the process - Jacob: Let's make sure we document the current process and then include Weihang in the automation as they've been the ones doing notes most of the time - epage: We have 2 tiers of release notes: the big ones that are sent to the notes across the project and then the changelog that contains every single PR - Jacob: the old system had a problem where some really important notes (e.g. with breaking changes) got dropped - josh: `[hints]` https://github.com/rust-lang/cargo/pull/15673 - josh: the main reason this is getting an FCP is that while the majority of this is going through the full unstable cycle, the `[hints]` table itself is an insta-stable - Why: we don't want the corner case where all the old versions will handle it with a warning, all the versions where it is stable will work without a warning - You could gate hints itself (the table with no hints in it) and then the one and only hint (so far) separately - epage: there's nothing we're locking ourselves into, we can change the hints table however we want - josh: what this FCP is just stabilizing the `[hints]` table - Jacob: this feels like a two-way door; we can always remove it again if we want to. Glad I was consulted on it but happy to check it off. - eric: RFCs that could use attention? - https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+label%3AT-cargo - epage: several of these are waiting on author - epage: four that we could do something about: - changelog - https://github.com/rust-lang/rfcs/pull/3779 - CARGO_CHECK - https://github.com/rust-lang/rfcs/pull/3748 - recommended-bin-packages - https://github.com/rust-lang/rfcs/pull/3383 - safe file discovery - https://github.com/rust-lang/rfcs/pull/3279 - Josh: also #3759: Allow packages to specify a set of supported targets - Eric: I was supposed to ask them to make sure they know this won't be supported for cargo.lock filtering and so on - epage: I summarised it in this comment: https://github.com/rust-lang/rfcs/pull/3759#discussion_r1973868712 - Josh: I thought that we were going to drop the resolver target filtering for now - epage: We talked about that, but there was too much complexity. We ended up going with the config `[resolver]` table - epage: Should this RFC just be left for target filtering? And if so, is there enough usecase to justifying this feature? - Josh: I'd still like to see dependency filtering based off of manifest rather than config - epage: If we never do the manifest filtering, is this feature still justified on its own? - Josh: Yes, I think it would be useful still even without that. - epage: Looks like we may not be able to do that for cargo-vendor, so we want to separate those two features as really two separate features and make sure this has value on its own. - Jacob: The links filter had something similar. - Eric: I'm a bit hesitant about supported target. Let's say we'll want to do families (e.g. unix, windows), we might end up with two fields: supported targets and filtered targets that may look very similar. - Josh: We should make sure that something's being treated as a future work for a proposal we need to make sure that there's a way how we can get from A to B - Eric: But we know now that we can't get from the current proposal to the the second one - epage: For us to filter things out from the cargo-vendor we have to filter them out from the lockfile - Josh: there's no degree we can do the lockfile without doing the full vendor portion? - epage: No. - Josh: There are a numbre of times when people want to say "I don't want all the windows and redox stuff on my linux machine" - Jacob: If we say there's a static filter at the root and ?? - Josh: That case you've just described is the one I'd say we could explicitly not do. What we could do is filtering based on the top-level filter. And the top-level filter would let us specify dependencies that we're never going to use for the given target. We won't have to detect the intersection of the cfgs - epage: It'd be good for us to come prepared for the next time, have a summary of the past discussions. This will help us figure out how related/unrelated those two features are and whether it makes sense for us to treat this as one feature. - Eric: Agreed. We talked about all these things. I can work on putting together a summary. - epage: Crate changelog field #3779 - epage: We've rejected this RFC before - epage: Do we want to reject it again? Or move this to crates.io? - Josh: Has there been any progress on updatable metadata? - epage: The first step on the process was a custom message on yank. That stalled out. - Josh: URL for the current changelog feels like it should be updateable (and possible it should be a file for the current changelog?) - epage: If it's a file, we're running issues with editability. They've tried to avoid problems with the previous RFC by making it a URL instead - Eric: vibe check? - epage: I understand the problem they're trying to address. There's a couple of us that have a broader vision of what should be done. But there's a lot of pieces and I don't know what should be done in the short term. I don't know this is the right imperect solution. - Josh: Great summary. I think something should be done in this area but not sure if this is the right something. Also not sure the focus on the changelog is right. - Josh: I've seen people call it "changelog.md" and sometimes it's a list of commit and sometimes it's ?? - epage: Sometimes people say you shouldn't generate a changelog off of the commits. But there's not a choice between a commit-based changelog and a hand-written changelog but between a changelog and not having a changelog. - Josh: This is more of a question of how we frame it -- not to prescribe how it should be done. - Eric: I agree, it's frustrating trying to hunt for a changelog for any given crate. - Arlo: If we can get people start doing this, that's value on its own. - Josh: We can get surprisingly far in the Rust community with tools built around a best effort. Having a URL with an anchor per changelog is something that tools can then go and use. - Eric: Has anyone on crates.io said anything? - epage: No, they haven't. - Eric: I'll ping them. - Arlo: It'd be great to see this in docs.rs as well. - epage: Making sure that anchors will be on every single release is going to be a lot of work. ## 2025-06-17 - FCP Reminders: - https://github.com/rust-lang/cargo/pull/15374#issuecomment-2791032791 -- Add http.proxy-cainfo config for proxy certs - https://github.com/rust-lang/cargo/pull/15636#issuecomment-2944641679 -- Stabilize multi-package publishing - Josh: Does this toposort the packages to get the order of publication? - epage: It does a topological sort, taking into account removing: some dependency edges can be removed - epage: If you don't specify a version for a dev dependency, we strip the dev dependency - Josh: If someone publishes a large multi-crate package and someone does cargo-update in the middle, things should still work - epage: If you publish in the middle of the dependency graph, it'll rely on the crates that are in crates.io at that time - we have tests for dependency cycles - Scott: should we talk to the crates.io people re dependency cycles - Jacob: They're doing a lot more verification now than in the past, so it might be worth checking with them - If we change the role of semver, we need to make sure they update that semver patch - Eric: That could be expensive -- they'd have to load every version of the dependency - could be many thousand rows in the database - Eric: could we generate a better error message? - But none of this should block the FCP - epage: Two issues. One we don't have a reproduction case for yet, the other we have a reproduction case for as of a week ago. - doing a dry run without having built any packages - https://github.com/rust-lang/cargo/issues/15647 - generate.crate gives a different checksum that's what's in `Cargo.lock` file - josh: Appreciation for the snapshot testing infrastructure - josh: `[hints]` and `hints.mostly-unused`: Design for letting a package provide the hint about itself. - https://github.com/rust-lang/cargo/pull/15673 - Josh: we talked about the hinst infrastructure last week. Implemented it yesterday - added `[hints]` table and a `hints.mostly-unused` hint - have test in the test suite that verify that this works and that the profile version of the hint overrides this - that means a top level crate can control the hint - distinguishes between: true, false, ?? - Scott: min-opt level means something like "sqlx should be built with opt level 1" - Josh: Yes - Josh: The profile mechanism should be able to override what a dependency does by setting `profile.dev.my-crate.opt-level` etc. - epage: The hints table should not affect MSRV etc. -- we can add/remove freely. It's not there as far as stable is concerned - Josh: that's my intention. I need to find a place in the documentation for the hints table - Everything in the hints table should be ignorable -- if you ignore hints you should never fail to build - You can rip the entire hints table out and at worst you'll get a warning about some unused keys - Eric: what happens if you get a parse error while in the hints table? - Josh: right now for any unknown key we simply ignore it - But I should add a test that e.g. adds an invalid value to a known key - epage: we did that for the lints table while it was unstable - Josh: While the hints table is expected to be not gated in the sense that it's best-effort parsed and ignored on errors - But if you set a hint, we won't use it until we have the feature flag set - epage: Can you document the precedence in the PR/docs - there's the dev profile, user custom profile, build overrides, etc. - where in all this does this override? - Josh: You're asking what is the order of the overriding? - the intent is: everything in a profile overrides the hint - for min opt-level we'll need to distinguish between the default value and the hint vs. having it set explicitly in the dev profile - Scott: are we going to document the hints that are available? - like the lints doc that we have now? - Josh: we're defining and documenting this - epage: right now the `[hints]` table will be insta stabilised, but the new lint will be unstable - Scott: having everything specified in one place, marking it as unstable and then linking into the unstable docs makes more sense than having it split between multiple docs - josh: Project goals 2025H2 discussion? - We're starting to discuss 2025H2 goals - We'll start hearing from folks with asks on the Cargo team - There will be goals that people will want to add as well as goals that folks will want to renew - Scott: Does it make sense for things that will only take e.g. about a month? - epage: I've made that same mistake for cargo-script, we had to turn it into a goal eventually anyway - Jacob: re first half year goal followup - Unsure that'll happen for my goals -- unclear capacity - Code signing stuff: if you can't give updates to the monthly report on what your progress is, then I'm not comfortable renewing the goal again - you get official support from the project in exchange for publicly saing what needs doing - there's not been an update on the project for two cycles - Goal doc: https://rust-lang.github.io/rust-project-goals/2025h1/verification-and-mirroring.html - Sync meeting scheduling: https://rust-lang.zulipchat.com/#narrow/channel/417663-tbd-signing/topic/Sync.20Discussion - epage: hasn't there been a process to explicitly withdraw support when the team was no longer receiving updates on the project? - Jacob: if no one proposes it, the goal won't be created and that'd be fine with us - but that feels passive aggressive - Scott: we should reach out and ask about status and be definitive about what we're looking for - it's the fairest thing for the person working on this - If the in-person conversation about the renewal of the goal gets scheduled, we'll be able to talk to them on video which may be less harsh - The primary person driving this is Walter Pearce who's working on this for the Foundation - Eric: I'd like to figure out some next steps - Not sure if we've made it clear what we were expecting here - Josh: after the Rust Week conversation, I had long conversations with Walter and Joel - regarding the level of communication expectation - There have been a couple of updates since RustWeek - Josh made it clear that the update shouldn't be going just to tbd-signing but also to the rust goal tracking issue - epage: reading the May 20th update, is Walter saying it'll be 30MB? - https://rust-lang.zulipchat.com/#narrow/channel/417663-tbd-signing/topic/Download.20reduction.20progress.20.26.20question - Josh: that's for Vanilla TUF and that's why I don't think that's the way to go - epage: I was expected this would be like 1k or something - Scott: given that rustup already has a lot of trouble with parallel downloads, adding extra 30MB per repo would be too much - Josh: nobody is proposing we'd do this for releases (see the Drawbacks section on that post). The proposed direction is using Merkle Trees - Jacob: No one's done a Merkle Tree implementation for this so a lot depends on the implementation - Josh: The Merkle Tree should let you say that the root is validly signed by an upstream tree and then the leaves match the expected hashes and then that should be enough to know that this matches the complete tree without verifying every single leave - Josh: The Rust releases mirror (including all the nightlies) is around 1.7 terabytes and that's an open question - do we want to sign all that? - create a smaller valid mirror? - Eric: We need to make sure Walter deals with the health issues - But when we have the sync discussion, we need to check with him to make sure he'll be getting regular updates - And if things don't get better, we'll talk to Joel - Scott: I want to note that things have been better lately. We need to be clear on that. - Jacob: The next set of project goals will have to happen during the next month - Scott: If someone has a life problem, we can backport this - Josh: I expect sometime within the next week or two we'll see how things go ## 2025-06-10 - https://github.com/rust-lang/cargo/issues/15646 -- SemVer impact for removing of features - https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/How.20old.20is.20this.20feature.20resolving.20quirk.3F/near/430327908 - epage: jubilee recomended that it's not a major breakage. I disagree. If we had cargo-upgrade-like behaviour it wouldn't respect this. Changing your version requirement would make the resolve to fail. - adds an upper bound on your requirement without explicitly mentioning it -- can break a lot of people - JoshT: Corollary of the [preparedness paradox](https://en.wikipedia.org/wiki/Preparedness_paradox): If you put in effort to catch an issue that's still incorrect and your mitigation is half-way good, people will start asking if it's worth it after all. This is absolutely semver-breaking, and the fact that we have a mitigation doesn't make it less breaking. - Jacob: Why we added this in the first place: the resolver often spends thousands of iterations in the parts of the dependency tree where it won't make progress, ... ??. - The problem here are indirect dependencies where the resolver hass'nt figured it out yet - Jacob: Agree that there's room for explanation of what the breakage looks like. - epage: I worry about us trying to dig into the nuance and implementation details of trying to quantify what the breakage is. - Eric: sounds like agree to close this? - Jacob: Violating semver on purpose is a normal thing people are allowed to do. - epage: "semver is about transitive dependencies" article - Eric: I'll close it off and write it up on why. - (backlog) https://github.com/rust-lang/cargo/issues/6827 -- warn or remove support for separate lib/crate name (latter would require a breaking change) - Useful for experiments / short-lived forks - A way to experiment with namespacing / temporary forks - A cdylib person found this useful to have their package prefixed with `lib` and then removing that prefix in the lib name because cargo will auto-prefix with `lib` so they don't get `liblib` - Abuse can be confusing (can't assume what to use in code from package name, see the Python ecosystem where these are set separately) - epage: for closing the issue (this is intentional) - `[lib]` are the exception - Considered a lint but already rare - Scott: Because this is sufficiently different from normal/expected it's worth having a lint but I understand it can be verbose - JoshT: Lint if we want to make sure someone doesn't do it by accident - epage: If someone's doing it intentionally they probably have a good reason anyway so seeing a lint's probably not going to change it. - JoshT: Should this be allowed for new crates? Feel maybe we shouldn't - epage: I think so (e.g. cdylib) - e.g. I want a temp fork of serde without having to rewrite all the `use` statements - JoshT: That one is actually interesting. Sounds like we should close it and move on. - Eric: we'll revisit later if we change our minds - https://github.com/rust-lang/cargo/issues/8164 - Jacob found nothing would be broken by implicitly adding the feature - Requires extra work in pubgrub resolver - Confusing to users - Josh: thinking through other compatibility hazards, couldn't come up with any - Even if we add negative features, this shouldn't be an issue, because the invented `default` wouldn't depend on anything, so `-default` wouldn't actually turn anything off. - Jacob: noticed one hazard, `#[cfg(feature = "default")]` would have already evaluated to false, now will evaluate to true sometimes - Ed: `check-cfg` would have helped catch these problems - Josh: Would be nice to remember that we created the `default` feature, and not tell `check-cfg` that `default` is a valid feature in that case. Only if it's straightforward to do. - Ed: why avoid telling `check-cfg`? - Josh: focus is on caller, not crate author - Ed: keep it simple - Eric: detailed questions - Should this show up in index? no for space? - Published manifest? should match index - `cargo metadata`? subtle changes "broken" people - Ed: just do during normalization of manifest - except than index and manifest will mismatch - Josh: Doing it on publish would mean that a subsequent publish with old cargo would mean a feature gets removed. Worth being aware of - Jacob: only old versions can detect the breakage - Eric: For `cargo metadata`, it could break people either way - Ed: `cargo hack` might run in more cases - Could noticeably slow it down by doing twice the runs when no features - Eric: compromise: only do this for CLI - Ed: can't just ignore, `--no-default-features -F default` should cancel each other out - Josh: Also, Jacob previously observed that this change would simplify the resolver by avoiding a special case - Ed: worry about having all these special cases that will confuse users - Jacob: Already been hit by this, someone else will be hit and will open this bug again. - Eric: Summary: no specific decision, needs more design work. - profile-hint-mostly-unused: Design for letting a package provide the hint about itself? (Design should also support opt-level.) - https://github.com/rust-lang/cargo/pull/15643 - Josh: adding mostly-unused to the compiler as a profile option. It has value in itself -- you can declare it for dependencies - Crates where this is useful for big crates where you don't use most of the crates (such as windows-rs or big cloud crates) - Worth being able to override it because you've written a binding to another language where you don't want them deferred - But sufficiently unlikely to support this in mid-level dependency. Should be okay to only set this in the top-level crate's dependency override - Ed: Have to design two parts of this: the actual setting and the override - Do we allow this in other cases such as opt-level for dependencies - Josh: we should design what table this should go in and have this be the first enry on the table - Ed: You want to apply it to your dependents but not yourself? - Ed: Should this also be an attribute in Rust? Does that solve most of the problems for window-sys defining it for itself? - Eric: Will these hints be based on the profile (debug/release) - Josh: Wouldn't typically expect that, but could be supported. - Would expect that you'd want it for both profiles in majority cases -- seems unlikeyl you'd only set it for one profile - Eric: was thinking if we extended this for other cases such as opt-level - Josh: For opt-level you already have differnrt opt-levels for different profiles -- you set this hint because you want this anyway - Eric: If you're setting this hint, it's becaues you want opt-level 3 in release while opt-level 1 in debug - Ed: if you're setting this on a profile as a dependency, what profile is actually being run? - Josh: That's why I think this hint shouldn't be profile-specific - Josh: We could specify "hint min opt-level" to set the minimal optimization level - Jacob: How does z and s fit in? - Josh: Where should we put this in Cargo.toml - if it were one-off option, I'd put it into `package` - if it's a family, should it be a table (e.g. `hints` -- kinda like `lints`) - Ed: If generalized to `profile`, then yes a dedicated table. Otherwise there's probably going to be a scale of 2-3 of these so having it in a general location like `package` - Or `[lib]` but that means people have to manually specify it - Josh: The fact that there will only be 2-3 shouldn't mean we don't have the table. What do people want to see? - Jacob: If you have a one-off you can spell it `hints.` - we can make it a table and recommend spelling it `hints.` - Eric: you'd have to put it at the root -- above package - Josh: or say it `package.hints.` - Josh: if dedicated table, you could do: `hints.workspace = true` for workspace inheritance - Josh: in big saas with many crates you may want to inherit it from the workspace - Ed: that implies most/all the crates would have to want the same - Is this inherent to the workspace or is it a means of reducing duplication? - Features shouldn't be required to be the same across workspace - This is why we removed `public` from workspace inheritance, because that depends on the crate - Weihang: `hint` table sounds good. I'd add another hint: scheduling (per package) - Josh: No strong opinion on workspace inheritance. - There would be value in this - Less deduplication more define the common sense and define the expections - But wouldn't push it if there's reason not to - Scott: you could do named inheritance - Ed: `workspace = "sdk"` - Josh: Some consensus in having a hints table? - Ed: We don't know enough, need experiment with something - Eric: Write down what it looks like in Zulip and ask what people think? - Proceed with understanding that it might need to change in the future ## 2025-06-03 - https://github.com/rust-lang/rfcs/pull/3826 - Procedural macros in same package as app - Relationship with nested package rfc? - ed: Not quite the same since it is a new cargo target. Nested packages wouldn't be able to solve `$crate`, but uncertain if that would be possible. Might need to have a way to tell the compiler what `$crate` would evaluate to. - josh: The other solution for $crate is to wrap in a macro and pass to proc-macro. - epage: `cargo publish --workspace` -- Level of quality for stabilization? - aka calibrating on what level of quality to stabilize - One known issue: when switching from a path dep to a registry dep, the lockfile may need to re-resolve for the version requirement now being taken into account - Its annoying when running into it but shouldn't be a reason to pull the feature or break the user, so no stability impact by deferring the fix - scott: If you know of some issue, address those before stabilizing? - jacob: Stabilization notes could note any issues. If those known problems become more than a footnote, maybe that needs more to address? - weihang: Some users have a large number of packages, and if it fails in the middle, they can't resume. So they may not be able to switch to this. - ed: publish workspace does verification before it starts publishing, so that should be better than a shell script. - weihang: Thinking more about network errors. Potential blocker, or maybe an enhancement. Comparing to existing tooling which would be able to resume. - arlo: To consider is that if we need to make that enhancement could it cause a problem if it is already stable. Unknown unknowns. - eric: Mostly if we don't anticipate many people to run into problems, then that seems like it should be fine. - Something like weihang's example seems like we should be able to address that after stabilization. - scott: +1 to being able to note in the release notes, and use that to gauge the quality. - weihanglo: `http.proxy-cainfo` FCP with concerns - https://github.com/rust-lang/cargo/pull/15374 - Just check in if they have addressed the concern, or we should suggest splitting the aligning curl behavior out from the `http.proxy-cainfo` change. - josh has resolved concern. - ed: Start with fallback and evaluate the config? - ed: Don't feel in a position to block due to lack of knowledge, but uncertain about why have the config and the fallback, and not just the fallback. - arlo: Can go either way, could be potentially useful, but don't have a rationale from this specific user. Would prefer without unless there is a motivation. - ed: Always a cost with anything being done, more config can cause more confusion. - weihang: Also a concern with other networking backends that would need to recreate the same logic. - Motivation and information: https://github.com/rust-lang/cargo/issues/15376 - ed: Would like to have a clear explanation of why the explicit config is needed over the fallback. - weihang: will take care of asking for that. - https://github.com/rust-lang/cargo/issues/8164 -- people commonly expect the built-in `default` feature to be implicitly created - jacob: Semantic difference between no default and empty default. If you ask for a dependency with `features=["default"]`, the resolver will skip over dependencies that don't have that. If we changed that, that could end up with a different resolve. - jacob: I have a set of tests in pubgrub related to this. - jacob: If it's just the command-line, then maybe it is ok, but if it is the same issue as the resolver, then it could be a breaking change that needs more thought. - ed: In the past, this seemed a little weird. - jacob: Can someone remind me to look into it, to quantify the problem. - josh: Does removing the special case affect future changes for negative default feature? - ed: Don't think so. That might involve something more like a "base" feature specification, so that might involve two separate approaches. - https://github.com/rust-lang/cargo/issues/4966 -- `cargo doc` web server - ed: Is this also a problem for WSL? - scott: Dev containers or remote, it is difficult to access `file://`. - josh: clearly articulate all motivating use cases - josh: local file stuff less motivating, specifically whats written (e.g. limitations in vimium) - eric: Feels like there are legitimate concerns with browser settings that we don't want to tell users to enable some potentially less secure option to work around the problems with `file://`. - josh: some justifications based on file protocol, but also rustdoc bugs (e.g. paths used for fonts?) - jacob: Also talk to rustdoc team. - weihang: Concern if people use this in production. What is the exposure to cargo for things like vulnerabilities. - ed: Mindful of security aspects. Is reasonable since many site generators have something like this. - Regarding serving endlessly, this could tie into something like watching for changes and regenerate documentation. - `--interactive` - Arlo: +1, does it run until ctrl-c? - Could implement this in nightly, and not necessarily block for watch support. - scott: Have a semi-official place where people could implement it and experiment with it outside of cargo. - ed: Like a nursery, like some of the gsoc projects. - eric: Another consideration is that `rustup doc` is also in the same boat of wanting to serve files. Wondering if we should coordinate with them. - eric: Will reach out to rustdoc for feedback. - josh: And document limitations. - eric: Examples of the kinds of issues and scope creep that can happen with this: https://github.com/rust-lang/mdBook/issues/?q=is%3Aissue%20state%3Aopen%20label%3ACommand-serve ## 2025-05-27 - TC: Hired PM is coming onboard next week. Invited them to join this meeting. - eric: cargo target tiers, what are they? - Are tools like cargo included in the tier policy? - Currently cargo is not being tested on all tier 1 targets. - general tier vs tier with host tools - josh: We should be running tests for tier 1. If not, we should try, but best effort. - ed: Could only run when merging instead of just PR. Most likely these aren't going to fail. - josh: Worth considering adding Windows and macOS to rust-lang/cargo CI; it might not slow things down, since hey can run in parallel. - eric: there is a difference between rust-lang/rust CI and cargo's CI. rust-lang/rust is currently only testing on two targets. - eric: The other issue is whether or not we should be involved in tier promotion? - ed: Our risk factors are sys platforms, platform-specific code like file locks. - ed: A provisional tier 1 status, where the tests are blocking, to identify problems. - eric: Suggesting that we aren't required to approve tier changes, but we can always raise concerns during the process. - josh: Wonder if we drop a few more tier 1s. - x86_64-apple-darwin - eric: GitHub may eventually force our hand on that. - i686-pc-windows-msvc? - eric: Will investigate more and open a conversation with infra about adding more jobs. May just add aarch64-apple-darwin on r-l/r and double check cargo's coverage. May not bother with i686. - eric: Testing compatibility with older versions of cargo. Would we be OK accepting the cost in CI? - josh: Are we testing a full mock sparse index, not just test packages? - eric: Our CI creates an index and tests against that. - jacob: Could help with us knowing when older versions don't actually work, and we can stop saying that they do. - scott: Debian stable could be a good threshold. - josh: This will soon bump to a much newer version (1.85). - weihang: And the first version of each edition. - jacob: Problems of chains of versions. - eric: We do have some old cargo tests to make sure that you can start with an old version, go forward through every version, and then walks backwards. - eric: Will look into starting with a basic start with one or two versions, and see how it goes. - weihang: how to call for testing for `-Zrustdoc-depinfo` - This is more like a bug-fixing unstable feature. People may have no reason to opt in if they don't needed it. - rustdoc team may rely on us to report how useful it is in order to stabilize `rustdoc --emit=dep-info` - eric: Feels like it would be fine to just stabilize without calling for testing, assuming we have some tests that cover the issues it is intended to fix. - When making a proposal to rustdoc team, do something like a stabilization report to explain *why* we are stabilizing it now, along with a set of tests that illustrate what things it solves. - weihang: Do we try to handle other things like extra `.css`? - eric: Feels like it would be fine to defer that till the future whenever they want. - josh: Vibe check: hint-mostly-unused - Thinking of an MCP to add a flag to rustc to provide a way to do best-effort code-gen as much as possible. Essentially "inline yes". This can avoid codegen for crates where there is a lot of unused code. - Possibly add a cargo profile, a way to set this for specific packages. - mir-only rlib ran into corner cases, and may never be stabilized. https://github.com/rust-lang/rust/pull/119017 - This would be more stabilizable than the experiment "inline yes" threshold. - This wouldn't work very well in some scenarios like if you have a bunch of separate test binaries, they would all get a lot of inlining. - In the future, would like packages be able to provide a hint for themselves. - jacob: Do we want this a bespoke feature for this one flag, or how much does this open up for more things? Or more generalized solutions. - josh: Would like to expand to other things, like being able to specify a package wants to be optimized. - ed: example: sqlx recommends opt-level=3 override. May need to be cautious, but would be great to be better defaults. - josh: Could also need to limit, for example don't want to override debug symbols. - ed: Could cause some complexity with custom profiles? - josh: These hints may apply regardless of the profile. - Would need to think of some of the complexities like conflicts (dependency specifies `opt-level=3` but binary crate wants `opt-level=z`). - No objections to experimenting. ## 2025-05-20 - `cfg(version("..."))` https://github.com/rust-lang/rust/pull/141137#issuecomment-2888466686 - Do we want to block rustc until cargo is ready? - https://github.com/rust-lang/cargo/pull/15533 - Contributor (rustlings maintainer) offered to help with this. - ed: Hope to get this done to not block rust-lang/rust side. - We want to have this in the same release, and we don't expect it to be a blocker. - josh: What does it do on old cargo? Does it error out as expected? - ed: Should set up a test for that. We should verify that. - ed: Recommend reading the stabilization report, there are some subtle changes from the RFC, such as nightly patch version matching. - weihang: Does this have interaction with the resolver? - jacob: Not really, but there will be things like "this shows up in the lock file, but isn't reachable" like other cfg things. - epage: All Hands catch up - codegen settings - ed: compiler pushing for adding a general field in cargo that is just "codegen settings" as a set of strings, which cargo just adds `-C`. Similar problem as profile.rustflags. Target modifiers can make it a builder link error if there are soundness issues. - josh: Doesn't change the story for `profile.rustflags`. Reading the codegen flags for consistency. Not all of them change codegen; some are just arbitrary flags to rustc. - ed: May want to have an allow list. For example, may not want llvm flags. - A more fixed syntax makes it easier to handle (as opposed to general rustflags). - Another consideration is how rustc handles repetition. - Some rustc `-Z` flags get stabilized as `-C` flags even if they're not about codegen. - Overlap with flags that cargo handles, like strip or debuginfo. - ed: What is the reason we specifically don't want profile.rustflags? - josh: Bringing into the manifest has a higher expectation of stability. - weihang: Why have codegen in profile? What's wrong with just setting rustflags? - ed: How to smooth the addition of codegen flags across the teams. Cargo doesn't know if it is safe for it, or what the right abstraction is for it. Don't know if codegen settings is necesssarily the right approach or solving the problem, but that is the intent. - ed: Also the per-profile aspect, to make it easier to switch between different configurations. - josh: Also to set flags per crate. - josh: crates that only support specific targets - https://rust-lang.zulipchat.com/#narrow/channel/436762-wg-embedded/topic/Supported.20Targets.20RFC/near/518342819 - https://github.com/rust-lang/rfcs/pull/3759 - ed: First stage is to just filter for local development with `--workspace`. - ed: Is there enough of a use case for this to move forward, and the answer seems to be yes. - josh: Prunning from the lockfile can wait. - lints - ed: Lessons learned. What is the role of check versus clippy divide? Came up with a list of reasons. Boils down, easier to add to clippy than to rustc. Was originally thinking, if we split them, don't want to force. `cargo lints` command for managing multiple linters (rustc, clippy, cargo, other third-party tools). - weihang: Can continue to stabilize `cargo::` namespace. - ed: Yea, clippy doesn't want to add any new ones. - cargo-semver-checks talked about rustdoc JSON linking between crates. Thinking about adding the rmeta path in the json. - explain, digging into errors - Tim McNamera Also rustc lints and clippy lints. Rendering markdown from cargo? How should register-tool fit in? Navigating to messages and then getting explanations to expand a message. - doctests - Idea to allow rustdoc to run as a rustc driver. In rustc driver mode, it will convert the doctests to `#[test]` functions inlined in the crate. Does some transformations to be able to access the API via the crate path. Some drawbacks and benefits of being able to access private APIs. - arlo: One benefit is being able to run doctests just like normal unittests. - performance - ed: Feel like I failed at my talk :(. Was hoping to move on to roadmapping and project goals, but realized it should have been how do we make decisions on prioritizations (like across or within a team), how to avoid diluting to prevent progress. - jacob: Feels like the effort was a success, since people got to talking. - arlo: Also feel like it was good to get discussion flowing. - ed: At least three different discussions of proc-macro sandboxing. Was hoping to get better clarrification on what problems to solve, and is it worthwhile to sandbox, or are other solutions good enough. Unfortunately didn't have that discussion (would have preferred to start with that). - build-std - jacob: Three levels of topics: - What content got discussed. I experienced differen things. - How did the meeting go, and how did people respond? - There seems to be some miscommunication between people who didn't show up to meetings, or had different understandings. - ed: david wood scheduled a meeting on build-std without specific topics, but there were some frustration with what happened during the talk. - Timeline: 1 year ago, started discussions, and ed asked for a document to get up to speed - Goals process started, and we reiterated the need for the documentation to get up to speed. - Lack of clarity during back-and-forth on that initial document. - Josh + Eric having synchronous meetings. - Things seem to have gone silent (from jacob's perspective). - Talk at all-hands. - others? ## 2025-05-13 Skip for RustWeek ## 2025-05-06 - epage: All Hands Prep - Thought on making documentation easier to discover, cohesive (our involvement being the Rust book) - arlo: Agree with the problem, if you don't know what you are looking for. - ed: Some better kind of navigation between parts of the documentation. - arlo: Agree, some kind of top-level navigation that unifies the different sites together. - josh: The link to https://www.rust-lang.org/learn link isn't obvious, if you're looking for "documentation"; you have to know that "learn" gets you there. And being able to navigate once inside one of these documentations to other parts of the documentations. - also redundant with https://doc.rust-lang.org/stable/ - weihang: Make the official documentation more standout? Can't tell the difference between someone's random rust guide, versus reading something from official rust-lang. - ed: We are lacking some official thing like official design language that is from the foundation. Some kind of branding thing or guide. - eric: Also some way to switch between stable and nightly and other versions of the documentation. (Including specific 1.xy versions.) - Approved RFC for this that hasn't been implemented: https://github.com/rust-lang/rust/issues/44687 - Amazon folks pushing for sandboxing - eric: Generally reproducible builds are supposed to be supported, and anything that conflicts with that is intended to be a bug. - weihang: One of the biggest challenges is building C libraries. - ed: Reducing the reliance on build scripts goes a long way towards avoiding the need for sandboxing those. - ed: If we were to consider pluggable sandboxing, trying to handle wasm or native executable sandboxing (ie docker) would be out of scope. - Wonder if it is worth that when other things address the majority of the use cases. - Arlo: Starting with proc-macros might be easier since they don't need system integration. - ed: There are some exceptions (like sqlx), 99% of proc-macros don't need. - ed: Declarative macros vs proc-macros vs reflection, could replace uses of proc-macros. - weihang: Social aspect of sandboxing, to drive the community to writing better build scripts (or using better mechanisms we provide). Otherwise for company usage, they can just use docker or whatever to isolate things independent of cargo. - eric: Support for `-Zedition` to assist with edition testing. - We want to add support for edition testing, especially with crater, but also locally. Any objections for a permanently unstable experimental `-Z` flag? - Josh: Overriding `Cargo.toml`? Is there a reason it needs to be permanently unstable? - check if too old of edition - migrate - validate migration worked - handle `cargo_features` - scott: Can you run specific migrations? - eric: Yea, all future edition changes will be in the "future" edition, everything disabled by default, and then enabled with `-Zcrate-attr=feature(...)` - scott: How does this work with Cargo's migrations? - eric: Uncertain, will need to think about that. - josh: Plase use a different name than `-Zedition` to make it clearer what it does. - eric: Yea, happy to figure out a better name. - eric: The flag also knows the start and end edition. - ed: Should `cargo fix` change the edition field. - arlo: Only cargo-fix - eric: yes - https://github.com/rust-lang/cargo/issues/12661 -- Integrate SLSA - ed: Close this, create individual issues for artifact tracking. - arlo: Not clear in the issue what they want. Would need a lot of research what other ecosystems are using it for, and how it could be integrated into cargo. - scott: What is the relation with other signing efforts? - conclusion: Will close, directing more towards something like an internals/rfc discussion process. - https://github.com/rust-lang/cargo/issues/12596 -- Introduce --all-features flag to cargo vendor - eric: Thinks this might be difficult to implement, because it wouldn't know which version to vendor, since it has to get that information from the resolver, but there solver doesn't have that ability. - arlo: Concerned that it is vendoring anything that is not in the lock file. - josh: Give some context on why this is difficult. - ed: There is a way to work around this (can create dummy workspace with all those feature), or with plumbing commands would have more flexibility to create a tool to vendor whatever they want. Nothing special about `cargo vendor` for doing something for this. Create a third-party tool for this need to iterate and get feedback. - Also `cargo add` vendoring things on the fly. That could also be another potential route. - See also https://github.com/rust-lang/cargo/issues/15019 - Arlo: Changing the meaning of `--all-features` could be confusing. - Conclusion: Close this with the above recommendations. - https://github.com/rust-lang/cargo/issues/8244 -- Non-hidden config - Related: https://github.com/pi0/config-dir (non-hidden support is rejected) - ed: Some tools use `_` instead of `.` (like static site generators). - arlo: Maybe not a good idea now (without a time travel machine). - josh: Can't make everyone happy. - josh: Find it a mild annoyance, would prefer them in `Cargo.toml`. Cost of searching more than one place is not worth changing it to look in two places. - ed: We do support `config` and `config.toml` today. - ed: config-include is another potential workaround - josh: Wonders about have a separate config that is only workspace-level. - ed: Don't know where the workspace is before loading config. - weihang: Can cause a lot of churn for other tools that load config (particularly since cargo doesn't provide a library for that). - Other tools: https://github.com/pi0/config-dir/discussions/6 - Migrating away from config: https://github.com/rust-lang/cargo/issues/12738 - conclusion: will close, particularly have other alternatives (and we really want to move things to `Cargo.toml` mostly). ## 2025-04-29 - FCP reminders: - https://github.com/rust-lang/cargo/pull/15192#issuecomment-2813079199 -- fix: default to all targets when using --edition and --edition-idioms in cargo fix - https://github.com/rust-lang/cargo/pull/15462#issuecomment-2837033111 -- Stabilize doctest-xcompile - https://github.com/rust-lang/cargo/issues/15422 -- cargo check builds a dependency shared by a proc macro and library twice - eric: should this be a close? - ed: pointing to sharing metadata between build and check - arlo: Are there problems of reusing the metadata? - jacob: That could use some conversation at all hands? - josh: wonder if rustc could output an indication of getting past the `check` step, and be niced to a lower priority after metadata had been generated (and cargo could suppress the output if undesired, but have it cached for the next `cargo build`). - epage: host/target sharing? - ehuss: yes, we're at things being too complex and been moving away from sharing - conclusion: will close in favor of #3501 - https://github.com/rust-lang/cargo/issues/15210 -- Add doc comments and doctests to lib.rs generated by cargo init - weihang: This by itself seems good, but recognizes adding more can be an issue. - ed: The more you add is more that you need to delete. - josh: partly agree, but today we have a whole test module as doing a unit test as a separate function which is useful. The net result of a doctest might be simpler compared to the unittest module block. - jacob: How we teach rust might not be in our purview? - arlo: Would like to avoid adding more stuff to generate. Sympathetic to adding doctest. - josh: For me, deleting more doesn't change the number of keystrokes to delete. - ed: Thinking about test performances, moving tests out to a separate file can improve build-time, which reduces recompilations. - josh: Concerns about out-of-sight out-of-mind issues with people uploading crates with unused `test` modules. All a matter of taste on how to organize (in directories, etc.). - josh: A separate module and unittests is normally done for functions that are more complicated, where a doctest can cover simple functions like `add` sufficiently. - ed: The proposed code is broken. - eric: Feels uncomfortable that this will require substitutions, and won't survive crate renames. - eric: concerns about where do we stop? Like crate-level comment? Other Rust things to illustrate? - weihang: Keep it under one screenfull. - ed: What terminal size do we shoot by default? What is one screen? Please share with me if you have thoughts. - Just buy everyone bigger monitors. - josh: Dynamically check the terminal size. (Talking about `cargo add` feature list.) - josh: Of course there are arguments about scrolling the screen, and how much a human can consume. - https://github.com/rust-lang/cargo/issues/14007 -- also `?` compatibility - arlo: What about bin template, and `?` support? - ed: Slightly different topic. - ed: Some concern that `Err` from main presentation shows Debug is not acceptable for a program. - josh: Feels that `Debug` is fine for some use cases. Agrees that we shouldn't be doing a `Box<Error>`. Defer to something better in the standard library. - ed: Ok to to close https://github.com/rust-lang/cargo/issues/14007? - arlo: Sympathetic to users using `?` getting a bad error message. - ed: Have opened issue to improve that error. - Ed will close https://github.com/rust-lang/cargo/issues/14007 - ed will reach out to people who do rust training/education to solicit their feedback about what might be helpful. - https://github.com/rust-lang/cargo/issues/13137 -- Pin cache entries still in use - ed: Might add too much runtime cost/complexity. - jacob: Being configurable. Example of removable drives. - josh: Likes the idea. - ed: Parsing all lock files could be a performance hit. - jacob: How far along is the tracking of `Cargo.lock` locations? - ed: There is a PR open, but it needs some work. - josh: Is there a trust concern about parsing lock files? For example, put a lock file in tmp, and then delete it, and then another user places a lock file there. - ed: For now, this would only affect how long cache entries are kept. - josh: Probably want to be cautious if we do more with Cargo.lock. - scott: Is there a way to explicitly say something should be kept around? - Not really other than turning it off. - There are unstable config options. - arlo: Not entirely convinced that the complexity/performance impact is worth it. If you are working on a project, it keeps the entries around. - josh: If you regularly update rust every new release (but otherwise only do rust stuff only every few months), the build directory will get blown away each time, so you are already incurring that performance hit. - jacob: Could construct histogram of successful cargo builds, and could use the distribution to determine how long to keep things around. - ed: Could talk to Jane regarding those kinds of metrics. ## 2025-04-22 - FCP reminder: https://github.com/rust-lang/cargo/pull/15192#issuecomment-2813079199 -- changes default targets of `cargo fix` - cfg boolean literals: https://github.com/rust-lang/cargo/pull/14649 - Any concerns? - Agreed that we are essentially mirroring what the compiler is doing, and they already approved FCP. - Ed will do a final check and merge. - `-Zgc`: Using `atime` for being more resilient with older cargoes. - https://github.com/rust-lang/cargo/pull/14287#issuecomment-2801415029 - `-Zgc` is about to stabilize (already went through 10-day FCP) - ed: Doesn't want to block. Maybe defer cleaning up the things cargo didn't download, but there was a response to that. Two lockfile setup is deprioritized (in terms of supporting old independent locks). Can also be disabled. Disruption is redownload every three months. - josh: Also doesn't want to block. - No specific objections to moving forward. - ed: volunteers to write a response before merging. - arlo: Are there any specific objections to atime in the future? - There are some technical concerns that we likely wouldn't adopt it. - Planning to have the release notes specifically address what the consequences are, and how to disable it. - epage: Set `CARGO_BIN_EXE_` when running test binary - Currently, we set some metadata env variables at runtime but not `CARGO_BIN_EXE_`, only set at compile time - Cargo's tests can't use this right now because the binary name is looked up in a dep - `cargo-test-support` doesn't get the environment variable. - https://github.com/rust-lang/cargo/pull/7697 - eric can't remember why it was done that way. Will look after meeting, but nobody has concerns about moving forward if we can't find any reasons. - epage: Thoughts on RUSTFLAGS affecting lint levels? - At all hands, we'll be working with clippy, compiler, etc to finish fleshing out the design for Cargo's linting system - Getting a vibe check from others because I have my thoughts on Urgau has his own. - Options - No - Yes - Only to any lints we have in Rust's namespace - FYI other questions - The purpose of the rustc/clippy divide and how we should apply it to Cargo - What namespaces should Cargo inhabit - Everything under `cargo::` - Clippy-like under `clippy::` - When lints overlap with rustc, no namespace - What if one lint overlaps with rustc but a related lint doesn't? - arlo: Is this cargo parsing rustflags? - ed: No, cargo passes the flags to the compiler, and the compiler has a "print-lint-levels" flag that will tell us what the effective level is. - How does the compiler know about cargo lints? - josh: any examples shared with rustc that would affect cargo other than `-Dwarnings`? What specific ones? - ed: unexpected_cfgs is the primary one. There might be others like `deprecated`, or would there be an independent `cargo::deprecated`? `non_snake_case`, too (but then `cargo::non_kebab_case`? gets messy)? How much is a cohesive system versus individual independent tools? - josh: Round-tripping to rustc just to share a name seems convoluted. If you want them to affect cargo, it should be set in cargo. - josh: If setting a rust lint in cargo, and it obviously also applies to cargo, cargo can take advantage of (unless you independently override it in `cargo::`). - eric: Was the idea to only parse CLI flags, or to parse crate-level lints? - ed: CLI only - josh: we could catch `-Dwarnings` - ed: There's already a feature for that: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#warnings - arlo: Cargo's lint system should be sufficient for setting things. - Clarification: Do you mean runtime? Yea, probably needing some kind of runtime ability to set it. - Is that a blocker for cargo's lint system? Not a blocker, but something that we should support. - Arlo: Use case, compliance requirements for the entire graph, and want to be able to enforce that for the entire graph, without modifying every crate. - Would that also apply to `cargo::`? Unclear, don't know which ones would be required, but if we are to keep a unified system, then yes. - ed: There isn't a blocker in the sense that `cargo::` isn't able to be set at runtime today. Something we can address in the future. - scott: Other build tools ability to set cargo lints? - ed: Would also need to control cap-lints if you want to override the graph. - weihang: Can we use `-Zwarnings` for runtime controls? - conclusion: For RUSTFLAGS specifically, vibe check is that we didn't want to go that route. RUSTFLAGS is a low-level escape hatch, and we should probably just drive the definitions from cargo's lint table. - Improved handling of non-writable rlib/rmeta files - https://github.com/rust-lang/cargo/issues/12674 - Josh and ed will write up a response, 3 already has some plans, 1 has some specific aspects of cargo that chooses it to share, 2 is likely a `rustc` thing, and will transfer to rust-lang/rust to see if compiler team wants to help with that. ## 2025-04-15 - Reminder: FCP proposal for `http.proxy-cainfo`: https://github.com/rust-lang/cargo/pull/15374#issuecomment-2791032791 - Discussed if this really needs to be a separate configuation option, and will recommend that it uses cainfo instead. We can always separate them in the future if we need to. This is how the curl *cli* works, but not the API. - Using zlib-rs (~60% performance improvement) - https://github.com/rust-lang/cargo/pull/15417 - josh: May want to be ready for any problems with less common platforms. But this is easy to revert on beta if needed. - No concerns brought up. - Ed to review and merge. - Allow mutitple SemVer-compatible version with = exact requirement - https://github.com/rust-lang/cargo/issues/12787 - epage: user is trying to write cross-version tests - josh: As long as it only worked with exact `=` constraint. Just want to avoid the situation where you have "1.0" and "=1.0.1", or "1.2" and "=1.0.1". - ed: Seems complicated for both the user to understand, and the implementation (retrofitting the resolver). - jacob: Would need to be careful of the many edge cases, like for example writing the lockfile will need to ensure that the deps entries point to the correct version. - jacob: Where are you allowed to introduce these requirements? If it is anywhere in the tree, then it could introduce confusion, as opposed to having the root package be special. - Wonders if you can have multiple path dependencies with the same name/version. (yes you can) - arlo: would lean towards closing, fine either way. - Another workaround is to use multiple path dependencies. - conclusion: Will leave open, but not accept at this time, and leave a comment with some of our thoughts. - `rustc --print-json` shape - <https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/rustc.20--print-json.20shape/> - Cargo heavily depends on `rustc --print` to probe information like output artifact prefix/suffix, supported crate-types, and more. - weihang: Will likely need more support for adding more complex output information for example getting library prefix/suffix information. This doesn't directly affect printing JSON, more to think about in the future. - Separate issue for how you tell the compiler whether to print json or text, exactly what the CLI flag looks like. - conclusion: Will let them know that we are all ok with the proposal. - Make `package.name` optional - https://github.com/rust-lang/cargo/issues/12689 - The recursive search in `git` dependencies, the root doesn't have a name, so that probably shouldn't be supported. - If there are enough exceptions with cargo-script, it may not be worth doing? - If the exceptions apply to both the cargo-script and non-cargo-script cases, this may still be simple. - jacob: What if we fully reject it as a dependency? - josh: We could initially reject it, and then decide to allow it in the future. Would need to have care for the recursive git search (it's found *here* to *error found mulitple*) - ed: Uncertain about having that exception, since if we have to document the caveats of being option, the user may be uncertain about why to do that. - ed: Sees some benefit to understand the issues that will affect cargo-script. - arlo: Feels weird about having the directory name affect how it is built. It seems OK if it is nested inside a version-controlled repo. - Ran out of time here, there was some uncertainty going either way. People noted it seemed like a reasonable motivation, but there was some uneasiness around some of the details. ## 2025-04-08 - (ehuss) `-Z embed-metadata` - https://github.com/rust-lang/cargo/pull/15378 - What to do about backwards compatibility? - had three ideas: - copy `.rmeta` to the target directory - don't copy `.rlib` to the top-level - make it a configuration option - josh: Could not pass it for the final library build. - Could be temporary, and then make a more drastic change later, after the option is stabilized. - weihang: multiple crate workspace might not have the benefit. - Perhaps cargo new should have a `[workspace]` tag? - https://github.com/rust-lang/cargo/issues/12998 - epage: would block our auto-inherit, auto-member behavior - epage: could do detection on first run and then add `[workspace]` - Alt: I've wanted a `package.workspace = <bool>` (not just path) for controlling discovery. could do `package.workspace = false` - arlo: This seems like documentation, as users may not need a workspace. - scott: Could have some complexity with automated workspace inheritence. - eric: Wonders if `cargo new` could print something indicating it was added to a workspace. - josh: Also feels like printing something, with a link to workspace information. - weihang: We already have that message. - scott: Having a flag for `[workspace]` still seems like something to explore. - conclusion: Will close, as we don't think we want this to be the default behavior. We may have more to explore with options, or better information or diagnostics. - `cargo install` should respect `[patch]` from user config - https://github.com/rust-lang/cargo/issues/12855 - epage: surprised it doesn't - epage: however, could have really weird affect on local development, almost seems like we should have a `cargo install` specific config - Conclusion: Seems like this should be working. May need a little investigation why it isn't. - Make `package.name` optional - https://github.com/rust-lang/cargo/issues/12689 - epage: mostly the motivation is to unify `Cargo.toml` / cargo script - epage: can also reduce boiletplate in workspaces - josh: seems reasonable - rustin: what happens if you rename the parent directory? - scott: If you depend on a package, it should have a name. It feels odd. - josh: why add a restriction? - arlo: this could affect git dependencies due to the recursive search. - eric: thinks it would just use the directory name? - Oh, if it is at the root of the git repo, there is no directory name. - weihang: adding more restrictions conflicts with the motivation to remove excpetions and documentation. - arlo: If we're uncomfortable with this, then maybe supporting it entirely isn't worth it. - arlo: What if you symlink, which one does it use? - josh: Should not be publishable. - just like not specifying a version. - josh: and don't change the behavior of `cargo new` - scott: Doesn't feel like this removes much boilerplate. ## 2025-04-01 - epage: `-Zembed-metadata`, see https://github.com/rust-lang/rust/pull/137535 - epage: instead of duplicating `rmeta` inside `rlib`, the intention is to only use `rmeta` - epage: savings seem to be negligable, unsure why Jakob is pushing it - epage: unsure on final interface but main risk I identified is with users grabbing our rlibs and doing stuff with them manually, not knowing they need to also grab rmeta (or maybe also specify them on the command-line? again, unsure if that was required) - josh: Why not remove rmeta? - This is required for pipelined builds, so that dependencies can start building as soon as the rmeta is available. - jacob: If you are mucking with the internals of the target directory, that's a hazard. - josh: If other build systems do not know they also need rmeta, then that could be a compatibility break. - epage: We could put the rmeta in the rlib for the final artifact, and just not the intermediate artifacts. - josh: Intermediate artifacts don't count. There will presumably be a separate flag for omitting the rmeta from the rlib, and we wouldn't use that on the final artifact, and other build systems wouldn't use that new flg at all so they wouldn't be affected. - Jacob: Could have an environment variable or something as a temporary escape hatch. - epage: should `cargo vendor` include `Cargo.toml.orig`? - `document-features` wants it to read the comments - See https://github.com/rust-lang/cargo/issues/13191 - ed: Unfortunately `vendor` uses the publish logic out of the `.crate` file so `Cargo.toml.orig` would be what was previously stripped. Could block on vendoring the original `.crate`. - ehuss: ideally, copy over orignal `.crate` - arlo: overall original request seems reasonable, as long as it isn't too horrible (to extract `.crate`). Just wants to avoid lots of hacks to plumb things through. - ed: git dependencies would need special support, too. - conclusion: The request seems reasonable to us, but not entirely certain about the level of work needed for the implementation. - Allow profiles to set `-Cforce-frame-pointers` - https://github.com/rust-lang/cargo/issues/15333 - eric: Don't recall conversations about guidance for choosing to add codegen options to profiles. - epage: kornel talked about pain of adding: https://internals.rust-lang.org/t/the-burden-of-creating-new-compiler-options-and-exposing-them-in-cargo/22101 - josh: Some codegen options we may never want to add (like affecting ABI, or conflicts with precompiled std) - This option is useful for debugging. - jacob: Can this be on by default for debug, and uncertain about release. - ed: This request is specifically for profiling. - What about the bench profile? - josh: Probably wouldn't want bench profile to differ from release like that; that could affect the suitability of the bench profile for accurate benchmarking. - jacob: Some small things can insta-stable - ed: Would need to have a handshake with t-compiler to understand the effects. - jacob: Could rfcbot confirm with them. - jacob: Maybe talk to them at all-hands on how to better communicate those things? - conclusion: Eric will try to capture the start of a policy, and indicate this would be accepted (noted we need an option for "default"). - Support tag/branch & rev at the same time for git dependencies - https://github.com/rust-lang/cargo/issues/13142 - Wants `rev` to pin to a specific revision, but also keep `tag` for human consumption. - epage: would we vaidate that the `tag` points to the `rev`? - epage: how would be treat `branch` and `rev`? Ignore the `branch`? If so, seems like a comment would work just as well and wouldn't convey any unintended meaning - epage: are we ok only supporting specific combinations? - scott: Concern around mutability - ed: Could check that tag and rev match each other. - If not checked, how is this different from a comment? - eric: Slight -1 on this, as this seems like a recipe for confusion when they get out of sync, or trying to keep them in sync. - josh: If you specify both tag/rev, error if they diverge. - Unless we have a notion to have a branch reference a particular rev ("does it contain" or "is it exactly"), then don't allow combining branch/rev. - arlo: How often to validate? - jacob: Whenever we fetch? - eric: Didn't quite understand, we already link tag and rev in manifest/lockfile. - Author had concerns about using git libraries at a dependency (which don't use lock), and also not seeing lockfile during review. - Why not just use `tag`? - Some use `rev` for "security reasons" - josh: Only thing I would push back against is doing this and not validating it. - conclusion: Eric will close with message. - Always set `MACOSX_DEPLOYMENT_TARGET` in build scripts - https://github.com/rust-lang/cargo/issues/13115 - scott: Can this move to our build script crate? - ed: Would want to hear, is it sufficient for the answer cargo would be giving? Is there one right answer, or are there other subtlities? - eric: Unfortunately don't have a lot of mac maintainers (issue author is the primary one). - arlo: If we get it wrong, it is harder to fix, whereas `cc` can get new releases at any time. - scott: is adding this a breaking change to non`cc` users? - arlo: Creeping `cc` into cargo (with the intent of compiling C code). - ed: And not all build scripts do compilation. - ed: Putting too much in that people might not use. - arlo: Tighter integration with something like metabuild could help make it easier to use and expose. - conclusion: Didn't have appetite for putting this in cargo itself, though we didn't have a specific consensus. Probably lean on external crates or support in some way for now.