bors [Mon, 14 Aug 2017 23:23:05 +0000 (23:23 +0000)]
Auto merge of #4404 - parkovski:master, r=alexcrichton
Fix #4370 - init panic in C:\ or /
This fixes the crash in this issue, but the error message is strange - unable to create directory 'C:\\.'. I don't have write permissions there without becoming admin, so I suspect it's just a permission issue, but the weird error can be fixed by calling Path::canonicalize on line 300.
bors [Sat, 12 Aug 2017 14:46:51 +0000 (14:46 +0000)]
Auto merge of #4393 - burtonageo:update-cargo-new-template, r=matklad
Update lib template for `cargo new` so that the placeholder test contains an assertion
When you run `rustfmt` on the default generated lib template, it modifies it as shown [here](https://play.rust-lang.org/?gist=bd44610731e26e76719e75d47e598990&version=undefined)
bors [Thu, 10 Aug 2017 09:04:21 +0000 (09:04 +0000)]
Auto merge of #4390 - alexcrichton:read-hard-links, r=matklad
Use `same-file` to avoid unnecessary hard links
This is targeted at removing the need for a workaround in rust-lang/rust#39518,
allowing the main rust build system to move back to hard links which should be
much more efficient.
Alex Crichton [Thu, 10 Aug 2017 00:22:34 +0000 (17:22 -0700)]
Use `same-file` to avoid unnecessary hard links
This is targeted at removing the need for a workaround in rust-lang/rust#39518,
allowing the main rust build system to move back to hard links which should be
much more efficient.
bors [Wed, 9 Aug 2017 16:30:21 +0000 (16:30 +0000)]
Auto merge of #4382 - Xanewok:expose-filter-rule, r=alexcrichton
Expose ops::cargo_compile::FilterRule
I've been mindlessly copying and consuming the Cargo API to work on the build plan prototype for RLS and I noticed that, it seems, pub `ops::cargo_compile::CompileFilter` is exported, but not the `ops::cargo_compile::FilterRule`, which `CompileFilter` uses, as a part of a public API.
If I'm wrong and missing something, feel free to ignore/close it. It was possible to match/destructure `CompileFilter` before, but with this change it's possible to use the underlying type.
This diff takes us to **Stage 1.1** of the migration plan by allowing
glob patterns to include a leading slash, so that glob patterns can be
updated, if needed, to start with a slash, closer to the future behavior
with gitignore-like matching.
Why is this stage needed?
It's common to have `package.include` set like this:
```
include = ["src/**"]
```
In old interpretation, this would only include all files under the `src`
directory under the package root. With the new interpretation, this
would match any path with some directory called `src`, even if it's not
directly under the package root.
After this patch, package owners can start marking glob patters with a
leading slash to fix the warning thrown, if any.
One thing to notice here is that there are no extra matchings, but, if
a manifest has already a pattern with a leading slash, this would
silently start matching it with the paths. I believe this is fine, since
the old behavior would have been for the pattern to not match anything,
therefore the item was useless.
See also <https://github.com/rust-lang/cargo/issues/4377> for suggestion
to throw warning on useless/invalid patterns in these fields.
bors [Wed, 9 Aug 2017 14:10:12 +0000 (14:10 +0000)]
Auto merge of #3611 - tylerwhall:stable-metadata, r=alexcrichton
Stable metadata hashes across workspaces
Currently a crate from a path source will have its metadata hash incorporate its absolute path on the system where it is built. This always impacts top-level crates, which means that compiling the same source with the same dependencies and compiler version will generate libraries with symbol names that vary depending on where the workspace resides on the machine.
This is hopefully a general solution to the hack we've used in meta-rust to make dynamic linking reliable.
meta-rust/meta-rust@0e6cf94
For paths inside the Cargo workspace, hash their SourceId relative to the root of the workspace. Paths outside of a workspace are still hashed as absolute.
This stability is important for reproducible builds as part of a larger build system that employs caching of artifacts, such as OpenEmbedded.
OpenEmbedded tightly controls all inputs to a build and its caching assumes that an equivalent artifact will always result from the same set of inputs. The workspace path is not considered to be an influential input, however.
For example, if Cargo is used to compile libstd shared objects which downstream crates link to dynamically, it must be possible to rebuild libstd given the same inputs and produce a library that is at least link-compatible with the original. If the build system happens to cache the downstream crates but needs to rebuild libstd and the user happens to be building in a different workspace path, currently Cargo will generate a library incompatible with the original and the downstream executables will fail at runtime on the target.
bors [Tue, 8 Aug 2017 00:58:29 +0000 (00:58 +0000)]
Auto merge of #4376 - behnam:virtual, r=alexcrichton
[docs/manifest] Add Virtual Manifest section
Current documentation does not mention Virtual Manifests at all, which
can be confusing because they appear in error messages.
Here we add the definition, and provide a hint about `--all` option for
most cargo commands, which allow the command to work in the way most
probably expected.
bors [Tue, 8 Aug 2017 00:05:36 +0000 (00:05 +0000)]
Auto merge of #4374 - behnam:new-init, r=alexcrichton
[cargo_new] Hint to use `cargo init` on existing dir
The `new` command always expects a non-existing path. The `init` command
always expects an existing path. Therefore, it makes sense to hint to
use `init` if the pre-condition to `new` is not satisfied.
bors [Mon, 7 Aug 2017 23:40:25 +0000 (23:40 +0000)]
Auto merge of #4375 - behnam:root-vs-repo, r=alexcrichton
[docs] Update language regarding repository vs package root
In the current documentation, there are many places with language that
assumes a *repository* (as in VCS) is the same as *package root* (the
directory where `Cargo.toml` sits).
With the new workspace features, this is far from true now, and the
inaccurate language makes it difficault for newbies or developers
without much familiarity with the cargo internals with authoring their
manifest files.
This diff tries to use the right terms for places any of these concepts
is referred to:
* Package root,
* Workspace root,
* VCS repository, and
* Package repository/index, like crates.io.
This diff takes us to **Stage 1.1** of the migration plan by allowing
glob patterns to include a leading slash, so that glob patterns can be
updated, if needed, to start with a slash, closer to the future behavior
with gitignore-like matching.
Why is this stage needed?
It's common to have `package.include` set like this:
```
include = ["src/**"]
```
In old interpretation, this would only include all files under the `src`
directory under the package root. With the new interpretation, this
would match any path with some directory called `src`, even if it's not
directly under the package root.
After this patch, package owners can start marking glob patters with a
leading slash to fix the warning thrown, if any.
One thing to notice here is that there are no extra matchings, but, if
a manifest has already a pattern with a leading slash, this would
silently start matching it with the paths. I believe this is fine, since
the old behavior would have been for the pattern to not match anything,
therefore the item was useless.
See also <https://github.com/rust-lang/cargo/issues/4377> for suggestion
to throw warning on useless/invalid patterns in these fields.
Behnam Esfahbod [Mon, 7 Aug 2017 18:44:34 +0000 (11:44 -0700)]
[docs/manifest] Add Virtual Manifest section
Current documentation does not mention Virtual Manifests at all, which
can be confusing because they appear in error messages.
Here we add the definition, and provide a hint about `--all` option for
most cargo commands, which allow the command to work in the way most
probably expected.
Behnam Esfahbod [Mon, 7 Aug 2017 18:11:36 +0000 (11:11 -0700)]
[docs] Update language regarding repository vs package root
In the current documentation, there are many places with language that
assumes a *repository* (as in VCS) is the same as *package root* (the
directory where `Cargo.toml` sits).
With the new workspace features, this is far from true now, and the
inaccurate language makes it difficault for newbies or developers
without much familiarity with the cargo internals with authoring their
manifest files.
This diff tries to use the right terms for places any of these concepts
is referred to:
* Package root,
* Workspace root,
* VCS repository, and
* Package repository/index, like crates.io.
Behnam Esfahbod [Mon, 7 Aug 2017 16:31:32 +0000 (09:31 -0700)]
[cargo_new] Hint to use `cargo init` on existing dir
The `new` command always expects a non-existing path. The `init` command
always expects an existing path. Therefore, it makes sense to hint to
use `init` if the pre-condition to `new` is not satisfied.
bors [Mon, 7 Aug 2017 04:12:18 +0000 (04:12 +0000)]
Auto merge of #4372 - frankmcsherry:patch-1, r=alexcrichton
Modernize explanation of `build.rs`
After some recent head-banging, it was explained to me that `"build.rs"` is a special file name, and that Cargo will build such a file even if you do not expect it to, for example if `Cargo.toml` contains the commented out line
```
#build = "build.rs"
```
Some experimentation lead me to the described behavior, but if it misses any subtle details please feel free to correct. The old text is incorrect, though.
Frank McSherry [Sun, 6 Aug 2017 20:57:13 +0000 (16:57 -0400)]
Modernize explanation of `build.rs`
After some recent head-banging, it was explained to me that `"build.rs"` is a special file name, and that Cargo will build such a file even if you do not expect it to, for example if `Cargo.toml` contains the commented out line
```
#build = "build.rs"
```
Some experimentation lead me to the described behavior, but if it misses any subtle details please feel free to correct. The old text is incorrect, though.
bors [Fri, 4 Aug 2017 09:28:33 +0000 (09:28 +0000)]
Auto merge of #4355 - pornel:docs, r=alexcrichton
Expand profile settings descriptions
Flags were described in the format `foobar = true # controls foobar, passes '--foobar' flag`, but this doesn't actually say what `foobar` does. I've expanded the descriptions a little to provide more context.
Auto merge of #4342 - sid0:hgignore, r=alexcrichton
new: fix hgignore for real
There was an attempt to fix hgignore in #4158, but unfortunately the fix
was incorrect -- hgignore glob syntax is not in fact identical to
gitignore syntax.
To get rooted ignores in Mercurial we must use the regex-based syntax,
so we have no choice but to define a separate set of ignores.
There was an attempt to fix hgignore in #4158, but unfortunately the fix
was incorrect -- hgignore glob syntax is not in fact identical to
gitignore syntax.
To get rooted ignores in Mercurial we must use the regex-based syntax,
so we have no choice but to define a separate set of ignores.
Avoids the sticking point of the previous two PRs (multiple registry updates) by threading through a first-run boolean flag to decide whether `select_pkg` needs to call `source.update()`.
There is still the issue that flags such as `--git` and `--vers` are "global" to the multiple packages you may be installing. The workaround is just to run `cargo install` separately. In the future we could add syntax like `cargo install foo=1.0 bar=2.5 quux=git://github.com/durka/quux#dev-branch` or something.
Auto merge of #4335 - debris:rebased_4021, r=matklad
Rebased and fixed 4025: Apply --all if workspace is virtual
- fixes #4021
- rebased #4025
- fixed issue issue described by @matklad in https://github.com/rust-lang/cargo/pull/4025#pullrequestreview-40660570
- added test `build_virtual_manifest_one_project` which covers the fix
As discussed with @aturon, who took it to @rust-lang/core.
LICENSE-MIT and one source file contain inaccurate copyright notices of
the form "Copyright (c) (years) The Rust Project Developers", which
implies that an entity called "The Rust Project Developers" holds
copyrights in Rust. Rust contributors retain their copyrights, and do
not assign them to anyone by contributing. Remove the inaccurate
notices.
LICENSE-MIT and one source file contain inaccurate copyright notices of
the form "Copyright (c) (years) The Rust Project Developers", which
implies that an entity called "The Rust Project Developers" holds
copyrights in Rust. Rust contributors retain their copyrights, and do
not assign them to anyone by contributing. Remove the inaccurate
notices.
[doc/manifest] Add build-dependencies to Dependency sections list
The `[build-dependencies]` section was missing from the Dependency
sections list, making it hard to find its existence and link to
`specifying-dependencies` page. This puts the section title in the list,
so a normal find works.
[doc/manifest] Add build-dependencies to Dependency sections list
The `[build-dependencies]` section was missing from the Dependency
sections list, making it hard to find its existence and link to
`specifying-dependencies` page. This puts the section title in the list,
so a normal find works.
Auto merge of #4305 - nodakai:fix-4278-tests-on-empty-ld_library_path, r=matklad
tests/build.rs: remove empty components from LD_LIBRARY_PATH to fix #4278
The tests intended to ensure Cargo wouldn't mistakenly add empty components to `LD_LIBRARY_PATH` (or its equivalents) but they could fail when the test runner already had empty components in `LD_LIBRARY_PATH` from their environment.
NODA, Kai [Wed, 19 Jul 2017 13:59:50 +0000 (21:59 +0800)]
tests/build.rs: remove empty components from LD_LIBRARY_PATH
This is to amend PR #4278
The tests intended to ensure Cargo wouldn't mistakenly add empty
components to LD_LIBRARY_PATH (or its equivalents) but they could fail
when the test runner already had empty components in LD_LIBRARY_PATH
from their environment.
Auto merge of #4303 - bluetech:doc-env-cfg, r=alexcrichton
Document the CARGO_CFG_* environment variables - fixes #4302
In order to keep the paragraph brief, I have omitted:
- examples of actual variable names - though adding those might help google.
- mention of `rustc --print cfg` - I think the link to the reference is enough.
- reference to the [RFC](https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md#lowering-cfg-values-to-cargo-build-script-environment-variables) - I don't think it's needed.
This pulls out the definitions of these functions into a single crate, [home](https://github.com/brson/home), to act as their canonical definition.
This has a bigger impact on rustup, since it is using definitions of all these things, where cargo is just defining cargo_home in terms of std's wrong home_dir.
The [definition of cargo_home](https://github.com/brson/home/blob/master/src/lib.rs#L179) used here is slightly different than what cargo has today in that it contains a bit of defensive code to avoid allowing `CARGO_HOME` to be set to `.multirust/cargo` - this is backwards compatibility code from rustup.
Auto merge of #4123 - alexcrichton:augment, r=matklad
Implement the [patch] section of the manifest
This is an implementation of [RFC 1969] which adds a new section to top-level
manifests: `[patch]`. This section allows you to augment existing sources with
new versions of crates, possibly replacing the versions that already exist in
the source. More details about this feature can be found in the RFC itself.
Alex Crichton [Fri, 12 May 2017 18:07:46 +0000 (11:07 -0700)]
Implement the [patch] section of the manifest
This is an implementation of [RFC 1969] which adds a new section to top-level
manifests: `[patch]`. This section allows you to patch existing sources with
new versions of crates, possibly replacing the versions that already exist in
the source. More details about this feature can be found in the RFC itself.
Auto merge of #4270 - behnam:ignore, r=alexcrichton
[sources/path] Add gitignore-like pattern matching and warn on mismatches
Add gitignore-like pattern matching logic to `list_files()` and throw
warnings for paths getting different inclusion/exclusion results from
the old and the new methods.
projects / cargo.git / log