Add an alias from cargo x to cargo run --

[Rustin170506]

close #95858

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[jyn514]

I think this will interact poorly with vendoring:

rust/src/bootstrap/bootstrap.py

Lines 1187 to 1206 in 52ca603

	if self.use_vendored_sources:
	config = ("[source.crates-io]\n"
	"replace-with = 'vendored-sources'\n"
	"registry = 'https://example.com'\n"
	"\n"
	"[source.vendored-sources]\n"
	"directory = '{}/vendor'\n"
	.format(self.rust_root))
	if not os.path.exists('.cargo'):
	os.makedirs('.cargo')
	with output('.cargo/config') as cargo_config:
	cargo_config.write(config)
	else:
	print('info: using vendored source, but .cargo/config is already present.')
	print(' Reusing the current configuration file. But you may want to '
	'configure vendoring like this:')
	print(config)
	else:
	if os.path.exists('.cargo'):
	shutil.rmtree('.cargo')

maybe we can change that check to see if .cargo/config differs from the default? and remove the rmtree(.cargo) call?

[Mark-Simulacrum]

I am not sure this is really worth it -- do we think that the long-term expectation for user interface is cargo x build?

I think it might be worth holding off on a change like this PR until we have a clearer story around cargo run -- working and an expectation that users should migrate to it. I'm not sure we're there yet, though there's definitely a relatively happy path to getting there I expect.

For example, for cargo test, I think there may be a pretty clear path to that running the bootstrap process and passing off any arguments as today's arguments to x.py test. cargo fmt seems like it should be largely in a similar place of 'works out of the box' with some work (perhaps upstream to it as a tool).

For doc, build, and check, the story is more complicated -- honestly, mostly because all three lack a clear integration point for non-Cargo tools to step in. It's not clear to me yet what our goal here should be (e.g., we could push for rustbuild-specific features in Cargo, but I think no one is a fan of that trajectory). Maybe there's a general integration point -- similar to https://github.com/matklad/cargo-xtask/, but without .cargo/config.toml modifications which feel to me like somewhat of an anti-pattern (it's sort of a user, not upstream file, it seems to me).

It might be that we push for ability to declare aliased commands from Cargo.toml, pointing to subcrates in the workspace explicitly, as an unstable feature. That could mean a natural path for xbuild/xdoc/xcheck and so on to work out of the box, for example, if you already have a local rustc sysroot. Features like that have stalled out historically, but I think given a strong use case and interested hands, it's not impossible we could add something quite limited and unstable, though likely hard.

[Mark-Simulacrum]

To elaborate a little on the .cargo/config.toml concern -- I think I recall hearing that some consumers of rustc tarballs and git trees generating or using that file to add their own settings (alongside the config.toml file from x.py), so I am hesitant to start expanding the amount of things we ourselves put in it as default. It's not insurmountable as a concern, but I think we're not at the point of knowing it's the right trajectory from my perspective.

[Rustin170506]

I think it might be worth holding off on a change like this PR until we have a clearer story around cargo run -- working and an expectation that users should migrate to it.

Close it for now.

[jyn514]

Replied here: #95858 (comment)

(but I do agree it makes sense to hold off until it's more clear where we want to end up with the entrypoint)