remove clones made redundant by Intern SourceId
This is a follow up to #6342. I used clippy to find all the places we called `.clone()` on a `SourceId` or where we passed `&SourceId`. This also involved fixing a large number of other things clippy was complaining about, and running `fmt` on a large number of files.
Tweak Layout to allow for non json file targets with internal "."
Per @alexcrichton 's comment in https://github.com/rust-lang/rust/pull/55041#issuecomment-431363683, currently cargo assumes that a target with an internal `.` is a custom json target spec, using the file stem for the build directory name.
This PR changes cargo to only use the file stem for files with a `json` extension.
Persistent data structures by im-rs
There has been a long standing "TODO: We should switch to persistent hash maps if we can" in the resolver. This PR introduces a dependency on [im-rs](https://github.com/bodil/im-rs/issues/26) to provide persistent hash maps. It then uses `im_rc::OrdSet` to store the priority list of dependencies, instead of `std::BinaryHeap`, as cloning the `Heap` was one of the most expensive things we did. In Big O terms these changes are very big wins, in practice the improvement is small. This is do to a number of factors like, `std::collections` are very fast, N is usually only in the hundreds, we only clone when the borrow checker insists on it, and we use `RC` and other tricks to avoid cloning.
I would advocate that we accept this PR, as:
- Things are only going to get more complicated in the future. It would be nice to have Big O on our side.
- When developing a new feature finding each place to add `RC` should be an afterthought not absolutely required before merge. (cc #6129 witch is stuck on this kind of per tick performance problem as well as other things).
- As the code gets more complex, making sure we never break any of the tricks becomes harder. It would be easier to work on this if such mistakes are marginal instead of show stoppers. (cc #5130 a bug report of one of these bing removed and affecting `./x.py build` enough to trigger an investigation).
- The resolver is already very complicated with a lot of moving parts to keep in your head at the same time, this will only get worse as we add features. There are a long list of tricks that are *critical* before and `~5%` after, it would be nice to consider if each one is worth the code complexity. (I can list some of the ones I have tried to remove but are still small wins, if that would help the discussion).
Overall, I think it is worth doing now, but can see that if is not a slam dunk.
Move command prelude into main library
When writing cargo sub-commands, it would be really useful to have access to these pre-built command line argument creates/parsers.
In a perfect world, I'd also move the contents of `src/bin/cargo/{cli.rs, main.rs, command/mod.rs}` that aren't specific to the built-in commands, but that's more complicated than this simple move of a module.
Add `c` alias for `check`
This PR adds `cargo c` alias for `cargo check`.
I believe that one of the most frequently used subcommands is `check`.
Adding this alias would save much time.
Currently, there are three aliases: `b` for `build`, `r` for `run`, `t` for `test`.
I think that adding out-of-the-box `c` alias is *natural* for many developers, and these aliases would cover most of the use cases.
We can add aliases via a configuration file, but I guess people would expect built-in `c` alias along with `b` and others.
One problem I have come up with is that the `clean` subcommand also starts with the letter `c`.
But I believe that running `check` subcommand by mistake would not hurt developers so much.
Fixes#6215
Allow user aliases to override built-in aliases
This PR allows user-defined aliases take precedence over built-in ones, with a warning that tells there exists a built-in alias.
This PR does not allow user aliases override built-in subcommands.
```console
$ cat .cargo/config
[alias]
b = "fetch"
build = "fetch"
$ ./target/debug/cargo b
warning: user-defined alias `b` overrides a built-in alias for `build`
$ ./target/debug/cargo build
warning: user-defined alias `build` is ignored, because it is shadowed by a built-in command
Compiling proc-macro2 v0.4.19
Compiling unicode-xid v0.1.0
Compiling cc v1.0.25
(snip)
```
In the current version of Cargo, user aliases cannot override built-in aliases.
This behavior is keeping us from safely adding new built-in aliases without interfering existing user config.
Merging this PR will allow that.
Fixes#6221
Relating to #6218
Fix renaming directory project using build scripts with cross-compiling.
The rename-protection introduced in #4818 checks for paths with a prefix of `/…/target/debug`, but this does not work for paths used during cross-compiling.
This change checks for paths with the full `OUT_DIR` prefix, and the `build/PKG/root-output` file now includes that full `OUT_DIR` instead of `/…/target/debug`.
This also includes a few other changes:
- Support fixing KIND=PATH style paths.
- Support fixing paths in metadata (like `cargo:root=…` or `cargo:include=…` which are common).
- Adds a "version" value to the metadata hash to ensure that cargo doesn't get confused with the new `root-output` file format.
Fixes#6177
Fix add_plugin_deps-related tests.
These tests were modified in #3974 in such a way that they stopped testing the `add_plugin_deps` code path. The tests can't be directly reverted because #3651 changed it so that dylib paths must be within the root output directory. I compromised by just copying the dylib into `$OUT_DIR`.
Closes#6318.
Stabilize the `rename-dependency` feature
This commit stabilizes Cargo's `rename-dependency` feature which allows
renaming packages in `Cargo.toml`, enabling importing multiple versions
of a single crate or simply avoiding a `use foo as bar` in `src/lib.rs`.
Closes#5653
