bors [Tue, 21 May 2019 15:04:48 +0000 (15:04 +0000)]
Auto merge of #6933 - ehuss:cache-output, r=alexcrichton
Add message caching.
The `cache-messages` feature causes Cargo to cache the messages generated by
the compiler. This is primarily useful if a crate compiles successfully with
warnings. Previously, re-running Cargo would not display any output. With the
`cache-messages` feature, it will quickly redisplay the previous warnings.
```
cargo +nightly check -Z cache-messages
```
Notes:
- `short` messages do not work correctly.
- rustdoc does not support `--json-rendered=termcolor`, so its output is currently uncolored.
- This approach to rendering should address some output issues like #6848.
bors [Mon, 20 May 2019 19:09:40 +0000 (19:09 +0000)]
Auto merge of #6962 - Eh2406:pub-dep-prop-tests, r=alexcrichton
add public & private prop tests.
This is the code that checks that the resolver does not output a public & private conflict. We still do not have the gen of public dependencies do to https://github.com/rust-lang/cargo/pull/6653/commits/9b8b12c1f85082e623a4dc8c7b248d7b757efcde, because backtracking is to inefficient, but this checks that we are getting a correct answer.
This was supposed to be in #6653, but was lost in the edits of history.
Reconstructed from https://github.com/Eh2406/cargo/commit/5522aba5e8875d9c9e14eb66b5469ad481cba7a1
bors [Mon, 20 May 2019 15:59:39 +0000 (15:59 +0000)]
Auto merge of #6963 - ehuss:doc-inequality, r=alexcrichton
Change docs "inequality" for semver requirement.
I can see how "inequality" may be confusing. I considered a few other words ("operator", "range", "relational"), but settled on "comparison" since it conveys that it is *comparing* against a value. npm uses the term "comparator".
Eh2406 [Mon, 20 May 2019 15:14:09 +0000 (11:14 -0400)]
add pub-piv prop tests.
This was supposed to be in #6653, but was lost in the edits of history.
Reconstructed from https://github.com/Eh2406/cargo/commit/5522aba5e8875d9c9e14eb66b5469ad481cba7a1
bors [Mon, 20 May 2019 14:22:59 +0000 (14:22 +0000)]
Auto merge of #6959 - rust-lang:dependabot/cargo/im-rc-13.0.0, r=alexcrichton
Update im-rc requirement from 12.1.0 to 13.0.0
Updates the requirements on [im-rc](https://github.com/bodil/im-rs) to permit the latest version.
<details>
<summary>Release notes</summary>
*Sourced from [im-rc's releases](https://github.com/bodil/im-rs/releases).*
> ## 13.0.0
> The minimum supported Rust version is now 1.34.0.
>
> ### Changed
>
> - `im::iter::unfold` now gives you the owned state value rather than an immutable reference to it, which makes it a little more useful.
>
> ### Removed
>
> - The deprecated `singleton` constructors have been removed. Please use `unit` instead.
> - The deprecated methods `Vector::chunks` and `Vector::chunks_mut` have been removed in favour of `Vector::leaves` and `Vector::leaves_mut` respectively. ([#50](https://github-redirect.dependabot.com/bodil/im-rs/issues/50))
> - The deprecated reference to [`sized-chunks`](https://crates.io/crates/sized-chunks) has been removed. If you need it, please use the `sized-chunks` crate directly.
> - `im::iter::unfold_mut` has been removed, as there's no meaningful difference between it and rust-std 1.34.0's `std::iter::from_fn` with a captured state variable.
>
> ### Fixed
>
> - `Vector` now uses [`sized_chunks::InlineArray`](https://docs.rs/sized-chunks/0.3.0/sized_chunks/inline_array/struct.InlineArray.html) instead of an `Empty` enum case to avoid allocation at very small sizes, letting you store a handful of elements on the stack before needing to grow into a full chunk. This has a beneficial effect on performance as well, as there's no pointer into the heap to dereference, making it faster than `std::vec::Vec` in this configuration.
> - Some complexity timings have been added and corrected. ([#87](https://github-redirect.dependabot.com/bodil/im-rs/issues/87))
> - `OrdSet::is_subset(&self, other)` now returns immediately when `self` is larger than `other` and thus could not possibly be a subset of it. ([#87](https://github-redirect.dependabot.com/bodil/im-rs/issues/87))
</details>
<details>
<summary>Changelog</summary>
*Sourced from [im-rc's changelog](https://github.com/bodil/im-rs/blob/master/CHANGELOG.md).*
> ## [13.0.0] - 2019-05-18
>
> The minimum supported Rust version is now 1.34.0.
>
> ### Changed
>
> - `im::iter::unfold` now gives you the owned state value rather than an
> immutable reference to it, which makes it a little more useful.
>
> ### Removed
>
> - The deprecated `singleton` constructors have been removed. Please use `unit`
> instead.
> - The deprecated methods `Vector::chunks` and `Vector::chunks_mut` have been
> removed in favour of `Vector::leaves` and `Vector::leaves_mut` respectively.
> ([#50](https://github-redirect.dependabot.com/bodil/im-rs/issues/50))
> - The deprecated reference to [`sized-chunks`](https://crates.io/crates/sized-chunks)
> has been removed. If you need it, please use the `sized-chunks` crate directly.
> - `im::iter::unfold_mut` has been removed, as there's no meaningful difference
> between it and rust-std 1.34.0's `std::iter::from_fn` with a captured state
> variable.
>
> ### Fixed
>
> - `Vector` now uses
> [`sized_chunks::InlineArray`](https://docs.rs/sized-chunks/0.3.0/sized_chunks/inline_array/struct.InlineArray.html)
> instead of an `Empty` enum case to avoid allocation at very small sizes,
> letting you store a handful of elements on the stack before needing to grow
> into a full chunk. This has a beneficial effect on performance as well, as
> there's no pointer into the heap to dereference, making it faster than
> `std::vec::Vec` in this configuration.
> - Some complexity timings have been added and corrected. ([#87](https://github-redirect.dependabot.com/bodil/im-rs/issues/87))
> - `OrdSet::is_subset(&self, other)` now returns immediately when `self` is
> larger than `other` and thus could not possibly be a subset of it. ([#87](https://github-redirect.dependabot.com/bodil/im-rs/issues/87))
>
> ## [12.3.4] - 2019-04-08
>
> ### Changed
>
> - `Clone` constraints have been further relaxed on maps and sets, so that you
> can now lookup and iterate over them without requiring a `Clone` constraint
> (though you do still need `Clone` to actually insert data into them to lookup
> or iterate over). ([#81](https://github-redirect.dependabot.com/bodil/im-rs/issues/81))
>
> ### Fixed
>
> - Enforces the latest bugfix release of sized-chunks. ([#78](https://github-redirect.dependabot.com/bodil/im-rs/issues/78))
> - Another edge case bugfix to `Vector`'s size table handling. ([#79](https://github-redirect.dependabot.com/bodil/im-rs/issues/79))
>
> ## [12.3.3] - 2019-03-11
></tr></table> ... (truncated)
</details>
<details>
<summary>Commits</summary>
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot ignore this [patch|minor|major] version` will close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language
- `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme
Additionally, you can set the following in your Dependabot [dashboard](https://app.dependabot.com):
- Update frequency (including time of day and day of week)
- Automerge options (never/patch/minor, and dev/runtime dependencies)
- Pull request limits (per update run and/or open at any time)
- Out-of-range updates (receive only lockfile updates, if desired)
- Security updates (receive only security updates, if desired)
Finally, you can contact us by mentioning @dependabot.
dependabot[bot] [Mon, 20 May 2019 05:41:28 +0000 (05:41 +0000)]
Update im-rc requirement from 12.1.0 to 13.0.0
Updates the requirements on [im-rc](https://github.com/bodil/im-rs) to permit the latest version.
- [Release notes](https://github.com/bodil/im-rs/releases)
- [Changelog](https://github.com/bodil/im-rs/blob/master/CHANGELOG.md)
- [Commits](https://github.com/bodil/im-rs/compare/12.1.0...13.0.0)
bors [Fri, 17 May 2019 21:37:12 +0000 (21:37 +0000)]
Auto merge of #6953 - vlad20012:add-doctest-field-to-metadata, r=alexcrichton
Add `doctest` field into metadata
Some tools can support rust doctests (e.g. highlighting
or launching). So it should be possible to find out if
doctests are enabled for a target or not. This commit
adds `doctest` field to `cargo metadata` output.
Related to https://github.com/intellij-rust/intellij-rust/issues/3852
vlad20012 [Fri, 17 May 2019 15:33:53 +0000 (18:33 +0300)]
Add `doctest` field into metadata
Some tools can support rust doctests (e.g. highlighting
or launching). So it should be possible to find out if
doctests are enabled for a target or not. This commit
adds `doctest` field to `cargo metadata` output.
bors [Wed, 15 May 2019 19:26:22 +0000 (19:26 +0000)]
Auto merge of #6946 - Eh2406:remove_candidate, r=alexcrichton
Remove Candidate
`Candidate` was a type to record the possibility that a package was replaced using the replacements feature. However there were only two places that cared about this possibility. One was switched to used a lookup table in #6860. This PR switches the other to use that table as well. Making the entire `Candidate` type unnecessary.
The main benefit of this change is a reduction in the cognitive complexity.
bors [Tue, 14 May 2019 21:50:44 +0000 (21:50 +0000)]
Auto merge of #6936 - sgrif:sg-timeout-error, r=alexcrichton
Give a better error message when crates.io requests time out
crates.io is hosted on Heroku, which means we have a hard 30 second time
limit on all requests. Typically this is only hit when someone is
attempting to upload a crate so large that it would have been eventually
rejected anyway, but it can also happen if a user is on a very slow
internet connection.
When this happens, the request is terminated by the platform and we have
no control over the response that gets sent. This results in the user
getting a very unhelpful error message from Cargo, and some generic
error page HTML spat out into their terminal. We could work around this
on our end by adding a 29 second timeout *somewhere else* in the stack,
but we have a lot of layers that buffer requests to protect against slow
client attacks, and it'd be a pretty decent amount of work. Since we
eventually want to switch over to having Cargo do the S3 upload instead
of us, it doesn't make sense to spend so much time on an error scenario
that eventually will go away.
I've tried to keep this uncoupled from crates.io as much as possible,
since alternate registries might not be hosted on Heroku or have the
same restricitions. But I figure "a 503 that took more than 30 seconds"
is a safe bet on this being hit. If we're ok with coupling this to
crates.io, I'd like to include "If your crate is less than 10MB you can
email help@crates.io for assistance" in the error message.
bors [Tue, 14 May 2019 15:53:49 +0000 (15:53 +0000)]
Auto merge of #6940 - alexcrichton:readonly-compat, r=ehuss
Re-enable compatibility with readonly CARGO_HOME
Previously Cargo would attempt to work as much as possible with a
previously filled out CARGO_HOME, even if it was mounted as read-only.
In #6880 this was regressed as a few global locks and files were always
attempted to be opened in writable mode.
This commit fixes these issues by correcting two locations:
* First the global package cache lock has error handling to allow
acquiring the lock in read-only mode inaddition to read/write mode. If
the read/write mode failed due to an error that looks like a readonly
filesystem then we assume everything in the package cache is readonly
and we switch to just acquiring any lock, this time a shared readonly
one. We in theory aren't actually doing any synchronization at that
point since it's all readonly anyway.
* Next when unpacking package we're careful to issue a `stat` call
before opening a file in writable mode. This way our preexisting guard
to return early if a package is unpacked will succeed before we open
anything in writable mode.
Alex Crichton [Tue, 14 May 2019 14:30:10 +0000 (07:30 -0700)]
Re-enable compatibility with readonly CARGO_HOME
Previously Cargo would attempt to work as much as possible with a
previously filled out CARGO_HOME, even if it was mounted as read-only.
In #6880 this was regressed as a few global locks and files were always
attempted to be opened in writable mode.
This commit fixes these issues by correcting two locations:
* First the global package cache lock has error handling to allow
acquiring the lock in read-only mode inaddition to read/write mode. If
the read/write mode failed due to an error that looks like a readonly
filesystem then we assume everything in the package cache is readonly
and we switch to just acquiring any lock, this time a shared readonly
one. We in theory aren't actually doing any synchronization at that
point since it's all readonly anyway.
* Next when unpacking package we're careful to issue a `stat` call
before opening a file in writable mode. This way our preexisting guard
to return early if a package is unpacked will succeed before we open
anything in writable mode.
Sean Griffin [Mon, 13 May 2019 20:18:42 +0000 (14:18 -0600)]
Give a better error message when crates.io requests time out
crates.io is hosted on Heroku, which means we have a hard 30 second time
limit on all requests. Typically this is only hit when someone is
attempting to upload a crate so large that it would have been eventually
rejected anyway, but it can also happen if a user is on a very slow
internet connection.
When this happens, the request is terminated by the platform and we have
no control over the response that gets sent. This results in the user
getting a very unhelpful error message from Cargo, and some generic
error page HTML spat out into their terminal. We could work around this
on our end by adding a 29 second timeout *somewhere else* in the stack,
but we have a lot of layers that buffer requests to protect against slow
client attacks, and it'd be a pretty decent amount of work. Since we
eventually want to switch over to having Cargo do the S3 upload instead
of us, it doesn't make sense to spend so much time on an error scenario
that eventually will go away.
I've tried to keep this uncoupled from crates.io as much as possible,
since alternate registries might not be hosted on Heroku or have the
same restricitions. But I figure "a 503 that took more than 30 seconds"
is a safe bet on this being hit. If we're ok with coupling this to
crates.io, I'd like to include "If your crate is less than 10MB you can
email help@crates.io for assistance" in the error message.
bors [Mon, 13 May 2019 13:31:30 +0000 (13:31 +0000)]
Auto merge of #6934 - ehuss:stabilize-offline, r=alexcrichton
Stabilize offline mode.
This stabilizes the `--offline` flag as detailed at https://github.com/rust-lang/cargo/issues/5655#issuecomment-488347426. It also adds the `net.offline` config value.
bors [Fri, 10 May 2019 15:03:12 +0000 (15:03 +0000)]
Auto merge of #6924 - ehuss:include-exclude-patterns, r=alexcrichton
Migrate package include/exclude to gitignore patterns.
This moves to the next phase of #4268.
This also includes a fdew more changes which can be removed if desired:
- Add support for `!` negate gitignore patterns.
- Add a warning if both package.include and package.exclude are specified.
bors [Fri, 10 May 2019 14:36:30 +0000 (14:36 +0000)]
Auto merge of #6883 - alexcrichton:pipelining-v2, r=ehuss
Implement the Cargo half of pipelined compilation (take 2)
This commit starts to lay the groundwork for #6660 where Cargo will
invoke rustc in a "pipelined" fashion. The goal here is to execute one
command to produce both an `*.rmeta` file as well as an `*.rlib` file
for candidate compilations. In that case if another rlib depends on that
compilation, then it can start as soon as the `*.rmeta` is ready and not
have to wait for the `*.rlib` compilation.
Initially attempted in #6864 with a pretty invasive refactoring this
iteration is much more lightweight and fits much more cleanly into
Cargo's backend. The approach taken here is to update the
`DependencyQueue` structure to carry a piece of data on each dependency
edge. This edge information represents the artifact that one node
requires from another, and then we a node has no outgoing edges it's
ready to build.
A dependency on a metadata file is modeled as just that, a dependency on
just the metadata and not the full build itself. Most of cargo's backend
doesn't really need to know about this edge information so it's
basically just calculated as we insert nodes into the `DependencyQueue`.
Once that's all in place it's just a few pieces here and there to
identify compilations that *can* be pipelined and then they're wired up
to depend on the rmeta file instead of the rlib file.
bors [Fri, 10 May 2019 13:44:03 +0000 (13:44 +0000)]
Auto merge of #6925 - ehuss:package-include-manifest, r=alexcrichton
Always include `Cargo.toml` when packaging.
Since `Cargo.toml` is required, might as well include it automatically rather than force everyone to include it explicitly. If it is not listed in `include`, there was a somewhat confusing error message when packaging.
Alex Crichton [Wed, 8 May 2019 18:28:05 +0000 (11:28 -0700)]
Fix fingerprint handling in pipelining mode
This commit fixes an issue when pipelining mode is used in handling
recompilations. Previously a sequence of compilations could look like:
* Crate A starts to build
* Crate A produces metadata
* Crate B, which depends on A, starts
* Crate B finishes
* Crate A finishes
In this case the mtime for B is before that of A, which fooled Cargo
into thinking that B needed to be recompiled. In this case, however, B
doesn't actually need to be recompiled because it only depends on the
metadata of A, not the final artifacts.
This unfortunately resulted in some duplication in a few places, but not
really much moreso than already exists between fingerprinting and compilation.
Alex Crichton [Tue, 30 Apr 2019 18:37:24 +0000 (11:37 -0700)]
Parse rmeta directives coming from rustc
This commit updates Cargo to process JSON directives emitted by rustc
when we're pipelining compilation. In this mode Cargo will attempt to
start subsequent compilations of crates as soon as possible, fully
completing the features of pipelined compilations in Cargo!
Alex Crichton [Tue, 30 Apr 2019 18:30:49 +0000 (11:30 -0700)]
Route rendered JSON diagnostics from rustc through Cargo
This commit updates Cargo's behavior when it is printing "human
readable" error messages when paired with pipelined compilation. In this
mode Cargo needs to switch rustc into JSON mode to get a JSON directive
message when metadata is ready, but we still want to produce human
readable error messages if they crop up. As a result parse a bit of JSON
coming out of rustc, if any, and ensure that everything is configured
correctly along the way.
Alex Crichton [Tue, 30 Apr 2019 17:59:25 +0000 (10:59 -0700)]
Refactor routing output from rustc/rustdoc
This commit refactors slightly how we actually spawn rustc/rustdoc
processes and how their output is routed. Over time lots has changed
around this, but it turns out that we unconditionally capture all output
from the compiler/rustdoc today, no exceptions. As a result simplify the
various execution functions in the `Executor` trait as well as branches
for emitting json messages. Instead throw everything in the same bucket
and just always look for lines that start with `{` which indicate a
JSON message.
This also fixes a few issues where output printed in each thread is now
routed through the main coordinator thread to handle updating the
progress bar if necessary.
Alex Crichton [Fri, 26 Apr 2019 20:53:51 +0000 (13:53 -0700)]
Implement the Cargo half of pipelined compilation
This commit starts to lay the groundwork for #6660 where Cargo will
invoke rustc in a "pipelined" fashion. The goal here is to execute one
command to produce both an `*.rmeta` file as well as an `*.rlib` file
for candidate compilations. In that case if another rlib depends on that
compilation, then it can start as soon as the `*.rmeta` is ready and not
have to wait for the `*.rlib` compilation.
Initially attempted in #6864 with a pretty invasive refactoring this
iteration is much more lightweight and fits much more cleanly into
Cargo's backend. The approach taken here is to update the
`DependencyQueue` structure to carry a piece of data on each dependency
edge. This edge information represents the artifact that one node
requires from another, and then we a node has no outgoing edges it's
ready to build.
A dependency on a metadata file is modeled as just that, a dependency on
just the metadata and not the full build itself. Most of cargo's backend
doesn't really need to know about this edge information so it's
basically just calculated as we insert nodes into the `DependencyQueue`.
Once that's all in place it's just a few pieces here and there to
identify compilations that *can* be pipelined and then they're wired up
to depend on the rmeta file instead of the rlib file.
bors [Mon, 6 May 2019 20:47:49 +0000 (20:47 +0000)]
Auto merge of #6910 - Eh2406:small-things, r=alexcrichton
Small things
This has two small changes that are worth saving from my most recent attempt to speedup https://github.com/rust-lang/cargo/issues/6258#issuecomment-479204465:
1. This removes the `ConflictCache::contains` added in #6776. Replacing it with a more general and easier to explain system based on the existing `ConflictCache::find_conflicting`.
2. This adds code to print the used part of the input for failing resolver tests. This is very helpful when
1. The proptest shrinking algorithm is interrupted, at least you have the smallest one found so far.
2. Hand minimizing, remove a dep and it will tell you all the packages that are no longer needed for the test to fail.
bors [Mon, 6 May 2019 20:08:45 +0000 (20:08 +0000)]
Auto merge of #6912 - alexcrichton:fix-parse, r=Eh2406
Fix skipping over invalid registry packages
This accidentally regressed in the previous caching PR for Cargo.
Invalid lines of JSON in the registry are intended to be skipped over,
but when skipping we forgot to update some indices which meant that all
future versions would fail to parse as well!
Alex Crichton [Mon, 6 May 2019 18:35:17 +0000 (11:35 -0700)]
Fix skipping over invalid registry packages
This accidentally regressed in the previous caching PR for Cargo.
Invalid lines of JSON in the registry are intended to be skipped over,
but when skipping we forgot to update some indices which meant that all
future versions would fail to parse as well!
bors [Sun, 5 May 2019 21:34:46 +0000 (21:34 +0000)]
Auto merge of #6905 - ArifRoktim:fork/bash_complete, r=ehuss
Fixes #6874
Bash completion for cargo on the latest version of stock macOS produced syntax errors. More info in #6874 . This PR should fix that, but as I don't have any apple devices, I can't test it.
Pinging @jimmycuadra or anyone who runs macOS: If you have the time, could you please check if applying the commit in this PR fixes the syntax error when running the stock bash that comes with macOS?
Quick one-liner to apply the commit would be:
```bash
patch -d "$(rustc --print sysroot)/etc/bash_completion.d/" cargo <(curl https://github.com/rust-lang/cargo/commit/e2c519dd7ac61e4d2f94cad60ef920ce4aa1718f.patch)
```
Once this PR is confirmed to work, it can marked as ready.
bors [Fri, 3 May 2019 14:37:34 +0000 (14:37 +0000)]
Auto merge of #6880 - alexcrichton:cache, r=Eh2406
Parse less JSON on null builds
This commit fixes a performance pathology in Cargo today. Whenever Cargo
generates a lock file (which happens on all invocations of `cargo build`
for example) Cargo will parse the crates.io index to learn about
dependencies. Currently, however, when it parses a crate it parses the
JSON blob for every single version of the crate. With a lock file,
however, or with incremental builds only one of these lines of JSON is
relevant. Measured today Cargo building Cargo parses 3700 JSON
dependencies in the registry.
This commit implements an optimization that brings down the number of
parsed JSON lines in the registry to precisely the right number
necessary to build a project. For example Cargo has 150 crates in its
lock file, so now it only parses 150 JSON lines (a 20x reduction from
3700). This in turn can greatly improve Cargo's null build time. Cargo
building Cargo dropped from 120ms to 60ms on a Linux machine and 400ms
to 200ms on a Mac.
The commit internally has a lot more details about how this is done but
the general idea is to have a cache which is optimized for Cargo to read
which is maintained automatically by Cargo.
Alex Crichton [Tue, 30 Apr 2019 21:38:55 +0000 (14:38 -0700)]
Add debug assertions for cache contents
This will largely only get tested during Cargo's own tests, but this
commit adds debug assertions where the cache of registry JSON files is
always valid and up to date when we consider it being up to date.
Alex Crichton [Tue, 30 Apr 2019 21:23:04 +0000 (14:23 -0700)]
Avoid using mtime information for reusing cache files
Using mtime information is pretty finnicky across platforms, so instead
take a different strategy where we embed the sha that a cache file was
generated from into the cache file itself. If the registry's sha has
changed then we regenerate the cache file, otherwise we can reuse the
cache file.
This should make cache file generation more robust (any command can
generate a cache file to get used at any time) as well as works better
across platforms (doesn't run into issues with coarse mtime systems and
the like).
projects / cargo.git / log