bors [Wed, 9 Mar 2016 17:20:11 +0000 (09:20 -0800)]
Auto merge of #2455 - jespino:remove-completed-todo, r=alexcrichton
Removing finished TODO
I think this TODO is finished (The only public field in all the file is the Layout::path) If this is part of the TODO, i can set it as private and create a getter).
bors [Fri, 4 Mar 2016 18:22:25 +0000 (18:22 +0000)]
Auto merge of #2438 - jseyfried:subcommands, r=alexcrichton
This PR moves the subcommands in `src/bin` into their own directory and ensures future compatibility with the corrected search paths for non-inline modules (see [Rust PR #32006](https://github.com/rust-lang/rust/pull/32006)).
r? @alexcrichton
bors [Fri, 4 Mar 2016 00:56:13 +0000 (00:56 +0000)]
Auto merge of #2423 - alexcrichton:fix-pkgid-hash, r=brson
All crates being compiled by Cargo are identified by a unique `PackageId` instance. This ID incorporates information such as the name, version, and source from where the crate came from. Package ids are allowed to have path sources to depend on local crates on the filesystem. The package id itself encodes the path of where the crate came from.
Historically, however, the "path source" from where these packages are learned had some interesting logic. Specifically one specific source would be able to return many packages within. In other words, a path source would recursively walk crate definitions and the filesystem attempting to find crates. Each crate returned from a source has the same source id, so consequently all packages from one source path would have the same source path id.
This in turn leads to confusing an surprising behavior, for example:
* When crates are compiled the status message indicates the path of the crate root, not the crate being compiled
* When viewed from two different locations (e.g. two different crate roots) the same package would have two different source ids because the id is based on the root location.
This hash mismatch has been [papered over](https://github.com/rust-lang/cargo/pull/1697) in the past to try to fix some spurious recompiles, but it unfortunately [leaked back in](https://github.com/rust-lang/cargo/pull/2279). This is clearly indicative of the "hack" being inappropriate so instead these commits fix the root of the problem.
---
In short, these commits ensure that the package id for a package defined locally has a path that points precisely at that package. This was a relatively invasive change and had ramifications on a few specific portions which now require a bit of extra code to support.
The fundamental change here was to change `PathSource` to be non-recursive by default in terms of what packages it thinks it contains. There are still two recursive use cases, git repositories and path overrides, which are used for backwards compatibility. This meant, however, that the packaging step for crate no longer has knowledge of other crates in a repository to filter out files from. Some specific logic was added to assist in discovering a git repository as well as filtering out sibling packages.
Another ramification of this patch, however, is that special care needs to be taken when decoding a lockfile. We now need all path dependencies in the lockfile to point precisely at where the path dependency came from, and this information is not encoded in the lock file. The decoding support was altered to do a simple probe of the filesystem to recursively walk path dependencies to ensure that we can match up packages in a lock file to where they're found on the filesystem.
Overall, however, this commit closes #1697 and also addresses servo/servo#9794 where this issue was originally reported.
Alex Crichton [Tue, 1 Mar 2016 16:24:43 +0000 (08:24 -0800)]
Fix all tests with recent changes
The package id for path dependencies now has another path component pointing
precisely to the package being compiled, so lots of tests need their output
matches to get updated.
Alex Crichton [Tue, 1 Mar 2016 16:20:16 +0000 (08:20 -0800)]
Fix some packaging logic in path sources
Currently the packaging logic depends on the old recursive nature of path
sources for a few points:
* Discovery of a git repository of a package.
* Filtering out of sibling packages for only including the right set of files.
For a non-recursive path source (now essentially the default) we can no longer
assume that we have a listing of all packages. Subsequently this logic was
tweaked to allow:
* Instead of looking for packages at the root of a repo, we instead look for a
Cargo.toml at the root of a git repository.
* We keep track of all Cargo.toml files found in a repository and prune out all
files which appear to be ancestors of that package.
Alex Crichton [Tue, 1 Mar 2016 06:20:47 +0000 (22:20 -0800)]
Fix decoding lock files with path dependencies
With the previous changes a path dependency must have the precise path to it
listed in its package id. Currently when decoding a lockfile, however, all path
dependencies have the same package id, which unfortunately causes a mismatch.
This commit alters the decoding of a lockfile to perform some simple path
traversals to probe the filesystem to understand where path dependencies are and
set the right package id for the found packages.
Alex Crichton [Tue, 1 Mar 2016 06:19:24 +0000 (22:19 -0800)]
Ensure overrides use recursive path sources
This mirrors the behavior that they have today. The `load` method for path
sources will by default return a non-recursive `PathSource` which unfortunately
isn't what we want here.
Alex Crichton [Tue, 1 Mar 2016 06:17:28 +0000 (22:17 -0800)]
Remove hacks when hashing package ids
Right now there's a few hacks here and there to "correctly" hash package ids by
taking a package's root path into account instead of the path store in the
package id. The purpose of this was to solve issues where the same package
referenced from two locations ended up having two different hashes.
This hack leaked, however, into the implementation of fingerprints which in
turned ended up causing spurious rebuilds. Fix this problem once and for all by
just defining hashing on package ids the natural and expected way.
bors [Thu, 3 Mar 2016 18:20:20 +0000 (18:20 +0000)]
Auto merge of #2433 - alexcrichton:fix-lines-match, r=alexcrichton
Right now we only match a suffix of the line, assuming all lines start with
`[..]`. Instead this ensures that the first match is anchored at the start.
Alex Crichton [Thu, 3 Mar 2016 18:18:02 +0000 (10:18 -0800)]
Fix output matching in tests
Right now we only match a suffix of the line, assuming all lines start with
`[..]`. Instead this ensures that the first match is anchored at the start.
bors [Mon, 29 Feb 2016 19:32:24 +0000 (19:32 +0000)]
Auto merge of #2406 - alexcrichton:download-less, r=brson
Currently Cargo will download an entire resolution graph all at once when in fact most packages may not be relevant to a compilation. For example target-specific dependencies and dev-dependencies are unconditionally downloaded regardless of whether they're actually needed or not.
This commit alters the internals of Cargo to avoid downloading everything immediately and just switches to lazily downloading packages. This involved adding a new `LazyCell` primitive (similar to the one in use on crates.io) and also propagates `CargoResult` in a few more locations.
Overall this ended up being a pretty large refactoring so the commits are separated in bite-sized chunks as much as possible with the end goal being this PR itself.
bors [Fri, 26 Feb 2016 22:33:44 +0000 (22:33 +0000)]
Auto merge of #2419 - dikaiosune:master, r=alexcrichton
Resolves #2417. I also reorganized the order of the items on the page and moved a little bit of text around. I think it's clearer, but critique is more than welcome.
Adam Perry [Fri, 26 Feb 2016 22:15:41 +0000 (15:15 -0700)]
Disambiguating docs about when environment variables are set.
Providing an example of fetching env vars at runtime in a buildscript.
Reordering the list so that examples pertain to the correct sections.
bors [Fri, 26 Feb 2016 21:50:11 +0000 (21:50 +0000)]
Auto merge of #2418 - alexcrichton:update-git2, r=alexcrichton
This crate was recently updated to the next release of libgit2, and I've noticed
historically that a noop `cargo build` was slow in the git2-rs repository.
Curious to see if the new libgit2 version helped speed things up at all, I
tested it out.
Before this commit, a noop `cargo build` produced 599108 syscalls. After this
commit, a noop build produced 86925 syscalls, an 85% reduction in the number of
syscalls! Needless to say it's much faster.
Alex Crichton [Fri, 26 Feb 2016 21:47:56 +0000 (13:47 -0800)]
Update dependency on git2
This crate was recently updated to the next release of libgit2, and I've noticed
historically that a noop `cargo build` was slow in the git2-rs repository.
Curious to see if the new libgit2 version helped speed things up at all, I
tested it out.
Before this commit, a noop `cargo build` produced 599108 syscalls. After this
commit, a noop build produced 86925 syscalls, an 85% reduction in the number of
syscalls! Needless to say it's much faster.
bors [Fri, 26 Feb 2016 19:11:13 +0000 (19:11 +0000)]
Auto merge of #2398 - alexcrichton:config-env-var, r=brson
This commit adds a more principled system to rationalize what ends up being a
configuration value versus an environment variable. This problem is solved by
just saying that they're one and the same! Similar to Bundler, this commit
supports overriding the `foo.bar` configuration value with the `CARGO_FOO_BAR`
environment variable.
Currently this is used as part of the `get_string` and `get_i64` methods on
`Config`. This means, for example, that the following environment variables can
now be used to configure Cargo:
Currently it's not supported to encode a list in an environment variable, so for
example `CARGO_PATHS` would not be read when reading the global `paths`
configuration value.
cc #2362
cc #2395 -- intended to close this in tandem with #2397
bors [Thu, 25 Feb 2016 00:40:22 +0000 (00:40 +0000)]
Auto merge of #2407 - alexcrichton:better-failed-auth-error, r=brson
This commit is an attempt to improve the error message from failed
authentication attempts as well as attempting more usernames. Right now we only
attempt one username, but there are four different possible choices we could
select (including $USER which we weren't previously trying).
This commit tweaks a bunch of this logic and just in general refactors the
with_authentication function.
Alex Crichton [Mon, 22 Feb 2016 03:36:35 +0000 (19:36 -0800)]
Auth with more usernames and improve errors
This commit is an attempt to improve the error message from failed
authentication attempts as well as attempting more usernames. Right now we only
attempt one username, but there are four different possible choices we could
select (including $USER which we weren't previously trying).
This commit tweaks a bunch of this logic and just in general refactors the
with_authentication function.
Per https://github.com/rust-lang/cargo/issues/1609
Added in a single line that states that the cached packages are only
removed by running the clean command.
bors [Wed, 24 Feb 2016 01:06:16 +0000 (01:06 +0000)]
Auto merge of #2369 - alexcrichton:no-more-ar, r=alexcrichton
This is largely no longer needed as we bundle llvm-ar and use that (and it's
cross platform). Note that the underlying support still exists in Cargo as the
flag hasn't been removed from the compiler outright, and older compilers may
still be in use. Just no need to document it so prominently when it's no longer
needed!
Alex Crichton [Sat, 20 Feb 2016 18:36:09 +0000 (10:36 -0800)]
Implement a fallible PackageSet::get
This function will lazily download the package specified and fill a cell with
that package. Currently this is always infallible because the `PackageSet` is
initialized with all packages, but eventually this will not be true.
Alex Crichton [Fri, 19 Feb 2016 21:49:14 +0000 (13:49 -0800)]
Merge the get/download methods on the Source trait
Nothing currently implements the ability to more efficiently download a set of
packages at any one point in time, and the download/get distinction isn't really
used at all. We can always refactor later, but currently there's no benefit, nor
can it really be seen what the possible benefit is, so let's just merge these
two methods into one and have them operate on one id at a time.
Alex Crichton [Fri, 19 Feb 2016 21:16:14 +0000 (13:16 -0800)]
Move the `get_package` step later when calculating deps
Future calls to `get_package` may end up actually downloading a package, so we
want to defer this as late as possible to ensure that we don't download
anything.
Alex Crichton [Fri, 19 Feb 2016 19:15:39 +0000 (11:15 -0800)]
Refactor build script output state initialization
Like with the previous refactor, remove the need to list all packages in a
package set as we only need to lazily do this for the actual packages being
compiled. Whenever a build script is requested to be executed is when we
actually go and try to see if an override was in play.
Alex Crichton [Fri, 19 Feb 2016 19:02:17 +0000 (11:02 -0800)]
Refactor links validation to not use PackageSet
Eventually we may not have the entire set of packages resident in memory, so
refactor the implementation to validate the `links` attribute in a demand driven
way rather than all at once up front.
Alex Crichton [Fri, 19 Feb 2016 18:53:57 +0000 (10:53 -0800)]
Fuse SourceMap and PackageSet
This commit moves the SourceMap structure into the PackageSet structure, and
simultaneously massively cuts down on the API surface area of PackageSet. It's
intended that eventually a PackageSet will be a lazily loaded set of packages so
we don't have to download everything all at once, and this is the commit in
preparation of that.
Alex Crichton [Fri, 19 Feb 2016 08:07:22 +0000 (00:07 -0800)]
Read configuration from environment variables
This commit adds a more principled system to rationalize what ends up being a
configuration value versus an environment variable. This problem is solved by
just saying that they're one and the same! Similar to Bundler, this commit
supports overriding the `foo.bar` configuration value with the `CARGO_FOO_BAR`
environment variable.
Currently this is used as part of the `get_string` and `get_i64` methods on
`Config`. This means, for example, that the following environment variables can
now be used to configure Cargo:
Currently it's not supported to encode a list in an environment variable, so for
example `CARGO_PATHS` would not be read when reading the global `paths`
configuration value.
cc #2362
cc #2395 -- intended to close this in tandem with #2397
bors [Thu, 18 Feb 2016 17:12:57 +0000 (17:12 +0000)]
Auto merge of #2393 - WiSaGaN:bugfix/tests-mod-naming, r=alexcrichton
In the default `lib.rs` provided by `cargo-new`, the "test" module is named "test" while Rust convention is using "tests" as the name of the module: https://doc.rust-lang.org/book/testing.html#the-tests-module
The plural form also conforms with the style used in special directories at project root such as "examples" and "tests".
This pull request conforms to the existing style.
bors [Tue, 16 Feb 2016 18:51:49 +0000 (18:51 +0000)]
Auto merge of #2328 - alexcrichton:target-specific-deps, r=brson
This commit is an implementation of [RFC 1361][rfc] which is an extension of
Cargo's `target` section in `Cargo.toml` to allow the use of `#[cfg]`-like
expressions for target-specific dependencies. Now that the compiler has been
extended with `--print cfg` each invocation of Cargo will scrape this output and
learn about the relevant `#[cfg]` directives in play for the target being
compiled. Cargo will then use these directives to decide whether a dependency
should be activated or not.
This should allow definition of dependencies along the lines of:
Alex Crichton [Tue, 26 Jan 2016 00:54:10 +0000 (16:54 -0800)]
Implement cfg-based target-specific dependencies
This commit is an implementation of [RFC 1361][rfc] which is an extension of
Cargo's `target` section in `Cargo.toml` to allow the use of `#[cfg]`-like
expressions for target-specific dependencies. Now that the compiler has been
extended with `--print cfg` each invocation of Cargo will scrape this output and
learn about the relevant `#[cfg]` directives in play for the target being
compiled. Cargo will then use these directives to decide whether a dependency
should be activated or not.
This should allow definition of dependencies along the lines of:
bors [Thu, 11 Feb 2016 19:51:06 +0000 (19:51 +0000)]
Auto merge of #2370 - alexcrichton:windows-jobs, r=brson
Currently it's somewhat surprising if you're using cargo and it's then ctrl-c'd.
The child processes that Cargo spawned are likely to still be running around in
the background as they're not killed as well, and this could cause output spew
or future build failures.
This situation is handled by default on Unix because ctrl-c will end up sending
a signal to the entire *process group*, which kills everything, but on Windows
we're not as lucky (just Cargo itself is killed). By using job objects on
Windows we can ensure that the entire tree dies instead of just the top Cargo
process.
Alex Crichton [Mon, 8 Feb 2016 19:28:53 +0000 (11:28 -0800)]
Use job objects on windows for ctrl-c to work
Currently it's somewhat surprising if you're using cargo and it's then ctrl-c'd.
The child processes that Cargo spawned are likely to still be running around in
the background as they're not killed as well, and this could cause output spew
or future build failures.
This situation is handled by default on Unix because ctrl-c will end up sending
a signal to the entire *process group*, which kills everything, but on Windows
we're not as lucky (just Cargo itself is killed). By using job objects on
Windows we can ensure that the entire tree dies instead of just the top Cargo
process.
Alex Crichton [Mon, 8 Feb 2016 17:52:08 +0000 (09:52 -0800)]
Remove config references to the `ar` tool
This is largely no longer needed as we bundle llvm-ar and use that (and it's
cross platform). Note that the underlying support still exists in Cargo as the
flag hasn't been removed from the compiler outright, and older compilers may
still be in use. Just no need to document it so prominently when it's no longer
needed!
bors [Fri, 5 Feb 2016 20:52:49 +0000 (20:52 +0000)]
Auto merge of #2359 - matklad:metadata-no-deps, r=alexcrichton
closes #2356. The output is not exactly the same as with `read-manifest`, because I wanted to include the `version` field.
Tests and implementation is a copy-paste from `read-manifest` except that [this line](https://github.com/rust-lang/cargo/blob/master/src/bin/read_manifest.rs#L36) is omited, because `root_package` [does update anyway](https://github.com/rust-lang/cargo/blob/master/src/cargo/sources/path.rs#L51).
bors [Fri, 5 Feb 2016 18:32:07 +0000 (18:32 +0000)]
Auto merge of #2335 - fpgaminer:config-target, r=alexcrichton
Fixed #2332.
This PR adds `build.target` to the Cargo config file, which behaves in the same way as passing `--target` to Cargo. Example `.cargo/config`:
```
[build]
target = "thumbv6m-none-eabi"
```
Similar to how `--jobs` overrides `build.jobs`, `--target` will override `build.target`.
I added documentation to `config.md`, and a test to `test_cargo_cross_compile.rs`. I couldn't get cross compile working on my machine for `cargo test`. Hopefully travis passes it.
This is my first PR against Cargo; sorry if I missed any procedures.
bors [Fri, 5 Feb 2016 17:28:04 +0000 (17:28 +0000)]
Auto merge of #2357 - matklad:no-more-warnings-in-tests, r=alexcrichton
Warnings from unrelated tests can be a little disturbing. Maybe we should be stricter about them?
You can always temporary `#![allow(unused, warnings)]` in the module you are writing if you are in the middle of a new development and don't want the compiler putting a spoke in the wheel.
bors [Tue, 2 Feb 2016 21:12:37 +0000 (21:12 +0000)]
Auto merge of #2355 - alexcrichton:fix-ordering-bug, r=brson
Cargo needs to ensure that if a build script prints a `-L` path that it's the
first `-L` path passed to the compiler. That way the build script can be sure
that any output it generated is the first to be considered by the compiler.
Alex Crichton [Tue, 2 Feb 2016 19:42:57 +0000 (11:42 -0800)]
Fix DAG ordering of passed -L flags
Cargo needs to ensure that if a build script prints a `-L` path that it's the
first `-L` path passed to the compiler. That way the build script can be sure
that any output it generated is the first to be considered by the compiler.