A Core Language for Cargo

1

I've long felt Cargo had a somewhat ad-hoc genesis, and while there has been good "clean up" work since, there has also been a steady stream of new ad-hoc small features that have been trying to put the whole endeavor on a firm foundation a somewhat satisfying task. Similarly, I think the lack of this clean-up work has been led to many different, sometimes contradictory, intuitions about Cargo in the community, making the discussion of new features/directions more difficult as syntax, semantics, pragmatics are all up for debate at once, in one intractable tangle. I've personally felt frustrated trying to discuss Stabilize Cargo's weak-dep-features and namespaced-features. by ehuss · Pull Request #3143 · rust-lang/rfcs · GitHub and Cargo feature migrations by Ericson2314 · Pull Request #3146 · rust-lang/rfcs · GitHub for these reasons, and would like to avoid that! :slight_smile:

Just as Rust has adopted MIR in the past, and Chalk in the precedent, to get a better grasp at certain long-standing issues and unlock possibilities, I think Cargo needs some "core languages" to do the same. I'm less concerned about Cargo's implementations actually using them, at least initially, then the design process, and the social process of synchronizing everyone's intuition.

I have tried to start the process with rust-rfcs/0000-cargo-feature-migrations.md at cargo-feature-migrations · Ericson2314/rust-rfcs · GitHub most of that should be "true" whether or not my particular proposal is adopted.

12 Likes
2

I think you could see the unit graph as the "core language" of cargo. AFAIK this is created after dependency resolution and records for each thing to compile (unit) how it can be compiled and which units it has as dependencies.

3

@bjorn3 That is a core language, and that is certainly an important one and one I value and like, but I think we need some pre-resolution too. If we think of resolution as a sort of compiler "pipeline stage", it's very natural that we would desire IRs before and after it.

The questions that have beguiled me as of late are pre-resolution, but certainly post-resolution ones are useful for e.g. converting Cargo-resolved plans to other build systems, which do I care a lot about too.

4

One of the hardest parts of design is the way it interacts with everything. A good abstraction can sometimes cut through that tangled mess and make some parts orthogonal. Cargo certainly has its fair share of tangled mess. If we find a clarifying new abstraction, that would be wonderful.

4 Likes
5

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.