cargotest/support: remove internal mutability in favor of switching types
`Cell<bool>` was removed from `ProjectBuilder`. Instead `PhantomData<T>` was added to it (and `RepoBuilder`) to manage state transition in the type level (`T` is either `Configuring` or `Done`.)
`ProjectBuilder::cargo_process()` was removed as its design heavily depended on the internal mutability.
Also added `#[must_use]` to `ProjectBuilder` and `RepoBuilder` to check for call sites of their `build()` method.
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>
Create `WorkspaceRootConfig`, which knows its `root_dir` and lists of
`members` and `excludes`, to answer queries on which paths are a member
and which are not.
This commit adds a new key to the `Cargo.toml` manifest, `workspace.exclude`.
This new key is a list of strings which is an array of directories that are
excluded from the workspace explicitly. This is intended for use cases such as
vendoring where path dependencies into a vendored directory don't want to pull
in the workspace dependencies.
There's a number of use cases mentioned on #3192 which I believe should all be
covered with this strategy. At a bare minimum it should suffice to `exclude`
every directory and then just explicitly whitelist crates through `members`
through inclusion, and that should give precise control over the structure of a
workspace.
Closes#3192
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
There was a panic! when the command `cargo update` was
executed in a workspace like this:
mkdir ws
cd ws
echo '[workspace]' > Cargo.toml
cargo new p1
cargo new p2
cargo update
The problem is that cargo tries to generate the Cargo.lock file
even if there aren't any members on the workspace.
This fix checks the existence of members in the workspace before trying
to do anything so at least we report an error instead of throwing a
panic!
This commit implements a scheme for .cargo/config files where sources can be
redirected to other sources. The purpose of this will be to override crates.io
for a few use cases:
* Replace it with a mirror site that is sync'd to crates.io
* Replace it with a "directory source" or some other local source
This major feature of this redirection, however, is that none of it is encoded
into the lock file. If one source is redirected to another then it is assumed
that packages from both are exactly the same (e.g. `foo v0.0.1` is the same in
both location). The lock file simply encodes the canonical soure (e.g.
crates.io) rather than the replacement source. In the end this means that
Cargo.lock files can be generated from any replacement source and shipped to
other locations without the lockfile oscillating about where packages came from.
Eventually this support will be extended to `Cargo.toml` itself (which will be
encoded into the lock file), but that support is not implemented today. The
syntax for what was implemented today looks like:
# .cargo/config
[source.my-awesome-registry]
registry = 'https://example.com/path/to/index'
[source.crates-io]
replace-with = 'my-awesome-registry'
Each source will have a canonical name and will be configured with the various
keys underneath it (today just 'registry' and 'directory' will be accepted). The
global `crates-io` source represents crates from the standard registry, and this
can be replaced with other mirror sources.
All tests have been modified to use this new infrastructure instead of the old
`registry.index` configuration. This configuration is now also deprecated and
will emit an unconditional warning about how it will no longer be used in the
future.
Finally, all subcommands now use this "source map" except for `cargo publish`,
which will always publish to the default registry (in this case crates.io).
Previously Cargo would compile a library into a different location depending on
whether it was the "root crate" or not. In the ongoing saga of reducing Cargo's
reliance on the idea of a "root crate" this PR is the next step. With workspaces
the root crate of a compliation changes all the time, so the output needs to be
the same whether a crate is at the root or not.
Fixing this inconsistence in turn fixes bugs like #2855 and #2897 which arise
due to this discrepancy. Additionally, Cargo will no longer recompile a library
when it's used as a "root crate" or not.
This is fixed by taking a few steps:
* Everything is now compiled into the `deps` directory, regardless of whether
it's a root output or not.
* If a "root crate" is being compiled, then the relevant outputs are hard-linked
up one level to where they are today. This means that your binaries, dylibs,
staticlibs, etc, will all show up where they used to.
* The `-C metadata` flag is always omitted for path dependencies now. These
dependencies are always path dependencies and already all have unique crate
names. Additionally, they're the only crates in the DAG without metadata, so
there's no need to provide additional metadata. This in turn means that none
of the file names of the generated crates are mangled.
Closes#2855
Previously the "root" of a lock file would erroneously change over time, so
instead just ensure that the root of a lock file is always the root of the
workspace. Otherwise the contents should always be the same.
Closes#2837
This commit is an implementation of [RFC 1525] which specifies the addition of
**workspaces** to Cargo.
[RFC 1525]: https://github.com/rust-lang/rfcs/blob/master/text/1525-cargo-workspace.md
A workspace is a group of crates which are all compiled into the same output
directory and share the same `Cargo.lock` file. This means that dependencies are
cached between builds as well as dependencies all being shared at the same
versions. An update to any one dependency transitively affects all other members
of the workspace.
Typical repository layouts with a crate at the root and a number of path
dependencies simply need to add the following to the root `Cargo.toml`:
```toml
[workspace]
```
Otherwise more advanced configuration may be necessary through the
`package.workspace` or `workspace.members` keys. More information can be found
as part of [RFC 1525].
