Zack M. Davis [Wed, 1 Feb 2017 04:51:24 +0000 (20:51 -0800)]
make build tests not depend on minutiæ of rustc output
This little patch arises from the maelstrom of my purity born of pain.
It's the pain of seeing rust-lang/rust#38103 in its perfect
crystalline beauty waste away on page four of
https://github.com/rust-lang/rust/pulls, waiting, ready, itching to
land, dying with anticipation to bring the light of clearer lint group
error messages to Rust users of all creeds and nations, only for its
promise to be cruelly blocked by the fateful, hateful hand of circular
dependency. For it is written in src/tools/cargotest/main.rs that the
Cargo tests must pass before the PR can receive Appveyor's blessing,
but the Cargo tests could not pass (because they depend on fine
details of the output that the PR is meant to change), and the Cargo
tests could not be changed (because updating the test expectation to
match the proposed new compiler output, would fail with the current
compiler).
The Gordian knot is cut in the bowels of cargotest's very notion of
comparison (of JSON objects) itself, by means of introducing a magic
string literal `"{...}"`, which can server as a wildcard for any JSON
sub-object.
And so it will be for the children, and the children's children, and
unto the 1.17.0 and 1.18.0 releases, that Cargo's build test
expectations will faithfully expect the exact JSON output by Cargo
itself, but the string literal `"{...}"` shall be a token upon the
JSON output by rustc, and when I see `"{...}"`, I will pass over you,
and the failure shall not be upon you.
bors [Thu, 2 Feb 2017 02:15:05 +0000 (02:15 +0000)]
Auto merge of #3609 - jmatraszek:build_proper_binary, r=alexcrichton
Fix building multiple binaries that do not have path spacified in Cargo.toml
When multiple binaries are specified in Cargo.toml, the binaries that do not have `path` specified are build from `src/main.rs`. Discovered here: https://github.com/rust-lang-nursery/thanks/pull/40#issuecomment-275493045.
This was caused by setting for a binary a main layout here https://github.com/rust-lang/cargo/blob/master/src/cargo/util/toml.rs#L478, which caused `normalize` to not fallback to default binary path here https://github.com/rust-lang/cargo/blob/master/src/cargo/util/toml.rs#L1149 (as `bin.path` was always `Some("/path/to/main.rs")`.
Added a test and fixed this by not using `layout.main()`, so right now for bins without `path` specified we fallback to default path inferred from bin's name (e.g. `src/bin/foo.rs`), test if the file exists and only if it doesn't -- fallback to `src/main.rs`.
I do not have any knowledge about Cargo's design, so I am not sure if this is the proper place to test for file existence.
If `[members]` key present, it compliantly defines the set of members. Otherwise, members are all (transitive) path dependencies.
The problem with this approach is that it violates convention over configuration principle: almost always you want a path dependency to be a member, even if there are some explicit members. Listing **all** path deps is just to much work.
# Original implementation
So, the actual algorithm **unconditionally** included path dependencies as memebers.
This is also problematic, because certain workspace configurations become impossible. In particular, you can't have a path dependency which is not a member of the workspace. This issue was reported in #3192.
# Current implementation
Current implementation (was merged couple of days ago) includes path dependency into the workspace only if is inside the workspace directory. This solves the problem in #3192 perfectly. However, some configuration are still impossible: you can't have a non-member path dependency inside a workspace directory. But the thinking is that if you don't want this path-dep to be a member, just don't put it inside the workspace directory.
There is another problem with current imlementation. Suppose you have an explicit member which lives alongside the workspace. Suppose this member has a path-dep which lives inside the member's folder. Under current implementation, this path-dep won't be a member of the workspace. It seems logical that it should be though (but we haven't received any actual bug reports yet)!
# Implementation in this PR
So, with this PR, the logic is as follows: members are explicit members + all path dependencies which reside under any of the explicit members.
bors [Wed, 1 Feb 2017 22:22:19 +0000 (22:22 +0000)]
Auto merge of #3004 - ehiggs:master, r=alexcrichton
Resubmission of templating PR (#1747)
This is a manual rebase of the older #1747 PR which was basically unrebasable due to the time it's been dormant.. This implements templating for Cargo and is basically the work of Greg Chapple (@gchp).
I'd love for this feature to move forward since it's really tedious to create all the directories (e.g. `src/bin`) and copy paste docopt examples which I then edit. Then implement the `main` program to delegate to the subcommands in `src/bin`, etc.
Ewan Higgs [Tue, 16 Aug 2016 23:58:05 +0000 (01:58 +0200)]
Cargo templating for `new` and `init`
PR #3004 This is a resubmission of the PR #1747 (from scratch) which adds
support for templating in Cargo. The templates are implemented using the
handlebars crate (where the original PR used mustache).
Examples:
cargo new --template https://url/to/template somedir foo
cargo new --template https://url/to/templates --template-subdir somedir foo
cargo new --template ../path/to/template somedir foo
bors [Tue, 31 Jan 2017 03:20:49 +0000 (03:20 +0000)]
Auto merge of #3618 - sbeckeriv:3473-new-subcommand-doc-update, r=alexcrichton
Update new command help doc
Resolves #3473
Dearest reviewer,
I hope that all is well in rustland. I was reviewing some open issues
and saw this update to the help text for the new command. I have added
the suggested help text from issue #3473. I formated to the message to
match the publish bin's job flag.
I hope that all is well in rustland. I was reviewing some open issues
and saw this update to the help text for the new command. I have added
the suggested help text from issue #3473. I formated to the message to
match the publish bin's job flag.
bors [Sun, 29 Jan 2017 02:06:47 +0000 (02:06 +0000)]
Auto merge of #3604 - froydnj:rich-version-info, r=alexcrichton
implement `cargo --version --verbose`
As suggested in #3584. This is a bit underwhelming, and I'm unsure if some of the complexity in froydnj/cargo@775c900 is really warranted, but this series gets the job done. Sample output when building with `configure` and `make`:
bors [Sat, 28 Jan 2017 00:35:00 +0000 (00:35 +0000)]
Auto merge of #3593 - Susurrus:master, r=alexcrichton
Improve error for dependencies that don't have the same source paths
I've added an additional test case which is how my project compiled. Part of the issue was that I didn't know that each dependency needs to use the same path for all build targets. The previous error message was unclear both in what was going on and how to resolve it. The new error message should be more clear.
bors [Fri, 27 Jan 2017 22:55:06 +0000 (22:55 +0000)]
Auto merge of #3557 - raphlinus:master, r=alexcrichton
Add dep-info generation
Work in progress: add a --dep-info flag to cargo build (and also
rustc) that outputs dependency information in a form compatible with
make and ninja, to a specified file. This will help in integrating
into other build systems.
Nathan Froyd [Fri, 27 Jan 2017 16:39:17 +0000 (11:39 -0500)]
export rich version information from cargo::version
To support `cargo --version --verbose`, ala rustc, we need more
information to be injected into cargo when it's built from the Makefile,
and a more explicit data structure to be returned from cargo::version.
We implement fmt::Display for our newly-created structure so clients
don't have to bother with the details of interpreting the structure if
all they want is a string.
bors [Thu, 26 Jan 2017 22:27:33 +0000 (22:27 +0000)]
Auto merge of #3597 - Susurrus:badge_docs, r=alexcrichton
Add gitlab to the supported services for AppVeyor badges.
This is undocumented but supported behavior for AppVeyor. I have already done this with a crate I own and the badge works on both the AppVeyor and crates.io end.
Raph Levien [Tue, 17 Jan 2017 21:22:05 +0000 (13:22 -0800)]
Add dep-info generation
Make cargo output a ".d" file containing dependency info (in a format
that make and ninja can consume) for each artifact it produces. This
will help in integrating into other build systems.
bors [Fri, 20 Jan 2017 18:48:12 +0000 (18:48 +0000)]
Auto merge of #3554 - bmwiedemann:patch-1, r=alexcrichton
make build reproducible
see https://reproducible-builds.org/ for why this is good
and https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal#Bash_.2F_POSIX_shell for variants that also work on BSD
bors [Thu, 19 Jan 2017 23:43:24 +0000 (23:43 +0000)]
Auto merge of #3565 - integer32llc:fix-gh-pages, r=alexcrichton
Fix doc publishing: Remove $USER from the --user argument from pip install
[This looks to be the cause of why docs aren't publishing to gh-pages](https://travis-ci.org/rust-lang/cargo/jobs/193507734#L1059). I was able to publish the docs to [my repo's gh-pages](https://integer32llc.github.io/cargo/) with this change (and setting my own secure gh-token).
It looks like this problem got introduced [in this commit](https://github.com/rust-lang/cargo/commit/dc15ca5d202d6d10f6be45f388759a902723de6c). I don't really know python/pip, but `$USER` wasn't there before and [Travis' docs just say `--user`](https://docs.travis-ci.com/user/languages/python/#pip).
Since `--test` works for rustc, doctests should also work. Currently cargo isn't setup to run doctests for proc macro crates, this PR adds them to the list.
Currently rustdoc can run doctests for proc-macro crates, but the `phase_2_configure_and_expand` call` triggers the following warning:
```
the `#[proc_macro_derive]` attribute is only usable with crates of the `proc-macro` crate type
```
So perhaps this PR should wait until I've finished creating/testing the PR for rustc.
bors [Tue, 17 Jan 2017 22:40:07 +0000 (22:40 +0000)]
Auto merge of #3546 - integer32llc:badgers, r=alexcrichton
Upload Travis CI and Appveyor badge metadata specified in the manifest
This goes with rust-lang/crates.io#504. This has cargo upload badge metadata to crates.io on publish, and will print any warnings it gets back from crates.io about unknown badges or missing required badge attributes!
This will definitely cause some merge conflicts with #3301, I'll watch and fix whichever one gets merged 2nd :)
bors [Tue, 17 Jan 2017 18:57:20 +0000 (18:57 +0000)]
Auto merge of #3301 - integer32llc:categories, r=alexcrichton
Upload categories specified in the manifest
This adds support for uploading categories to crates.io, if they are specified in the manifest.
This goes with rust-lang/crates.io#473. It should be fine to merge this PR either before or after that one; crates.io master doesn't care if the categories are in the metadata or not. With that PR, I was able to use this patch with cargo to add categories to a crate!
bors [Tue, 17 Jan 2017 02:48:37 +0000 (02:48 +0000)]
Auto merge of #3542 - creativcoder:check-digit-name, r=alexcrichton
Add a check for names starting with a digit
According to Rust grammer https://doc.rust-lang.org/grammar.html#extern-crate-declarations for extern crate declarations, a crate name cannot start with a digit.
But, currently this rule is not upheld by `cargo new` as creating a project like:
`cargo new 2048` would create a project named 2048 which obviously won't compile with crate declaration like `extern crate 2048` by a consumer.
This obviously is a rare case in practice, but its always good to check i guess.
This PR adds a check to the `new` method and `bail`s out with a message for any names starting with a digit.
PS: I noticed it while making a 2048 puzzle game as a library so thought it would be nice to add this check :)
bors [Thu, 12 Jan 2017 07:56:39 +0000 (07:56 +0000)]
Auto merge of #3533 - jtgeibel:3519-dev-target, r=alexcrichton
Rename debug target to dev in build output
This renames the debug target to dev in the build output for non-release
builds. This includes the output of commands such as `cargo build`,
`cargo test`, and `cargo doc`.
bors [Thu, 12 Jan 2017 05:56:12 +0000 (05:56 +0000)]
Auto merge of #3532 - alexcrichton:ignore, r=brson
Ignore spuriously failing Windows test
I really have no clue why this test is failing on Windows, and after months of
being unable to diagnose I'm tired of retrying PRs due to this failure. Let's
just ignore it on Windows.
bors [Thu, 12 Jan 2017 04:03:27 +0000 (04:03 +0000)]
Auto merge of #3490 - alexcrichton:dev-dep-doc-test, r=brson
Fix cargo test --doc with dev-deps
Previously Cargo accidentally didn't pull in dev-dependencies due to the way
`cargo test --doc` was interpreted in terms of top-level targets. This PR
special cases this situation by ensuring that the doctest intention makes its
way all to the backend and the dependencies can be correctly calculated.