Add a profile option to select the codegen backend
This makes it possible to compile only specific crates with a certain codegen backend.
I have tested this by compiling Bevy with cg_llvm, but one of the examples using cg_clif.
By the way I noticed that many unstable profile options are not checked when using profile overrides.
There are already similar preexisting test helpers which
also work on windows. Port over the executable-creation
helper into the file() helper and things appear to pass.
Fix version string.
The version string for `cargo version` was inadvertently changed in #9657 so that it does not include the leading `cargo` as in `cargo 1.53.0 (4369396ce 2021-04-27)`.
Allow publishing from workspace root.
Adds -p, --workspace, and --exclude to package and publish commands.
Uses ephemeral workspaces to avoid changing the existing functions too much.
There might be more `Finished dev [unoptimized + debuginfo] target` messages when packaging than there should be, I couldn't figure out what was generating them.
The tests aren't super extensive, as all the specs from arguments code should already be tested elsewhere.
Closes#7345
Stabilize the rustc-link-arg option
This change removes the unstable option (tracked by #9426) and unconditionally accepts additional linker arguments (as implemented in #7811 and #8441). Documentation is moved from unstable to what appeared to be the correct location.
I am not aware of any significant concerns with the option and it appears consistent with some other existing stable linker options.
Please let me know if this is not the appropriate process or if there is anything that I am missing from the PR.
Update should_use_metadata function
* Correct the reason for not renaming dylibs
* Add todo for -install-name/-soname usage
* Limit wasm32 executable metadata omission to emscripten. Wasm file don't contain any filename themself.
* Don't omit metadata for executables on macOS. backtrace-rs is now able to load debuginfo for renamed .dSYM files: ed3689c2f2/src/symbolize/gimli/macho.rs (L51-L65)
* Mention another reason to include the metadata hash for libstd.
Named profile updates
A few updates for named profiles to push them closer to stabilization:
- Disable the `dir-name` profile setting. `dir-name` primarily exists for translating the built-in profiles or sharing artifacts between profiles. In order to simplify the UI, we would like to not expose it to the user for the initial stabilization. The code to support it is kept in case we want to add it in the future.
- Reserve some profile names. Just to give a little flexibility in the future in case we want to use these, or that they could cause confusion. Also updated the error text a little.
- Add support for custom profiles to legacy commands. Their old behavior is still retained for backwards compatibility. That is:
* `cargo check`
* `--profile=test`: This forces the test mode. For example, `cargo check --lib --profile=test` will check the library as a unit test (with `--test`).
* `cargo fix`
* `--profile=test`: Forces test mode, same as above.
* `cargo rustc`
* `--profile=test`: Forces test mode, same as above.
* `--profile=bench`: Forces bench mode.
* `--profile=check`: Forces check mode.
- These commands also allow mixing the above options with `--release`, which is normally not allowed.
- Fix `cargo bench` to support the `--profile` option. I think it was just forgotten.
Deduplicate compiler diagnostics.
This adds some logic to deduplicate diagnostics emitted across rustc invocations. There are some situations where different targets can emit the same message, and that has caused confusion particularly for new users. A prominent example is running `cargo test` which will build the library twice concurrently (once as a normal library, and once as a test).
As part of this, the "N warnings emitted" message sent by rustc is intercepted, and instead cargo generates its own summary. This is to prevent potentially confusing situations where that message is either deduplicated, or wrong. It also provides a little more context to explain exactly *what* issued the warnings. Example:
```warning: `foo` (lib) generated 1 warning```
This only impacts human-readable output, it does not change JSON behavior.
Closes#9104
`cargo fix --edition`: extend warning when on latest edition
This extends the warning issued when `cargo fix --edition` is run when the user is already on the latest edition. Before #9184, there were instructions on what to do, but those probably should not have been completely removed. It seems likely that some users may get the steps out of order, so this hopefully tries to explain them clearly.
Add format option to `cargo tree` to print the lib_name
Adds a way to have `cargo tree` display the name of the library inside a package dependency, which can differ from the name of the package. Updates the `tree::format` test to test for its proper behavior.
Closes#9659
Prefer patched versions of dependencies
When selecting among several versions of a paackage, prefer versions
from `[patch]` sections over other versions, similar to how locked
versions are preferred.
Patches come in the form of a Dependency and not a PackageId, so this
preference is expressed with `prefer_patch_deps`, distinct from
`try_to_use`.
Fixes#9535
Spot the crate typo easily
ego tweak to make it easy to spot typos:
Before:
```
error: no matching package named `sc-consensus-primitivies` found
location searched: /Users/bit/p/substrate1/client/primitives/consensus/common
perhaps you meant: sc-consensus-primitives
required by package `sc-network v0.9.0 (/Users/bit/p/substrate1/client/network)`
```
After:
```
error: no matching package named `sc-consensus-primitivies` found
perhaps you meant: sc-consensus-primitives
location searched: /Users/bit/p/substrate1/client/primitives/consensus/common
required by package `sc-network v0.9.0 (/Users/bit/p/substrate1/client/network)`
```
This makes the following changes:
- Allows `cargo check`, `cargo fix`, and `cargo rustc` to support custom
named profiles. This retains the legacy behavior of those commands.
- Fixes `cargo bench` so that it supports custom named profiles.
Just to give a little flexibility in the future in case we want to use
these, or that they could cause confusion. Also updated the error text a
little.
dir-name primarily exists for translating the built-in profiles. In
order to simplify the UI, we would like to not expose it to the user for
the initial stabilization. The code to support it is kept in case we
want to add it in the future.
Serialize `cargo fix`
This changes `cargo fix` so that it only fixes one crate at a time. Previously, it would allow concurrent fixing across packages. This caused a problem if a workspace uses things like `#[path]` or `include!()` of a shared file between packages. A real-world example of this is serde, which has [this](9c39115f82/serde_derive_internals/lib.rs (L43-L45)) which reuses the some source files between the `serde` and `serde_derive` packages. Modifying those files concurrently causes corruption and the fix will fail.
Closes#6528
Update nightly failure notification.
This makes several changes to try to clarify errors with nightly requirements.
- Don't tell the user to edit `Cargo.toml` if it is not a local package. Things like registry packages are not under their control.
- Include the version number in the error message.
- Try to make better suggestions on what to do.
- Remove the redirects for stabilized features in unstable.md, and instead include a small stub that tells the user when it was stabilized and where to find more information. This should help with people using older releases which provide links to this page, to help them know which version they will need.
Closes#9610
Update Windows env uppercase key check.
This is the followup for #9646. Rust now correctly spawns processes with preserved casing on nightly on Windows, so the exceptions here are no longer needed.
When selecting among several versions of a paackage, prefer versions
from `[patch]` sections over other versions, similar to how locked
versions are preferred.
Patches come in the form of a Dependency and not a PackageId, so this
preference is expressed with `prefer_patch_deps`, distinct from
`try_to_use`.
This works by introspecting rustc's error output, using the JSON format
to determine whether it's a warning or error, then skipping it
altogether if it's a summary of the diagnostics printed.
Before:
```
src/main.rs:1:10: warning: trait objects without an explicit `dyn` are deprecated
src/main.rs:1:1: error[E0601]: `main` function not found in crate `wrong`
src/main.rs:1:9: error[E0038]: the trait `Clone` cannot be made into an object
error: aborting due to 2 previous errors; 1 warning emitted
error: could not compile `wrong`
```
After:
```
$ cargo check --message-format short
src/main.rs:1:10: warning: trait objects without an explicit `dyn` are deprecated
src/main.rs:1:1: error[E0601]: `main` function not found in crate `wrong`
src/main.rs:1:9: error[E0038]: the trait `Clone` cannot be made into an object
error: could not compile `wrong` due to 2 previous errors; 1 warning emitted
```
Include the linker in the fingerprint.
This adds the linker from the `[target]` config table to the fingerprint. Previously, changing the value would not trigger a rebuild.
Temporarily disable windows env test.
This temporarily disables the `target_in_environment_contains_lower_case` test on Windows until https://github.com/rust-lang/rust/pull/85270 gets into nightly. That PR changes it so that env vars are case-preserved on Windows. My intent is that after that is in nightly, we can remove the windows-specific code in `Config`, and this test should work the same on all platforms.
Closes#9630
Handle git deleted files with dirty worktree.
When listing git files for things like `cargo package`, it was including unstaged deleted files. This is because the file is still in the index, so it was included in the list. `cargo package --allow-dirty` would then fail with a confusing "file not found" error.
This fixes it by keeping a set of deleted files, and skipping those. This allows `cargo package --allow-dirty` to work.
Closes#9580
Fix `BorrowMutError` when calling `cargo doc --open`
~~I'm not sure why the existing test suite didn't catch this, it definitely calls `cargo doc --open`.~~
I had
```toml
[doc.extern-map]
std = "local"
```
in my `.cargo/config.toml`. Will write a test case that sets that and then tries to run `cargo doc --open`.
Closes#9530
Error when packaging with git dependencies without version
If `cargo package` is run on a package that specifies a git dependency
without a version, cargo will error. This should help with clarifying
that git dependencies will be stripped when packaging, and that the
dependency has to be fetched from a registry.
Closes#9442
If `cargo package` is run on a package that specifies a git dependency
without a version, cargo will error. This should help with clarifying
that git dependencies will be stripped when packaging, and that the
dependency has to be fetched from a registry.
Unify weak and namespaced features.
This unifies weak and namespaced features in order to simplify the syntax and semantics. Previously there were four different ways to specify the feature of a dependency:
* `package-name/feature-name` — Enables feature `package-name` on self and enables `feature-name` on the dependency. (Today's behavior.)
* `package-name?/feature-name` — Only enables `feature-name` on the given package if it that package is enabled and will also activates a feature named `package-name` (which must be defined implicitly or explicitly).
* `dep:package-name/feature-name` — Enables dependency `package-name`, and enables `feature-name` on that dependency. This does NOT enable a feature named "package-name".
* `dep:package-name?/feature-name` — Only enables `feature-name` on the given package if it that package is enabled. This does NOT enable a feature named "package-name".
This changes it so there are only two:
* `package-name/feature-name` — Today's behavior.
* `package-name?/feature-name` — Only enables `feature-name` on the given package if it that package is enabled. This does NOT enable a feature named "package-name" (the same behavior as `dep:package-name?/feature-name` above).
This is a fairly subtle change, and in most cases probably won't be noticed. However, it simplifies things which helps with writing documentation and explaining how it works.
Change `rustc-cdylib-link-arg` error to a warning.
In #9523, an error was added if `cargo:rustc-cdylib-link-arg` was issued in a build script without actually having a cdylib target. This uncovered that there was an unintentional change in #8441 to cause those link args to be applied to transitive dependencies.
This changes it so that the error is now a warning, with a note that this may become an error in the future. It also changes it so that the unstable `rustc-link-arg*` instructions only apply to the package that emitted them.
Don't allow config env to modify vars set by cargo
This changes how the `[env]` variables are applied. They will no longer replace any variables that are being set by cargo itself, whether or not the `force` flag is set. The `force` flag still determines whether existing variables from the environment can be overridden or not.
Addresses unresolved issue in #9539
Fix dep-info files including non-local build script paths.
I derped in #8177 and accidentally used the wrong unit when iterating over the dependencies when writing the `.d` file. The consequence here is that all the `rerun-if-changed` paths from a unit's dependencies are included in the `.d` file. This fixes it so that it does not include non-local dependencies.
Fixes#9445
Enhancements to testsuite error output.
This includes several changes to the testsuite error reporting in theory to help make it easier to see differences when the test output changes. The key change is to add a Myers diff with a little colored output to highlight the differences. Here is an example:
<img width="666" alt="image" src="https://user-images.githubusercontent.com/43198/122311381-e8d43580-cec6-11eb-81b4-e2675f10d6ba.png">
The rest of the changes here are various refactorings to try to clean up the diffing code. It ended up being far more changes than I was intending, but I did try to split things into commits to separate them.
I don't trust that all these transformations won't have unintended
consequences on other platforms. It is nice to verify there aren't any
backslash shenanigans on other platforms.
Enable support for fix --edition for 2021.
This adds support for using `cargo fix --edition` to migrate to 2021.
This also uses the new, currently unstable, `--force-warns` flag. This was added because there were a significant number of crates that were "allow"ing lints that are required for migrating the edition. This wasn't a problem for 2018, because its lints were new, and all "allow" to start. For 2021, several older "warn" lints are becoming hard errors. "allow"ing them would cause the migration to fail.
The output was checking the `targets`, whose order depends on the
filesystem order. Instead of checking all the output, just
check the one field this test is for.
Fix rustc/rustdoc config values to be config-relative.
The `rustc`, `rustdoc`, `rustc_wrapper`, and `rustc_workspace_wrapper` config values (in the `[build]` table) were being interpreted literally. This caused a problem if you used a relative path like `foo/rustc`. This would be interpreted as a relative path from whatever cwd cargo launches rustc from, which changes for different scenarios, making it essentially unusuable (since crates.io dependencies wouldn't be buildable).
Additionally, due to https://github.com/rust-lang/rust/issues/37868, it is a bad idea to use relative paths.
This changes it so that those paths are config-relative. Bare names (like "my-rustc-program") still use PATH as before.
This also includes a commit to centralize the rustc-wrapper program used by several tests so that it isn't built multiple times (and to allow several tests to work on windows).
Fixes#8202
If a combination of --bins, --benches, --examples, --tests flags have
been specified, but we didn't match on anything after resolving the unit-list,
we emit a warning to make it clear that cargo didn't do anything and that the
code is unchecked.
Closes#9536
Add `--prune` option for cargo-tree
Part of #8105
Prune the given package from the display of the dependency tree. Also providing a nice suggestion if the package is not within the resolved dependency graph.
Configure hosts separately from targets when --target is specified.
This prevents target configs from accidentally being picked up when cross compiling from hosts that have the same architecture as their targets.
closes#3349
Add some validation to rustc-link-arg
This adds some validation, so that if a `cargo:rustc-link-arg-*` build script instruction specifies a target that doesn't exist, it will generate an error. This also changes a parse warning to an error if the `=` is missing from BIN=ARG.
I intentionally did not bother to add the validation to config overrides, as it is a bit trickier to do, and that feature is very rarely used (AFAIK), and I'm uncertain if rustc-link-arg is really useful in that context.
cc #9426
`cargo tree -e no-proc-macro` to hide procedural macro dependencies
Probably resolves#9165
`cargo tree -e no-proc-macro` now hides procedural macro dependencies.
Note that when passed with `--invert <spec>`, the spec's reverse proc-macro dependencies are also hidden. Is this desired result?
Also, since I want `-p <spec>` and `-i <spec>` works with any valid package-id in the project, the filter logic is written in print stage instead of graph build stage
Update to semver 1.0.0
I am working on a 1.0.0 of the `semver` crate some time this week. It would be good to confirm Cargo will be able to use it, beforehand!
It's a from-scratch rewrite, but https://github.com/dtolnay/semver/issues/237 has code to compare against 0.10.0 (currently used by Cargo) how every possible version requirement currently published to crates.io matches against every possible crate version. The differences are all broken syntax like `^0-.11.0` previously parsing with ".11.0" as a pre-release string (which is invalid, because pre-release are not allowed to contain empty dot-separated identifiers) and `~2.0-2.2` previously parsing with "2.2" as a pre-release string, when the user almost certainly meant `>=2.0, <=2.2`. I'm not sure how much of those you want to add code into Cargo to preserve behavior, but I would be happy to do it.
Add `cargo:rustc-link-arg-bin` flag.
This PR implements a `cargo:rustc-link-arg-bin` command to specify per-binary link args from build scripts. This follows the suggestion from the tracking issue #9426.
Syntax is `cargo:rustc-link-arg-bin=BIN_NAME=ARG`
This was previously possible to do using the `#[link_args=".."]` attribute, but it was removed in rust-lang/rust#83820 in favor of the Cargo extra-link-args feature, which can currently not specify different link args for different bins in the same crate. This PR adds back the ability to do that.
Add a cargo-doc.browser config option
The idea of this option is to allow cargo to use a separate browser from
the rest of the system. My motivation in doing this is that I want to
write a script that adds a symbolic link in some web root on my system
such that I can access my docs via the http protocol to avoid the
limitations of the file protocol that are accessibility problems for me.
For instance, zoom is not retained across multiple pages and Stylus
filters don't work well.
The idea of this option is to allow cargo to use a separate browser from
the rest of the system. My motivation in doing this is that I want to
write a script that adds a symbolic link in some web root on my system
such that I can access my docs via the http protocol to avoid the
limitations of the file protocol that are accessibility problems for me.
For instance, zoom is not retained across multiple pages and Stylus
filters don't work well.
Improve two error messages
The first error message saying "an integer" is confusing because if you give it `4` it's an integer but it will still complain that it must be an integer. So it's more specific now and tells you that it actually needs to be `1`, `2` or `3`.
In the second error there was a space missing. It says `is not a valid setting,must be`.
The variable is set to $target_dir/$config/tmp
This is a directory where tests & benches can place testcasei-related data
for use by the tests.
cargo makes sure the directory exists when building tests/benches.
Add `report` subcommand.
This renames the `cargo describe-future-incompatibilities` subcommand to `cargo report future-incompatibilities`. The intent here is to have a general `report` subcommand that can be used for other reports in the future. This helps avoid the proliferation of top-level subcommands, and to help keep the CLI a little more organized.
Respect Cargo.toml `[package.exclude]` even not in a git repo.
May resolves#9054
This bug (or feature?) has been lingering for a while. #7680 fixed the `cargo package` part but `cargo vendor` is still affected by the heuristic rule of ignoring dotfiles. ~~I propose to drop the rule and include dotfiles by default even if the package is not under git-controlled~~. See below.
## Updated: Changes Summary
`cargo vendor` vendors dependencies without git-controlled but `cargo package` often runs under a VCS like git. [These lines](https://github.com/rust-lang/cargo/blob/1ca930b/src/cargo/sources/path.rs#L161-L168) are where they diverges: `fn list_files_walk_except_dot_files_and_dirs` builds [its own ignore instance], which cannot merge with other filter rules from `[package.exclude]`. This causes some patterns to not work as expected, such as re-including file after ignoring dotfiles `[.*, !negated_file]`.
To make re-include (negate) rule works, this patch adds the excluding dotfiles rule directly into the `package.exclude` ignore instance if **_no include option nor git repo exists_**. Other old behaviors should not change in this patch.
[its own ignore instance]: https://github.com/rust-lang/cargo/blob/1ca930b6/src/cargo/sources/path.rs#L364-L366
Fix collision doc tests randomly failing.
This fixes some tests that were randomly failing on CI. The cause is that #9419 added a remove_dir_all on the `doc` directory. However, if two jobs are trying to write to that directory at the same time, this can cause errors. The failure rate is low (a little over 1%), and I was unable to reproduce locally (only on GitHub's CI and only on the Windows job).
The solution is to run the jobs with -j1 so they run serially.
I only saw errors for `collision_doc_sources`, but to be on the safe side I added j1 to similar tests.
Fix dep-info files emitting paths relative to deps' roots
Sample `shoo.d` file prior to this change is below, note the `build.rs`
at the end, which was not from my package.
From booping the debugger, I found this was coming from
`compiler_builtins`. This is not really their bug though: if a build.rs
asks for rerun-if-changed on some crate relative path, this will happen
in general. So I've fixed it in Cargo and added a test to prevent it
regressing.
```
target/riscv64imac-mu-shoo-elf/release/shoo: /home/jade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/core_arch_docs.md /home/jade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/macros.rs /home/jade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/mod.rs /home/jade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/simd.rs /home/jade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/simd_llvm.rs crates/build_bits/src/lib.rs shoo/src/main.rs shoo/src/task.rs shoo/src/vectors.s build.rs
```
This change fixes it so it's like:
```
target/riscv64imac-mu-shoo-elf/release/shoo: /home/jade/.cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.39/build.rs /home/jade/.cargo/registry/src/github.com-1ecc6299db9ec823/log-0.4.14/build.rs /home/jade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/core_arch_docs.md /home/jade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/macros.rs /home/jade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/mod.rs /home/jade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/simd.rs /home/jade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/simd_llvm.rs crates/build_bits/src/lib.rs shoo/src/main.rs shoo/src/task.rs shoo/src/vectors.s
```
Fix rebuild issues with rustdoc.
This fixes two issues related to rebuilds with rustdoc:
* Switching features when running `cargo doc` would result in Cargo not rebuilding the documentation. This is because it was keeping the fingerprints in separate directories based on the features used. However, the rustdoc output isn't keyed off the metadata hash, so although the old fingerprint seemed "up to date", in reality the documentation was rewritten and needs to be rebuilt. The solution is to use a simplified hash for the fingerprint directory name.
* Removing items does not remove the files from the doc directory. This changes it to clear the package's doc directory before running rustdoc, to ensure any stale files are removed.
I'm a little concerned about potential performance impact of running `remove_dir_all`, but I think it shouldn't be too bad?
Fixes#7370
Sample `shoo.d` file prior to this change is below, note the `build.rs`
at the end, which was not from my package.
From booping the debugger, I found this was coming from
`compiler_builtins`. This is not really their bug though: if a build.rs
asks for rerun-if-changed on some crate relative path, this will happen
in general. So I've fixed it in Cargo and added a test to prevent it
regressing.
```
target/riscv64imac-mu-shoo-elf/release/shoo: /home/jade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/core_arch_docs.md /home/jade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/macros.rs /home/jade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/mod.rs /home/jade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/simd.rs /home/jade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/simd_llvm.rs crates/build_bits/src/lib.rs shoo/src/main.rs shoo/src/task.rs shoo/src/vectors.s build.rs
```
This change fixes it so it's like:
```
target/riscv64imac-mu-shoo-elf/release/shoo: /home/jade/.cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.39/build.rs /home/jade/.cargo/registry/src/github.com-1ecc6299db9ec823/log-0.4.14/build.rs /home/jade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/core_arch_docs.md /home/jade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/macros.rs /home/jade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/mod.rs /home/jade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/simd.rs /home/jade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/simd_llvm.rs crates/build_bits/src/lib.rs shoo/src/main.rs shoo/src/task.rs shoo/src/vectors.s
```
