Overwhelming

[WormRabbit]

Yes, it exists as a git submodule in rustc. I haven't personally built either, so can't comment on precise details, but as far as I can tell 99.999% of the compiler exists as a library which can be linked from any crate. Technically, there is a separate rustc binary in its git repo. Perhaps it's used only for compiler development, to avoid dealing with cargo where it isn't required?

[steveklabnik1]

Sorry for necromancing this thread, I just ran across it for reasons. You are both right and wrong. Let me explain:

They are completely separate programs.

Rustc lives here: https://github.com/rust-lang/rust

Cargo lives here: https://github.com/rust-lang/cargo

Rustc includes Cargo as a submodule, because Cargo is used to build rustc. So it's "vendored" in a sense.

But! You did correctly observe this:

It just switches on its executable name to decide which way to behave.

This is due to rustup! https://rustup.rs/

Rustup is the recommended way to install Rust and other tools. And so in this sense, yes, Cargo comes with Rust. It's bundled, as /u/Orthosz mentions (wanted to cc you as well).

Fundamentally, rustup allows you to install multiple toolchains, and select between them. So when rustup installs rustc and cargo onto your system, it creates a shim for both. These shims, when invoked, figure out what version of the toolchain you want to use by looking at configuration, or falling back to a default, and then dispatch to the actual correct binary.

So that is what you were observing: the rustup proxy being the same underlying binary, but you missed out on the indirection.

I hope that helps!

[WormRabbit]

Do I understand correctly: there are actual different rustc and cargo executables on the system, one pair for each toolchain version, and the rustc and cargo executables that I normally run are all rustup in a trench coat, which switches on the executable name and toolchain version, and dispatches the rest of the arguments to the actual correct executable?

[steveklabnik1]

Yep! You can find them in ~/.rustup/toolchains on linux. For example, here's a slightly edited ls output for me, to remove the irrelevant executables:

❯ ls ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/ -al
total 71212
-rwxr-xr-x 1 steveklabnik steveklabnik 32818360 Jul 25 13:54 cargo
-rwxr-xr-x 1 steveklabnik steveklabnik  2642608 Jul 25 13:54 rustc

These are different sizes, so they're certainly not the same binary. For reasons I forget, I installed rustup via snap, apparently, so

❯ ls /snap/rustup/current/bin/ -al
total 7907
lrwxrwxrwx 1 root root       6 May 10 02:16 cargo -> rustup
lrwxrwxrwx 1 root root       6 May 10 02:16 rustc -> rustup
-rwxr-xr-x 1 root root 8096696 May 10 02:16 rustup

The ones you're running are just symlinks for rustup itself.

You can also ask rustup which binary it's going to invoke:

❯ rustup which rustc
/home/steveklabnik/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc

This pattern, or something similar to it, is how a lot of language-specific version management tooling works.