Consider building rust with Cargo #16091
Comments
|
Indeed it might be P-low but I'm really excited to think of building rustc with cargo. 😄 |
|
Extracting rustc from |
|
The dependency graph would be equally complicated (likely unchanged), just spread over several repositories. I find it likely that splitting rustc into a separate repository while still doing lots of breaking & generally major changes as we are now would be a recipe for significant pain. |
|
@huonw I was referring to this repository's dependency graph. Naturally the global situation would be unchanged. Disentangling rustc from rust is probably important in the long run, since rustc depends on several extra libraries outside the standard library (e.g. graphviz) that should not necessarily be versioned with the language. One difficulty that comes to mind is ensuring that the latest rustc is compatible with the latest rust, but this is manageable with continuous integration. And having |
|
I'm not exactly sure why simplifying the dependency graph of a single repository is valuable, when the overall dependency graph of the officially supported crates is not changing; splitting it across many repositories just makes it harder to reason about, since it's now completely spread out. (My only point is we should not be looking at this from the point-of-view of repositories' dependency graphs; just focus on whatever other benefits it gives.)
It's not immediately obvious that it's easy; we'd certainly need to enhance bors significantly, and people submitting changes may need to submit and keep track of pull requests to upto n different repositories with them all reviewed and ready to merge at once (i.e. bors would have to collect all associated PRs together to land in one go... we'd even need a way to associate them reliably, both for bors and for historical purposes in the commit log). |
steveklabnik
added
the
C-enhancement
|
@alexcrichton can you give us an update on the efforts to get this done? Some stuff flared up in the summer, but I dunno what came of it. |
|
I don't think all of the limitations in Cargo (whichever these were) were addressed since then. Specifically, the PR depended on rust-lang/cargo#1802. |
|
In addition to the links that @jonas-schievink I'm also working on this on an external branch. My current stance is that I would like to avoid two build systems at all costs, so the only way to land this would be to entirely obsolete the current build system, which is taking some time to do :). |
|
Done! rustbuild is tracked here -- #31590 |
…ykril fix: self type replacement in inline-function Fix rust-lang#16113, fix rust-lang#16091 The problem described in this issue actually involves three bugs. Firstly, when using `ted` to modify the syntax tree, the offset of nodes on the tree changes, which causes the syntax range information from `hir` to become invalid. Therefore, we need to edit the AST after the last usage for `usages_for_locals`. The second issue is that when inserting nodes, it's necessary to use `clone_subtree` for duplication because the `ted::replace` operation essentially moves a node. The third issue is that we should use `ancestors_with_macros` instead of `ancestors` to handle impl definition in macros. I have fixed the three bugs mentioned above and added unit tests.
In #2237 it was resolved to rewrite the build system in Rust, but that never ended up happening. It was later decided that we should build Rust with rustpkg, but that also ended up not happening. As a natural continuation of said issue we should consider building Rust with Cargo.
There are certainly some difficulties in doing this, some of which I can think of are:
This is most certainly a low priority issue, I believe building servo with Cargo to be a better milestone than building Rust.
The text was updated successfully, but these errors were encountered: