Skip to content

x.py bench --stage 0 src/libcore fails with deprecation errors #61816

Closed

Description

@AaronKutch

I would like to benchmark a specific subset of all the benchmarks, but adding src/libcore onto the command makes it fail:

$ ./x.py bench --stage 0 src/libcore
Updating only changed submodules
Submodules updated in 0.59 seconds
    Finished dev [unoptimized] target(s) in 0.37s
Building stage0 std artifacts (x86_64-pc-windows-gnu -> x86_64-pc-windows-gnu)
    Finished release [optimized] target(s) in 4.00s
Copying stage0 std from stage0 (x86_64-pc-windows-gnu -> x86_64-pc-windows-gnu / x86_64-pc-windows-gnu)
Building stage0 test artifacts (x86_64-pc-windows-gnu -> x86_64-pc-windows-gnu)
    Finished release [optimized] target(s) in 0.56s
Copying stage0 test from stage0 (x86_64-pc-windows-gnu -> x86_64-pc-windows-gnu / x86_64-pc-windows-gnu)
Benchmarking core stage0 (x86_64-pc-windows-gnu -> x86_64-pc-windows-gnu)
   Compiling core v0.0.0 (C:\Users\Allen\Documents\GitHub\rust\src\libcore)
error: `...` range patterns are deprecated
   --> src\libcore\../libcore/benches\ascii.rs:194:21
    |
194 |                 b'a'...b'z' => true,
    |                     ^^^ help: use `..=` for an inclusive range
    |
    = note: `-D ellipsis-inclusive-range-patterns` implied by `-D rust-2018-idioms`

error: `...` range patterns are deprecated
   --> src\libcore\../libcore/benches\ascii.rs:206:21
    |
206 |                 b'a'...b'z' => true,
    |                     ^^^ help: use `..=` for an inclusive range

error: `...` range patterns are deprecated
   --> src\libcore\../libcore/benches\ascii.rs:218:21
    |
218 |                 b'a'...b'z' => true,
    |                     ^^^ help: use `..=` for an inclusive range

error: `...` range patterns are deprecated
   --> src\libcore\../libcore/benches\ascii.rs:230:21
    |
230 |                 b'a'...b'z' => true,
    |                     ^^^ help: use `..=` for an inclusive range

error: `...` range patterns are deprecated
   --> src\libcore\../libcore/benches\ascii.rs:194:21
    |
194 |                 b'a'...b'z' => true,
    |                     ^^^ help: use `..=` for an inclusive range

error: aborting due to 5 previous errors

error: Could not compile `core`.

To learn more, run the command again with --verbose.


command did not execute successfully: "C:\\Users\\Allen\\Documents\\GitHub\\rust\\build\\x86_64-pc-windows-gnu\\stage0\\bin\\cargo.exe" "bench" "--target" "x86_64-pc-windows-gnu" "-j" "4" "--features" "panic-unwind backtrace compiler-builtins-c" "--manifest-path" "C:\\Users\\Allen\\Documents\\GitHub\\rust\\src/libstd/Cargo.toml" "-p" "core" "--" "--quiet"
expected success, got: exit code: 101


        finished in 8.642

1 command(s) did not execute successfully:

  - "C:\\Users\\Allen\\Documents\\GitHub\\rust\\build\\x86_64-pc-windows-gnu\\stage0\\bin\\cargo.exe" "bench" "--target" "x86_64-pc-windows-gnu" "-j" "4" "--features" "panic-unwind backtrace compiler-builtins-c" "--manifest-path" "C:\\Users\\Allen\\Documents\\GitHub\\rust\\src/libstd/Cargo.toml" "-p" "core" "--" "--quiet"

Activity

  1. AaronKutch commented on Jun 13, 2019

    @AaronKutch
    ContributorAuthor

    Also, I should mention that this occurs even after running x.py clean

  2. Centril commented on Jun 14, 2019

    @Centril
    Contributor

    @AaronKutch Could you file a PR with ..= instead of ...?

  3. added
    C-bugCategory: This is a bug.
    C-cleanupCategory: PRs that clean code up or issues documenting cleanup.
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    on Jun 14, 2019
  4. ehuss commented on Jun 14, 2019

    @ehuss
    Contributor

    I was curious why this hadn't been noticed earlier. Apparently benchmarks aren't tested on CI to verify that they still build. This libcore benchmark has been broken since #60133. I'm quite surprised nobody has run x.py bench src/libcore since then.

    Another wrinkle that confused me is that ./x.py test --stage=0 --no-doc src/libcore also fails. Why does this command build benchmarks? Well this little snippet makes --no-doc also enable benchmarks. I suspect that was a mistake, or maybe the mistake is that benchmarks aren't always tested?

    The libs team may want to consider possibly testing benchmarks in CI to ensure that they stay functional. libcore at least only takes a few seconds to build and run its benchmarks in test mode (one iteration).

  5. added
    T-infraRelevant to the infrastructure team, which will review and decide on the PR/issue.
    on Jun 14, 2019
  6. added 3 commits that reference this issue on Jun 14, 2019
    1df29d7
    4b528fe
    145abd8
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: This is a bug.C-cleanupCategory: PRs that clean code up or issues documenting cleanup.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.T-infraRelevant to the infrastructure team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions