Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project.
is_build==false <-> ProjectBuilder
is_build==true <-> Project
Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project.
The same goes for RepoBuilder.
ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability.
Signed-off-by: NODA, Kai <nodakai@gmail.com>
Fixes#4326
`cargo package` (and so `cargo publish`) parses a crate’s `Cargo.toml`,
makes some modifications, and re-serializes it.
Because the `TomlManifest` struct uses `HashMap`
with its default `RandomState` hasher,
the maps’ iteration order changed on every run.
As a result, when using `cargo vendor`,
updating a dependency would generate a diff larger than necessary,
with non-significant order-changes obscuring significant changes.
This replaces some uses of `HashMap` with `BTreeMap`,
whose iteration order is deterministic (based on `Ord`).
Background: https://github.com/rust-lang/cargo/issues/4268
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.
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.
Migration Tracking: <https://github.com/rust-lang/cargo/issues/4268>
In TOML we have to emit all keys before we emit all sub-tables, so to handle
that for dependencies just transform everything to an elaborated version.
Closes#4081
This commit is an implementation of rewriting TOML manifests when we publish
them to the registry. The rationale for doing this is to provide a guarantee
that downloaded tarballs from crates.io can be built with `cargo build`
(literally). This in turn eases a number of other possible consumers of crates
from crates.io
* Vendored sources can now be more easily modified/checked as cargo build should
work and they're standalone crates that suffice for `path` dependencies
* Tools like cargobomb/crater no longer need to edit the manifest and can
instead perform regression testing on the literal tarballs they download
* Other systems such as packaging Rust code may be able to take advantage of
this, but this is a less clear benefit.
Overall I'm hesitatnt about this, unfortunately. This is a silent translation
happening on *publish*, a rare operation, that's difficult to inspect before it
flies up to crates.io. I wrote a script to run this transformation over all
crates.io crates and found a surprisingly large number of discrepancies. The
transformation basically just downloaded all crates at all versions,
regenerated the manifest, and then tested if the two manifests were (in memory)
the same.
Unfortunately historical Cargo had a critical bug which I think made this
exercise not too useful. Cargo used to *not* recreate tarballs if one already
existed, which I believe led to situations such as:
1. `cargo publish`
2. Cargo generates an error about a dependency. This could be that there's a
`version` not present in a `path` dependency, there could be a `git`
dependency, etc.
3. Errors are fixed.
4. `cargo publish`
5. Publish is successful
In step 4 above historical Cargo *would not recreate the tarball*. This means
that the contents of the index (what was published) aren't guaranteed to match
with the tarball's `Cargo.toml`. When building from crates.io this is ok as the
index is the source of truth for dependency information, but it means that *any*
transformation to rewrite Cargo.toml is impossible to verify against all crates
on crates.io (due to historical bugs like these).
I strove to read as many errors as possible regardless, attempting to suss out
bugs in the implementation here. To further guard against surprises I've updated
the verification step of packaging to work "normally" in these sense that it's
not rewriting dependencies itself or changing summaries. I'm hoping that this
serves as a good last-ditch effort that what we're about to publish will indeed
build as expected when uploaded to crates.io
Overall I'm probably 70% confident in this change. I think it's necessary to
make progress, but I think there are going to be very painful bugs that arise
from this feature. I'm open to ideas to help weed out these bugs ahead of time!
I've done what I can but I fear it may not be entirely enough.
Closes#4027
some clippy-suggested improvements
This fixes a number of [clippy](https://github.com/Manishearth/rust-clippy) warnings. It's mostly about readability, though a few changes could affect performance (though probably not measurably).
I've left out things to fix later; I thought I'd just push the first batch to see if you like it.
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`.
Closes#3519
Continuously publish Cargo builds
This commit tweaks Cargo's automation to continuously publish builds on Travis
an AppVeyor. Once this is merged we can hopefully turn off all buildbot
automation related to Cargo and purely rely on Travis and AppVeyor for this
repository. All CI matrices are ported over to Travis and AppVeyor and a new
musl build of Cargo is even added just to test out adding that for a spin.
Currently Cargo will upload the final artifact for each target to a directory
keyed by the commit hash to a new bucket on S3, rust-lang-cargo-dev. Once we're
happy with the builds then we can change this to `rust-lang-cargo` or anything
else at that point.
This commit tweaks Cargo's automation to continuously publish builds on Travis
an AppVeyor. Once this is merged we can hopefully turn off all buildbot
automation related to Cargo and purely rely on Travis and AppVeyor for this
repository. All CI matrices are ported over to Travis and AppVeyor and a new
musl build of Cargo is even added just to test out adding that for a spin.
Currently Cargo will upload the final artifact for each target to a directory
keyed by the commit hash to a new bucket on S3, rust-lang-cargo-dev. Once we're
happy with the builds then we can change this to `rust-lang-cargo` or anything
else at that point.
Previously, cargo package did not do anything if a tarball already
existed. This is wrong, because the source may have changed and cargo
does not do any dependency tracking for package tarballs yet, so it did
not notice this.
This commit changes cargo package to always overwrite existing tarballs,
which works fine until proper dependency tracking is implemented.
Fixes#2799
This commit alters Cargo's behavior to prevent publishing a crate by default if
any files in that crate are determined to be dirty, that is either modified or
not part of the working tree.
This can prevent common mistakes like many listed in #2063, and subsequently...
Closes#2063
Compiling everything in one binary was getting annoying as it just took forever
to build, instead shard it all up so we can build just particular test suites at
a time.
2016-05-25 21:25:13 -07:00
Renamed from tests/test_cargo_package.rs (Browse further)
