Auto merge of #5353 - matklad:features, r=alexcrichton
New semantics for `--features` flag
Historically, feature-related flags like `--all-features`,
`--no-default-features` and `--features` operated on the *current*
package. That is, `cargo --package foo --feature feat` would activate
`feat` for the package at the current working directory, and not for the
`foo` package. `-Z package-features` flag implements the more obvious
semantics for this combination of flags. This changes behavior, and that
is why we want to start with an unstable opt-in. The changes are:
* `--feature` flag affects the selected package. It is an error to
specify `--feature` with more than a single `-p`, or with `-p` outside
workspace (the latter could work in theory, but would be hard to
implement).
* `--all-features` and `--no-default-features` affect all selected
packages, and not the one at cwd.
* The package in `cwd` is not implicitly enabled when doing feature
selection. That is, `cargo build -Z package-features -p foo` could
select *less* features for various packages than `cargo build -p foo`.
Historically, feature-related flags like `--all-features`,
`--no-default-features` and `--features` operated on the *current*
package. That is, `cargo --package foo --feature feat` would activate
`feat` for the package at the current working directory, and not for the
`foo` package. `-Z package-features` flag implements the more obvious
semantics for this combination of flags. This changes behavior, and that
is why we want to start with an unstable opt-in. The changes are:
* `--feature` flag affects the selected package. It is an error to
specify `--feature` with more than a single `-p`, or with `-p` outside
workspace (the latter could work in theory, but would be hard to
implement).
* `--all-features` and `--no-default-features` affect all selected
packages, and not the one at cwd.
* The package in `cwd` is not implicitly enabled when doing feature
selection. That is, `cargo build -Z package-features -p foo` could
select *less* features for various packages than `cargo build -p foo`.
Auto merge of #5348 - djc:resolve-target-specific, r=alexcrichton
Have compilation context info available earlier in the build process
Eventually, I hope this will allow us to ignore platform-specific dependencies when irrelevant for the current build earlier in the process. This should save on extraneous errors. As is, this seems like it already decreases coupling in the code base.
Auto merge of #5323 - matklad:document-good-stuff, r=alexcrichton
Document how to use Cargo's internal logging
I always forget the syntax for filtering by module, and I've learned about `CARGO_PROFILE` yesterday, so let's document these for other contributors as well :-)
Auto merge of #5318 - ehuss:unstable-docs, r=matklad
Add unstable documentation.
I kept most of these relatively brief with the intent that more complete
documentation would be added when a feature is stabilized. I did my best to be
accurate, but I am unfamiliar with most of these features, so please let me know
if anything should change.
@matklad: I didn't fully understand the use case for `minimal-versions`, so I
didn't say much about it. In particular, I didn't understand why one wouldn't
just use `~` or `=` semver requirements if you wanted to be careful about not
pulling in a newer version. When someone says "1.0", aren't they explicitly
saying they want a newer version (up to 2.0) if it's available? The example
in the RFC of switching a dependency to "=1.0" sounds like a breaking change
(essentially downgrading a dependency).
Eric Huss [Sat, 7 Apr 2018 21:11:07 +0000 (14:11 -0700)]
Add unstable documentation.
I kept most of these relatively brief with the intent that more complete
documentation would be added when a feature is stabilized. I did my best to be
accurate, but I am unfamiliar with most of these features, so please let me know
if anything should change.
@matklad: I didn't fully understand the use case for `minimal-versions`, so I
didn't say much about it. In particular, I didn't understand why one wouldn't
just use `~` or `=` semver requirements if you wanted to be careful about not
pulling in a newer version. When someone says "1.0", aren't they explicitly
saying they want a newer version (up to 2.0) if it's available? The example
in the RFC of switching a dependency to "=1.0" sounds like a breaking change
(essentially downgrading a dependency).
Auto merge of #5322 - matklad:correctly-use-unstable-options, r=alexcrichton
Properly use unstable options for out-dir
@alexcrichton how exactly are unstable CLI options supposed to be handled?
One can do `-Z unstable-options my-opt` (this is done for `registry`, and this pr uses the same approach for `out-dir`). Once can also do `-Z my-opt`. Doc comments say that `-Z my-opt=val` is also possible, but in reality it does not work.
This infra was inherited from `rustc`, which is a slightly different use-case, because it does not have subcommands. That is, if you do `-Z my-opt`, it is available for all subcommands, but does not show up in the help...
What do you think about having only `-Z unstable-options` to unlock all cli options? Or do we require a finer-graind granularity?
Somewhat related, we have a bunch of unstable options already... Do we have tracking issues for them, to know when the time comes to graduate them to stable?
Auto merge of #5319 - matklad:fix-profiler, r=Eh2406
Don't print profiling information twice
It's important to `.clear` the messages so that we don't print them
again for the next "profiling session". It might be argued that really
we should have a single "profiling session" for Cargo, but we don't at
the moment.
And, while we are at it, let's lock stdout as well, so that we won't
get confused when Cargo becomes multi-threaded and prints profiling info
from several threads simultaneously.
It's important to `.clear` the messages so that we don't print them
again for the next "profiling session". It might be argued that really
we should have a single "profiling session" for Cargo, but we don't at
the moment.
And, while we are at it, let's lock stdout as well, so that we won't
get confused when Cargo becomes multi-threaded and prints profiling info
from several threads simultaneously.
Auto merge of #5314 - matklad:need-more-time, r=alexcrichton
Try to measure all time it takes to compile code
As @killercup noticed on IRC, no-op build by Cargo takes as much as 300 ms (on stable, beta and nightly), which seems unreasonable. However, Cargo wrongly reports ` Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs`, and this might be the reason why we haven't noticed this before.
So let's try to measure time slightly better:
```
~/projects/rustraytracer master*
λ time cargo +stable build
Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
cargo +stable build 0.16s user 0.02s system 94% cpu 0.195 total
~/projects/rustraytracer master*
λ time $c build # Cargo with this patch applied
Finished dev [unoptimized + debuginfo] target(s) in 0.31 secs
$c build 0.30s user 0.02s system 96% cpu 0.330 total
```
Auto merge of #5307 - alexcrichton:another-fix, r=matklad
Fix another issue of poisoning too eagerly
This commit extends the fix in #5288 by moving the logic added farther up in the
loop over package dependencies. This means that we won't recursively look at
optional/dev path dependencies which aren't members of the workspace. This
should fix the new issue that came up in #5257
Alex Crichton [Fri, 6 Apr 2018 19:35:37 +0000 (12:35 -0700)]
Fix another issue of poisoning too eagerly
This commit extends the fix in #5288 by moving the logic added farther up in the
loop over package dependencies. This means that we won't recursively look at
optional/dev path dependencies which aren't members of the workspace. This
should fix the new issue that came up in #5257
Auto merge of #5302 - Eh2406:MoreRc, r=alexcrichton
use more Rc in the part of resolver that gets cloned a lot 2
This is the same idea as https://github.com/rust-lang/cargo/pull/5118, I was looking at a profile and noted that ~5% of our time was sent dropping `HashMap<PackageId, HashSet<InternedString>>`. A quick rg and I found the culprit, we are cloning the set of features for every new `Context`. With some Rc we are now just cloning for each time we insert.
To benchmark I commented out line https://github.com/rust-lang/cargo/blob/b9aa315158fe4d8d63672a49200401922ef7385d/src/cargo/core/resolver/mod.rs#L453
the smallest change to get https://github.com/rust-lang/cargo/issues/4810#issuecomment-357553286 not to solve instantly.
Before 17000000 ticks, 90s, 188.889 ticks/ms
After 17000000 ticks, 73s, 232.877 ticks/ms
Auto merge of #5280 - klausi:clippy-191-trvials, r=matklad
chore(clippy): Simplify minor stuff found by clippy
Executed clippy 0.0.191, fixed the trivial stuff.
Filed https://github.com/rust-lang-nursery/rust-clippy/issues/2615 for all the format_err!() false positives.
Auto merge of #5293 - Eh2406:InternMoreStrings, r=alexcrichton
Intern more strings
As pointed out in https://github.com/rust-lang/cargo/pull/5270#issuecomment-378372147, that clean up adds the mildly expensive `InternedString::new` to the hot path in the resolver.
The process of this PR is:
1. Find a `InternedString::new` in the hot path.
2. replace the argument of type `&str` that is passed along to `InternedString::new` with the type `InternedString`
3. add an `InternedString::new` to the callers until it type checked.
4. Repeat from step 1.
This stop if:
- It was traced back to something that was already an `InternedString`
- It was traced back to a `.to_string()` call
- It was in a persistent object creation
cc:
- @djc this is building on your work, I don't want to get in your way.
- @alexcrichton is this making things clearer and do you want to see a performance check?
Auto merge of #5270 - djc:feature-requirements, r=Eh2406
Introduce FeatureValue type to represent features table values
This is the next step towards #1286 (after #5258). The goal here is to have a central place in the code where feature strings are interpreted as (a) a feature, (b) a dependency or (c) a dependency/feature combo, and anchor that interpretation in the type system as an enum.
I've spent quite a bit of effort avoiding extra string allocations, complicating the code a bit; notice in particular the use of `Cow<str>` in `FeatureValue` variants, and the slight workaround in `Context::resolve_features()` and `build_requirements()`. I hope this is all okay.
Auto merge of #5288 - alexcrichton:another-fix, r=matklad
Less aggressively poison sources on builds
Discovered in #5257 the changes in #5215 were slightly too aggressively
poisoning sources to require updates, thinking that a manifest changed when it
actually hadn't.
Non-workspace-member path dependencies with optional/dev-dependencies
don't show up in the lock file, so the previous logic would recognize this and
think that the dependency missing from the lock file was just added and would
require a registry update.
The fix in this commit effectively just skips all of these dependencies in
non-workspace members. This means that this will be slightly buggy if an
optional dependency that's activated is added, but that's hopefully something we
can tackle later.
Alex Crichton [Tue, 3 Apr 2018 18:42:44 +0000 (11:42 -0700)]
Less aggressively poison sources on builds
Discovered in #5257 the changes in #5215 were slightly too aggressively
poisoning sources to require updates, thinking that a manifest changed when it
actually hadn't.
Non-workspace-member path dependencies with optional/dev-dependencies
don't show up in the lock file, so the previous logic would recognize this and
think that the dependency missing from the lock file was just added and would
require a registry update.
The fix in this commit effectively just skips all of these dependencies in
non-workspace members. This means that this will be slightly buggy if an
optional dependency that's activated is added, but that's hopefully something we
can tackle later.
projects / cargo.git / log