Commit graph

37 commits

Author SHA1 Message Date
hi-rustin
ed9dc44f47 Update other tests to use cargo:: syntax
Signed-off-by: hi-rustin <rustin.liu@gmail.com>
2023-12-23 13:17:55 +08:00
Ed Page
82f9bd330e feat(spec): Allow partial versions when unambigious
This was proposed in #12425 to help improve usability of the existing
`cargo update` when dealing with the added workflows.
2023-09-13 22:00:00 -06:00
Ed Page
396298200d test(profile): Verify spec version parsing 2023-09-13 21:59:28 -06:00
Scott Schafer
8d66a0265d chore: update profile_overrides tests to use check 2023-02-20 12:21:55 -06:00
Ed Page
cdec3838a8 Extend pkgid syntax with @ support
In addition to `foo:1.2.3`, we now support `foo@1.2.3` for pkgids.  We
are also making it the default way of rendering pkgid's for the user.

With cargo-add in #10472, we've decided to only use `@` in it and to add
it as an alternative to `:` in the rest of cargo.  `cargo-add`
originally used `@`.  When preparing it for merge, I switched to `:` to
be consistent with pkgids. When discussing this, it was felt `@` has
precedence in too many tools to switch to `:` but that we should instead
switch pkgid's to use `@`, in a backwards compatible way.

See also https://internals.rust-lang.org/t/feedback-on-cargo-add-before-its-merged/16024/26?u=epage
2022-04-19 16:00:15 -05:00
Eric Huss
6f8c7d5a87 Normalize raw string indentation. 2020-09-26 17:59:58 -07:00
Alex Crichton
bac300bda0 Add support for -Cembed-bitcode=no
This commit is the Cargo half of support necessary for
rust-lang/rust#70458. Today the compiler emits embedded bytecode in
rlibs by default, but compresses it. This is both extraneous disk space
and wasted build time for almost all builds, so the PR in question there
is changing rustc to have a `-Cembed-bitcode` flag which, when enabled,
places the bitcode in the object file rather than an auxiliary file (no
extra compression), but also enables `-Cembed-bitcode=no` to disable
bitcode emission entirely.

This Cargo support changes Cargo to pass `-Cembed-bitcode=no` for almost
all compilations. Cargo will keep `lto = true` and such working by not
passing this flag (and thus allowing bitcode to get embedded), but by
default `cargo build` and `cargo build --release` will no longer have
any bitcode in rlibs which should result in speedier builds!

Most of the changes here were around the test suite and various
assertions about the `rustc` command lines we spit out. One test was
hard-disabled until we can get `-Cembed-bitcode=no` into nightly, and
then we can make it a nightly-only test. The test will then be stable
again once `-Cembed-bitcode=no` hits stable.

Note that this is intended to land before the upstream `-Cembed-bitcode`
change. The thinking is that we'll land everything in rust-lang/rust all
at once so there's no build time regressions for anyone. If we were to
land the `-Cembed-bitcode` PR first then there would be a build time
regression until we land Cargo changes because rustc would be emitting
uncompressed bitcode by default and Cargo wouldn't be turning it off.
2020-04-01 14:31:06 -07:00
Eric Huss
2296af27ae Fix BuildScriptOutput when a build script is run multiple times. 2020-02-02 13:26:22 -08:00
Eric Huss
77ee608de3 Add named config profiles. 2020-01-13 13:27:33 -08:00
bors
b35bb1b9b7 Auto merge of #7591 - ehuss:stabilize-profile-overrides, r=alexcrichton
Stabilize profile-overrides.

This stabilizes the profile-overrides feature. This was proposed in [RFC 2282](https://github.com/rust-lang/rfcs/pull/2282) and implemented in #5384. Tracking issue is https://github.com/rust-lang/rust/issues/48683.

This is intended to land in 1.41 which will reach the stable channel on Jan 30th.

This includes a new documentation chapter on profiles. See the ["Overrides" section](9c993a92ce/src/doc/src/reference/profiles.md (overrides)) in `profiles.md` file for details on what is being stabilized.

Note: The `config-profile` and `named-profiles` features are still unstable.

Closes #6214

**Concerns**
- There is some risk that `build-override` may be confusing with the [proposed future dedicated `build` profile](https://github.com/rust-lang/cargo/pull/6577). There is some more discussion about the differences at https://github.com/rust-lang/rust/issues/48683#issuecomment-445571286. I don't expect it to be a significant drawback. If we proceed later with a dedicated `build` profile, I think we can handle explaining the differences in the documentation. (The linked PR is designed to work with profile-overrides.)
- I don't anticipate any unexpected interactions with `config-profiles` or `named-profiles`.
- Some of the syntax like `"*"` or `build-override` may not be immediately obvious what it means without reading the documentation. Nobody suggested any alternatives, though.
- Configuring overrides for multiple packages is currently a pain, as you have to repeat the settings separately for each package. I propose that we can extend the syntax in the future to allow a comma-separated list of package names to alleviate this concern if it is deemed worthwhile.
- The user may not know which packages to override, particularly for some dependencies that are split across multiple crates. I think, since this is an advanced feature, the user will likely be comfortable with using things like `cargo tree` to understand what needs to be overridden. There is [some discussion](https://github.com/rust-lang/rust/issues/48683#issuecomment-473356415) in the tracking issue about automatically including a package's dependencies, but this is somewhat complex.
- There is some possibly confusing interaction with the test/bench profile. Because dependencies are always built with the dev/release profiles, overridding test/bench usually does not have an effect (unless specifying a workspace member that is being tested/benched). Overriding test/bench was previously prohibited, but was relaxed when named profiles were added.
- We may want to allow overriding the `panic`, `lto`, and `rpath` settings in the future. I can imagine a case where someone has a large workspace, and wants to override those settings for just one package in the workspace. They are currently not allowed because it doesn't make sense to change those settings for rlibs, and `panic` usually needs to be in sync for the whole profile.
- There are some strange interactions with `dylib` crates detailed in https://github.com/rust-lang/rust/issues/64319. A fix was attempted, but later reverted. Since `dylib` crates are rare (this mostly applied to `libstd`), and a workaround was implemented for `build-std` (it no longer builds a dylib), I'm not too worried about this.
- The interaction with `share-generics` can be quite confusing (see https://github.com/rust-lang/rust/issues/63484). I added a section in the docs that tries to address this concern. It's also possible future versions of `rustc` may handle this better.
- The new documentation duplicates some of the information in the rustc book.  I think it's fine, as there are subtle differences, and it avoids needing to flip back and forth between the two books to learn what the settings do.
2019-12-02 15:54:59 +00:00
Eric Huss
83571aee56 Minor testsuite organization. 2019-11-24 18:42:45 -08:00
Eric Huss
dda81d3177 Stabilize profile-overrides. 2019-11-15 17:13:55 -08:00
Eric Huss
12392f6d99 Fix profile override warning in a workspace. 2019-10-23 11:32:50 -07:00
Eric Huss
fcfe0b8988 Rename overrides to package in profiles. 2019-10-10 14:39:30 -07:00
Dan Aloni
375a46f18b Merge remote-tracking branch 'origin/master' into custom-profile-pr-rfc 2019-09-18 08:56:13 +03:00
Alex Crichton
9115b2c326 Extract support directory to its own crate
Extract out all our test support code to its own standalone crate so it
can be shared between multiple test suites if necessary.
2019-09-16 11:47:09 -07:00
Dan Aloni
84331fcf71 profiles: allow to specify overrides other than for 'dev' and 'release' 2019-09-08 21:43:42 +03:00
Alex Crichton
daa1bce283 Enable pipelined compilation by default
This commit enables pipelined compilation by default in Cargo now that
the requisite support has been stablized in rust-lang/rust#62766. This
involved minor updates in a number of locations here and there, but
nothing of meat has changed from the original implementation (just
tweaks to how rustc is called).
2019-07-31 14:56:24 -07:00
Eric Huss
7d7fe6797a Stabilize default-run 2019-06-21 11:36:53 -07:00
Jethro Beekman
0e0d968825 Update #[test] attribute on all tests in the testsuite
sed -i 's/^#\[test\]/#[cargo_test]/' $(rg -l '^#\[test\]')

Manual fixes:
* proc_macro::proc_macro_doctest
2019-06-07 12:41:26 -07:00
Alex Crichton
127fdfeb89 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.
2019-05-08 08:10:26 -07:00
Eric Huss
3cf913ef93 Include proc-macros in build-override. 2019-04-01 16:05:04 -07:00
Eric Huss
ef0b47769b Cleanup: Remove unnecessary borrows. 2019-03-26 18:09:56 -07:00
Alex Crichton
fecb724643 Format with cargo fmt 2018-12-08 03:19:47 -08:00
Dale Wijnand
04ddd4d0fc
Upgrade to Rust 2018 2018-12-06 20:18:35 +01:00
kennytm
4779dbfe85
Update the testsuite to include the explicit '--color' flags. 2018-09-12 11:59:08 +08:00
Dale Wijnand
85984a8700
Migrate from tests fom assert_that/execs to .run() 2018-08-28 15:08:12 +02:00
Dale Wijnand
b5ee3635ef
Wrap ProcessBuilder in Execs & make .cargo return that 2018-08-28 09:24:37 +01:00
Dale Wijnand
16aeb0cd4f
Default test support's Execs to exit code 0 2018-08-03 07:44:42 +01:00
Dale Wijnand
05400b8018
Drop the [/] test output macro 2018-08-02 10:18:48 +01:00
Dale Wijnand
ca7d9ee292
Declare one-line files on one line, in test projects 2018-07-25 09:58:50 +01:00
Dale Wijnand
ab19c48358
Dedup a bunch more manifest 2018-07-25 00:43:30 +01:00
Dale Wijnand
43b42d6f4c
Reorganise the testsuite crate module hierarchy
* Collapse the nested cargotest::support module into the cargotest
  module (merge the mod.rs's)
* Rename the cargotest module to support
* Nest the top-level hamcrest module into support
2018-07-22 08:46:44 +01:00
Dale Wijnand
7fe2fbc8a3
Remove the argument from the project test support function
By rewriting the tests, with rerast (https://github.com/google/rerast),
to use the newly introduced "at" method.

First I added the following temporary function to cargotest::support:

    pub fn project_foo() -> ProjectBuilder {
        project("foo")
    }

Then I defined the following rewrite.rs:

    use cargotest::support::{ project, project_foo };

    fn rule1(a: &'static str) {
        replace!(project("foo") => project_foo());
        replace!(project(a) => project_foo().at(a));
    }

Then I ran rerast:

    cargo +nightly rerast --rules_file=rewrite.rs --force --targets tests --file tests/testsuite/main.rs

Finally I searched and replaced the references to project_foo with
argument-less project (a little awkardly on macOS with a git clean).

    find tests -type f -exec sed -i -e 's/project_foo/project/g' {} +
    git clean -d tests
2018-07-20 13:31:50 +01:00
Eric Huss
5415a341a5 Add package spec support to profile overrides.
Note: It errors out if multiple overrides match the same package.  This could potentially merge the overrides together with a hierarchy similar to CSS specificity.  However, that seems overkill for now.
2018-05-05 16:51:50 -07:00
Eric Huss
b9181ef3b5 Add some more tests. 2018-04-27 13:42:30 -07:00
Eric Huss
9ca36de444 Move profile override tests to a dedicated file. 2018-04-27 13:42:30 -07:00