bors [Thu, 29 Jun 2017 01:01:27 +0000 (01:01 +0000)]
Auto merge of #4234 - michaelwoerister:smarter-cargo-incremental-2, r=alexcrichton
Set -Ccodegen-units=N for non-path dependencies when CARGO_INCREMENTAL is set.
This PR tweaks compilation for non-path dependencies when CARGO_INCREMENTAL is set. Before, `cargo` would compile such dependencies "just" non-incrementally while, with this PR, it will also set the number of CGUs to the number of CPU cores. Otherwise compiling those dependencies might take significantly longer (because of more expensive optimizations and less multi-threading) than compiling them incrementally -- which is what we wanted to avoid in the first place.
bors [Wed, 28 Jun 2017 06:39:50 +0000 (06:39 +0000)]
Auto merge of #4229 - azerupi:install-version-range, r=matklad
Implement semver ranges for install --vers
This implements the design discussed in #4207
It allows to specify semver ranges on `cargo install ... --vers`
1. The first character of the `--vers` value is checked, if there is none we return an error.
2. If it is one of `<`, `>`, `=`, `^`, `~` we parse the value as a `VersionReq`, otherwise we parse it as a `Version`.
3. If the parsing as a `Version` fails but parsing as `VersionReq` succeeds, we add a note to the warning mentioning that a qualifier should be used to specify a semver range. This catches versions with less than tree digits.
Otherwise, the previous behaviour is preserved with the warning of backwards compatibility.
This means that
- `cargo install ... --vers "^1.2.3"` will be parsed as a range
- `cargo install ... --vers 1.2.3` will be parsed as a version
- `cargo install ... --vers 1.2` will be parsed as a version for backwards compatibility reasons, fail and be passed through as is,**but** we will add a note `if you want to specify semver range, add an explicit qualifier, like ^1.2`
- `cargo install ... --vers blah` will be parsed as a version for backwards compatibility reasons (which is weird because it is not even a valid semver range) and produce an `unknown error` down the line. I have left this behaviour untouched because it worked like that before, but I can easily make it error sooner with a better message.
bors [Tue, 27 Jun 2017 00:42:29 +0000 (00:42 +0000)]
Auto merge of #4230 - Mark-Simulacrum:double-print, r=alexcrichton
Prevent rustc stderr/stdout from being duplicated.
Please review carefully. I've not submitted patches to Cargo before, I think, so this may be flawed in some way I haven't detected yet. Tests are green locally, though.
bors [Sat, 24 Jun 2017 04:24:55 +0000 (04:24 +0000)]
Auto merge of #4209 - natboehm:add-index-flag, r=alexcrichton
Replace `cargo publish --host` with `cargo publish --index`
This change makes the command consistent with other versions with the same flag. `cargo publish --host` is still supported, currently marked as deprecated, or for reuse as mentioned in issue #4208.
bors [Mon, 19 Jun 2017 14:09:30 +0000 (14:09 +0000)]
Auto merge of #4181 - gilescope:patch-1, r=alexcrichton
Make test less brittle prior to assert_eq failure message format change
PR required for rust-lang/rust#42541 to make assert_eq error message be multi-line. Before implementing this we need to make the current test less brittle.
Not 100% clear on if I need the final [...] or not.
bors [Thu, 15 Jun 2017 17:52:42 +0000 (17:52 +0000)]
Auto merge of #4125 - alexcrichton:rerun-if-env-changed, r=matklad
Implement `cargo:rerun-if-env-changed=FOO`
This commit implements a new method of rerunning a build script if an
environment variable changes. Environment variables are one of the primary
methods of giving inputs to a build script today, and this'll help situations
where if you change an env var you don't have to remember to clean out an old
build directory to ensure fresh results.
Alex Crichton [Mon, 5 Jun 2017 14:52:31 +0000 (07:52 -0700)]
Implement `cargo:rerun-if-env-changed=FOO`
This commit implements a new method of rerunning a build script if an
environment variable changes. Environment variables are one of the primary
methods of giving inputs to a build script today, and this'll help situations
where if you change an env var you don't have to remember to clean out an old
build directory to ensure fresh results.
bors [Wed, 14 Jun 2017 18:19:17 +0000 (18:19 +0000)]
Auto merge of #4168 - alexcrichton:more-metadata, r=alexcrichton
Hash `Kind` in metadata for crates
This fixes what is now a bug in Cargo discovered when attempting to land
rust-lang/rust#42495 where Cargo will compile both host and target artifacts
with the same `-C metadata` flag. This means that the compile can load two
crates with the same SVH that are supposed to be distinct, which causes weird
bugs with crate loading and whatnot.
This commit throws in the `Kind` into the metadata calculation to resolve this
to ensure that host/target artifacts always have a different `-C metadata`
Alex Crichton [Wed, 14 Jun 2017 18:16:24 +0000 (11:16 -0700)]
Hash `Kind` in metadata for crates
This fixes what is now a bug in Cargo discovered when attempting to land
rust-lang/rust#42495 where Cargo will compile both host and target artifacts
with the same `-C metadata` flag. This means that the compile can load two
crates with the same SVH that are supposed to be distinct, which causes weird
bugs with crate loading and whatnot.
This commit throws in the `Kind` into the metadata calculation to resolve this
to ensure that host/target artifacts always have a different `-C metadata`
bors [Wed, 14 Jun 2017 09:57:12 +0000 (09:57 +0000)]
Auto merge of #4162 - alexcrichton:termcolor, r=matklad
Migrate from the `term` crate to `termcolor`
The API of `termcolor` fits what the system gives us much more nicely and should
be well battle-tested from ripgrep. Additionally we don't really need huge
terminfo parsers, that wasn't every really the intention of the color support
here.
bors [Wed, 14 Jun 2017 03:33:46 +0000 (03:33 +0000)]
Auto merge of #4155 - ketralnis:fossil, r=alexcrichton
Add fossil VCS support to `cargo new`
Fossil is a simple, high-reliability, distributed software configuration management system <https://www.fossil-scm.org/>
I mostly followed https://github.com/rust-lang/cargo/pull/3842 as a template. Like that one, this only adds support for `cargo new`, not for pulling down fossil-hosted dependencies
A problem that i didn't tackle but I'd be willing to is a little more more `trait`ifying of the VCSs. I would need some guidance on that since it looks like git has some more thorough support than e.g. hg does but it looks pretty doable
bors [Wed, 14 Jun 2017 03:01:33 +0000 (03:01 +0000)]
Auto merge of #4159 - matklad:arch, r=alexcrichton
Blurb about Cargo inner workings
Hi!
At today's dev tools meetings we've discussed how we can foster contributions to rust dev tools, and I've complained that some tools are difficult to contribute to because it's difficult to learn how they work because there are no docs, and some other people complained that Cargo is difficult to contribute to because it is rather complex. And, as a member of Cargo team, I thought that I am probably responsible for fixing that :)
So, here's my take at making it easier to dive in into Cargo! I've written a small birds eye overview of the current architecture of Cargo (more like a list of things to look at while reading the code actually :)
In general, I am skeptical about documenting internals of binaries (docs will become obsolete, and very fast), but such a high level picture should be pretty robust (I deliberately avoided linking to the actual source code), and so pretty low-effort to maintain. We do something similar for IntelliJ Rust: https://github.com/intellij-rust/intellij-rust/blob/master/ARCHITECTURE.md as well.
Alex Crichton [Thu, 8 Jun 2017 22:09:04 +0000 (15:09 -0700)]
Migrate from the `term` crate to `termcolor`
The API of `termcolor` fits what the system gives us much more nicely and should
be well battle-tested from ripgrep. Additionally we don't really need huge
terminfo parsers, that wasn't every really the intention of the color support
here.
bors [Tue, 13 Jun 2017 19:18:49 +0000 (19:18 +0000)]
Auto merge of #3978 - dethoter:separated-credentials, r=alexcrichton
Move API token into the separate file.
Fix of #3748. BTW, it's not clear what to do with old config.
Should I add a check for old config and try to remove [repository.token] field from it every time user add a new token?
Or should I just prefer to use a token field from a new config over the old one?
bors [Mon, 5 Jun 2017 14:49:59 +0000 (14:49 +0000)]
Auto merge of #4118 - alexcrichton:hamt, r=matklad
Optimize a slew of Cargo internals
Cargo has historically had very little optimization applied to it. Despite that it's pretty speedy today but there's always a desire to be faster! I've noticed Cargo being particularly sluggish on projects like Servo and rust-lang/rust, so I started profiling and found quite a few low-hanging fruit!
This PR is a slew of optimizations across Cargo for various things found here and there. The banner optimizations are:
* Resolution with a lock file should be basically a noop in terms of execution time now. An optimization was done to avoid cloning `Context` unless necessary, and that basically means it doesn't get cloned now! As the number 1 source of slowdown in Cargo this is the biggest improvement.
* Lots of pieces in `resolve` are now `Rc<T>` for being more easily cloneable.
* `Summary` now internally contains an `Rc` like `Dependency`, making it much more quickly cloneable.
* `Registry` as a trait no longer returns a `Vec` but rather takes a closure to yield summaries up, removing lots of intermediate arrays.
* We no longer spawn a thread for all units of "fresh work", only when we're about to spawn a process.
Almost everything here was guided through profiling `./x.py build` on rust-lang/rust or `cargo build -p log` on Servo. Both of these stress "noop resolution" and the former also stresses noop builds.
Runs of `./x.py build` dropped from 4 to 2 seconds (with lots of low-hanging fruit still remaining in Cargo itself) and `cargo build -p log` dropped from 1.5s to 0.3s. Massif graphs showing Cargo's memory usage also show that the peak memory usage of Cargo in a noop build of Servo dropped from 300MB to 30MB during resolution.
I'm hoping that none of these optimizations makes the code less readable and/or understandable. There are no algorithmic improvements in this PR other than those transitively picked up by making clones cheaper and/or allocating less.
projects / cargo.git / log