Add new cargo stable benchmark

Author: Kobzol

collector/compile-benchmarks/README.md

@@ -140,6 +140,9 @@ Rust code being written today.
 
 - **encoding**: An old crate providing character encoding support. Contains
   some large tables.
+- **cargo**: An old version of Cargo, corresponding to the 1.24.0 Rust release.
+  Two of its dependencies (`socket2` and `url`) had to be vendored, to provide patches
+  so that it can compile with old rustc.
 - **futures**: v0.1.0 of the popular `futures` crate, which was used by many
   Rust programs. Newer versions of this crate (e.g. v0.3.21 from February 2021)
   contain very little code, instead relying on sub-crates. This makes them less

collector/compile-benchmarks/REUSE.toml

@@ -27,6 +27,21 @@ path = "bitmaps-3.2.1-new-solver/**"
 SPDX-License-Identifier = "MPL-2.0"
 SPDX-FileCopyrightText = "Bodil Stokke"
 
+[[annotations]]
+path = "cargo/**"
+SPDX-FileCopyrightText = "The Rust Project Developers (see https://thanks.rust-lang.org)"
+SPDX-License-Identifier = "MIT OR Apache-2.0"
+
+[[annotations]]
+path = "cargo/socket2-0.2.3/**"
+SPDX-FileCopyrightText = "Alex Crichton"
+SPDX-License-Identifier = "MIT OR Apache-2.0"
+
+[[annotations]]
+path = "cargo/url-1.5.1/**"
+SPDX-FileCopyrightText = "The rust-url developers"
+SPDX-License-Identifier = "MIT OR Apache-2.0"
+
 [[annotations]]
 path = "cargo-0.87.1/**"
 SPDX-FileCopyrightText = "The Rust Project Developers (see https://thanks.rust-lang.org)"

collector/compile-benchmarks/cargo/.gitignore

@@ -0,0 +1,14 @@
+/target
+.cargo
+/config.stamp
+/Makefile
+/config.mk
+src/doc/build
+src/etc/*.pyc
+src/registry/target
+src/registry/Cargo.lock
+rustc
+__pycache__
+.idea/
+*.iml
+*.swp

collector/compile-benchmarks/cargo/.travis.yml

@@ -0,0 +1,60 @@
+language: rust
+rust: stable
+sudo: required
+dist: trusty
+
+git:
+  depth: 1
+
+cache:
+  directories:
+    - $HOME/.cargo/bin/
+
+matrix:
+  include:
+    - env: TARGET=x86_64-unknown-linux-gnu
+           ALT=i686-unknown-linux-gnu
+    - env: TARGET=x86_64-apple-darwin
+           ALT=i686-apple-darwin
+      os: osx
+
+    - env: TARGET=x86_64-unknown-linux-gnu
+           ALT=i686-unknown-linux-gnu
+      rust: beta
+
+    - env: TARGET=x86_64-unknown-linux-gnu
+           ALT=i686-unknown-linux-gnu
+      rust: nightly
+      install:
+        - mdbook --help || cargo install mdbook --force
+      script:
+        - cargo test
+        - cargo doc --no-deps
+        - sh src/ci/dox.sh
+      after_success: |
+        [ $TRAVIS_BRANCH = master ] &&
+        [ $TRAVIS_PULL_REQUEST = false ] &&
+        [ $(uname -s) = Linux ] &&
+        pip install ghp-import --user &&
+        $HOME/.local/bin/ghp-import -n target/doc &&
+        git push -qf https://${GH_TOKEN}@github.com/${TRAVIS_REPO_SLUG}.git gh-pages 2>&1 >/dev/null
+
+  exclude:
+    - rust: stable
+
+before_script:
+  - rustup target add $ALT
+script:
+  - cargo test
+
+env:
+  global:
+    - secure: "hWheSLilMM4DXChfSy2XsDlLw338X2o+fw8bE590xxU2TzngFW8GUfq7lGfZEp/l4SNNIS6ROU/igyttCZtxZMANZ4aMQZR5E8Fp4yPOyE1pZLDH/LdQVXnROsfburQJeq+GIYIbZ01Abzh5ClpgLg5KX0H627uj063zZ7Ljo/w="
+
+notifications:
+  email:
+    on_success: never
+addons:
+  apt:
+    packages:
+      - gcc-multilib

collector/compile-benchmarks/cargo/0-println.patch

@@ -0,0 +1,13 @@
+diff --git a/src/cargo/lib.rs b/src/cargo/lib.rs
+index f20118b8..350d8e47 100755
+--- a/src/cargo/lib.rs
++++ b/src/cargo/lib.rs
+@@ -98,6 +98,8 @@ impl fmt::Display for VersionInfo {
+             }
+         };
+ 
++        println!("testing");
++
+         if let Some(ref cfg) = self.cfg_info {
+             if let Some(ref ci) = cfg.commit_info {
+                 write!(f, " ({} {})",

collector/compile-benchmarks/cargo/ARCHITECTURE.md

@@ -0,0 +1,90 @@
+# Cargo Architecture
+
+This document gives a high level overview of Cargo internals. You may
+find it useful if you want to contribute to Cargo or if you are
+interested in the inner workings of Cargo.
+
+
+## Subcommands
+
+Cargo is organized as a set of subcommands. All subcommands live in
+`src/bin` directory. However, only `src/bin/cargo.rs` file produces an
+executable, other files inside the `bin` directory are submodules. See
+`src/bin/cargo.rs` for how these subcommands get wired up with the
+main executable.
+
+A typical subcommand, such as `src/bin/build.rs`, parses command line
+options, reads the configuration files, discovers the Cargo project in
+the current directory and delegates the actual implementation to one
+of the functions in `src/cargo/ops/mod.rs`. This short file is a good
+place to find out about most of the things that Cargo can do.
+
+
+## Important Data Structures
+
+There are some important data structures which are used throughout
+Cargo.
+
+`Config` is available almost everywhere and holds "global"
+information, such as `CARGO_HOME` or configuration from
+`.cargo/config` files. The `shell` method of `Config` is the entry
+point for printing status messages and other info to the console.
+
+`Workspace` is the description of the workspace for the current
+working directory. Each workspace contains at least one
+`Package`. Each package corresponds to a single `Cargo.toml`, and may
+define several `Target`s, such as the library, binaries, integration
+test or examples. Targets are crates (each target defines a crate
+root, like `src/lib.rs` or `examples/foo.rs`) and are what is actually
+compiled by `rustc`.
+
+A typical package defines the single library target and several
+auxiliary ones. Packages are a unit of dependency in Cargo, and when
+package `foo` depends on package `bar`, that means that each target
+from `foo` needs the library target from `bar`.
+
+`PackageId` is the unique identifier of a (possibly remote)
+package. It consist of three components: name, version and source
+id. Source is the place where the source code for package comes
+from. Typical sources are crates.io, a git repository or a folder on
+the local hard drive.
+
+`Resolve` is the representation of a directed acyclic graph of package
+dependencies, which uses `PackageId`s for nodes. This is the data
+structure that is saved to the lock file. If there is no lockfile,
+Cargo constructs a resolve by finding a graph of packages which
+matches declared dependency specification according to semver.
+
+
+## Persistence
+
+Cargo is a non-daemon command line application, which means that all
+the information used by Cargo must be persisted on the hard drive. The
+main sources of information are `Cargo.toml` and `Cargo.lock` files,
+`.cargo/config` configuration files and the globally shared registry
+of packages downloaded from crates.io, usually located at
+`~/.cargo/registry`. See `src/sources/registry` for the specifics of
+the registry storage format.
+
+
+## Concurrency
+
+Cargo is mostly single threaded. The only concurrency inside a single
+instance of Cargo happens during compilation, when several instances
+of `rustc` are invoked in parallel to build independent
+targets. However there can be several different instances of Cargo
+process running concurrently on the system. Cargo guarantees that this
+is always safe by using file locks when accessing potentially shared
+data like the registry or the target directory.
+
+
+## Tests
+
+Cargo has an impressive test suite located in the `tests` folder. Most
+of the test are integration: a project structure with `Cargo.toml` and
+rust source code is created in a temporary directory, `cargo` binary
+is invoked via `std::process::Command` and then stdout and stderr are
+verified against the expected output. To simplify testing, several
+macros of the form `[MACRO]` are used in the expected output. For
+example, `[..]` matches any string and `[/]` matches `/` on Unixes and
+`\` on windows.

collector/compile-benchmarks/cargo/CONTRIBUTING.md

@@ -0,0 +1,173 @@
+# Contributing to Cargo
+
+Thank you for your interest in contributing to Cargo! Good places to
+start are this document, [ARCHITECTURE.md](ARCHITECTURE.md), which
+describes the high-level structure of Cargo and [E-easy] bugs on the
+issue tracker.
+
+If you have a general question about Cargo or it's internals, feel free to ask
+on [IRC].
+
+## Code of Conduct
+
+All contributors are expected to follow our [Code of Conduct].
+
+## Bug reports
+
+We can't fix what we don't know about, so please report problems liberally. This
+includes problems with understanding the documentation, unhelpful error messages
+and unexpected behavior.
+
+**If you think that you have identified an issue with Cargo that might compromise
+its users' security, please do not open a public issue on GitHub. Instead,
+we ask you to refer to Rust's [security policy].**
+
+Opening an issue is as easy as following [this
+link][new-issues] and filling out the fields.
+Here's a template that you can use to file an issue, though it's not necessary to
+use it exactly:
+
+    <short summary of the problem>
+
+    I tried this: <minimal example that causes the problem>
+
+    I expected to see this happen: <explanation>
+
+    Instead, this happened: <explanation>
+
+    I'm using <output of `cargo --version`>
+
+All three components are important: what you did, what you expected, what
+happened instead. Please use https://gist.github.com/ if your examples run long.
+
+## Working on issues
+
+If you're looking for somewhere to start, check out the [E-easy][E-Easy] tag.
+
+Feel free to ask for guidelines on how to tackle a problem on [IRC] or open a
+[new issue][new-issues]. This is especially important if you want to add new
+features to Cargo or make large changes to the already existing code-base.
+Cargo's core developers will do their best to provide help.
+
+If you start working on an already-filed issue, post a comment on this issue to
+let people know that somebody is working it. Feel free to ask for comments if
+you are unsure about the solution you would like to submit.
+
+While Cargo does make use of some Rust-features available only through the
+`nightly` toolchain, it must compile on stable Rust. Code added to Cargo
+is encouraged to make use of the latest stable features of the language and
+`stdlib`.
+
+We use the "fork and pull" model [described here][development-models], where
+contributors push changes to their personal fork and create pull requests to
+bring those changes into the source repository. This process is partly
+automated: Pull requests are made against Cargo's master-branch, tested and
+reviewed. Once a change is approved to be merged, a friendly bot merges the
+changes into an internal branch, runs the full test-suite on that branch
+and only then merges into master. This ensures that Cargo's master branch
+passes the test-suite at all times.
+
+Your basic steps to get going:
+
+* Fork Cargo and create a branch from master for the issue you are working on.
+* Please adhere to the code style that you see around the location you are
+working on.
+* [Commit as you go][githelp].
+* Include tests that cover all non-trivial code. The existing tests
+in `test/` provide templates on how to test Cargo's behavior in a
+sandbox-environment. The internal crate `cargotest` provides a vast amount
+of helpers to minimize boilerplate.
+* Make sure `cargo test` passes. If you do not have the cross-compilers
+installed locally, ignore the cross-compile test failures or disable them by
+using `CFG_DISABLE_CROSS_TESTS=1 cargo test`. Note that some tests are enabled
+only on `nightly` toolchain. If you can, test both toolchains.
+* Push your commits to GitHub and create a pull request against Cargo's
+`master` branch.
+
+## Pull requests
+
+After the pull request is made, a friendly bot will automatically assign a
+reviewer; the review-process will make sure that the proposed changes are
+sound. Please give the assigned reviewer sufficient time, especially during
+weekends. If you don't get a reply, you may poke the core developers on [IRC].
+
+A merge of Cargo's master-branch and your changes is immediately queued
+to be tested after the pull request is made. In case unforeseen
+problems are discovered during this step (e.g. a failure on a platform you
+originally did not develop on), you may ask for guidance. Push additional
+commits to your branch to tackle these problems.
+
+The reviewer might point out changes deemed necessary. Please add them as
+extra commits; this ensures that the reviewer can see what has changed since
+the code was previously reviewed. Large or tricky changes may require several
+passes of review and changes.
+
+Once the reviewer approves your pull request, a friendly bot picks it up
+and [merges][mergequeue] it into Cargo's `master` branch.
+
+## Contributing to the documentation
+
+To contribute to the documentation, all you need to do is change the markdown
+files in the `src/doc` directory. To view the rendered version of changes you
+have made locally, run:
+
+```sh
+sh src/ci/dox.sh
+open target/doc/index.html
+```
+
+
+## Issue Triage
+
+Sometimes an issue will stay open, even though the bug has been fixed. And
+sometimes, the original bug may go stale because something has changed in the
+meantime.
+
+It can be helpful to go through older bug reports and make sure that they are
+still valid. Load up an older issue, double check that it's still true, and
+leave a comment letting us know if it is or is not. The [least recently
+updated sort][lru] is good for finding issues like this.
+
+Contributors with sufficient permissions on the Rust-repository can help by
+adding labels to triage issues:
+
+* Yellow, **A**-prefixed labels state which **area** of the project an issue
+  relates to.
+
+* Magenta, **B**-prefixed labels identify bugs which are **blockers**.
+
+* Light purple, **C**-prefixed labels represent the **category** of an issue.
+
+* Dark purple, **Command**-prefixed labels mean the issue has to do with a
+  specific cargo command.
+
+* Green, **E**-prefixed labels explain the level of **experience** or
+  **effort** necessary to fix the issue. [**E-mentor**][E-mentor] issues also
+  have some instructions on how to get started.
+
+* Red, **I**-prefixed labels indicate the **importance** of the issue. The
+  [I-nominated][inom] label indicates that an issue has been nominated for
+  prioritizing at the next triage meeting.
+
+* Purple gray, **O**-prefixed labels are the **operating system** or platform
+  that this issue is specific to.
+
+* Orange, **P**-prefixed labels indicate a bug's **priority**. These labels
+  are only assigned during triage meetings and replace the [I-nominated][inom]
+  label.
+
+* The light orange **relnotes** label marks issues that should be documented in
+  the release notes of the next release.
+
+
+[githelp]: https://dont-be-afraid-to-commit.readthedocs.io/en/latest/git/commandlinegit.html
+[development-models]: https://help.github.com/articles/about-collaborative-development-models/
+[gist]: https://gist.github.com/
+[new-issues]: https://github.com/rust-lang/cargo/issues/new
+[mergequeue]: https://buildbot2.rust-lang.org/homu/queue/cargo
+[security policy]: https://www.rust-lang.org/security.html
+[lru]: https://github.com/rust-lang/cargo/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc
+[E-easy]: https://github.com/rust-lang/cargo/labels/E-easy
+[E-mentor]: https://github.com/rust-lang/cargo/labels/E-mentor
+[Code of Conduct]: https://www.rust-lang.org/conduct.html
+[IRC]: https://kiwiirc.com/client/irc.mozilla.org/cargo