Put the alloc unit tests in a separate alloctests package #136642
+591
−602
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
A-testsuite
|
These commits modify the If this was unintentional then you should revert the changes before this PR is merged. |
This comment has been minimized.
This comment has been minimized.
bjorn3
force-pushed
the
separate_alloctest_crate
branch
from
d40470e to
34a86f7
Compare
This comment has been minimized.
This comment has been minimized.
bjorn3
force-pushed
the
separate_alloctest_crate
branch
from
34a86f7 to
68120bf
Compare
This comment has been minimized.
This comment has been minimized.
bjorn3
force-pushed
the
separate_alloctest_crate
branch
from
68120bf to
8f1c7c3
Compare
|
☔ The latest upstream changes (presumably #136697) made this pull request unmergeable. Please resolve the merge conflicts. |
cuviper
reviewed
Feb 10, 2025
cuviper
reviewed
Feb 10, 2025
bjorn3
force-pushed
the
separate_alloctest_crate
branch
from
8f1c7c3 to
1726670
Compare
|
@bors r+ |
bors
added
S-waiting-on-bors
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this pull request
Feb 14, 2025
…=cuviper Put the alloc unit tests in a separate alloctests package Same rationale as rust-lang#135937. This PR has some extra complexity though as a decent amount of tests are testing internal implementation details rather than the public api. As such I opted to include the modules containing the types under test using `#[path]` into the alloctests package. This means that those modules still need `#[cfg(test)]`, but the rest of liballoc no longer need it.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 14, 2025
…kingjubilee Rollup of 13 pull requests Successful merges: - rust-lang#135439 (Make `-O` mean `OptLevel::Aggressive`) - rust-lang#136460 (Simplify `rustc_span` `analyze_source_file`) - rust-lang#136642 (Put the alloc unit tests in a separate alloctests package) - rust-lang#136904 (add `IntoBounds` trait) - rust-lang#136908 ([AIX] expect `EINVAL` for `pthread_mutex_destroy`) - rust-lang#136924 (Add profiling of bootstrap commands using Chrome events) - rust-lang#136951 (Use the right binder for rebinding `PolyTraitRef`) - rust-lang#136956 (add vendor directory to .gitignore) - rust-lang#136967 (Use `slice::fill` in `io::Repeat` implementation) - rust-lang#136976 (alloc boxed: docs: use MaybeUninit::write instead of as_mut_ptr) - rust-lang#136981 (ci: switch loongarch jobs to free runners) - rust-lang#136992 (Update backtrace) - rust-lang#136993 ([cg_llvm] Remove dead error message) r? `@ghost` `@rustbot` modify labels: rollup
|
Testing for #136998 (comment) |
bors
removed
the
S-waiting-on-bors
For the tests that make use of internal implementation details, we include the module to test using #[path] in alloctests now.
bjorn3
force-pushed
the
separate_alloctest_crate
branch
from
e8647ec to
da1371b
Compare
This comment has been minimized.
This comment has been minimized.
cargo test -p core -p alloc overrides the test=false in Cargo.toml so we have to avoid passing -p core and -p alloc to cargo test.
bjorn3
force-pushed
the
separate_alloctest_crate
branch
from
da1371b to
9c88f10
Compare
|
Locally miri works now. @bors try |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 21, 2025
…try> Put the alloc unit tests in a separate alloctests package Same rationale as rust-lang#135937. This PR has some extra complexity though as a decent amount of tests are testing internal implementation details rather than the public api. As such I opted to include the modules containing the types under test using `#[path]` into the alloctests package. This means that those modules still need `#[cfg(test)]`, but the rest of liballoc no longer need it. try-job: x86_64-gnu-aux
|
☀️ Try build successful - checks-actions |
|
@rustbot ready |
rustbot
added
S-waiting-on-review
cuviper
approved these changes
Feb 21, 2025
|
@bors r+ |
bors
added
S-waiting-on-bors
compiler-errors
added a commit
to compiler-errors/rust
that referenced
this pull request
Feb 22, 2025
…=cuviper Put the alloc unit tests in a separate alloctests package Same rationale as rust-lang#135937. This PR has some extra complexity though as a decent amount of tests are testing internal implementation details rather than the public api. As such I opted to include the modules containing the types under test using `#[path]` into the alloctests package. This means that those modules still need `#[cfg(test)]`, but the rest of liballoc no longer need it.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 22, 2025
…mpiler-errors Rollup of 10 pull requests Successful merges: - rust-lang#136642 (Put the alloc unit tests in a separate alloctests package) - rust-lang#136910 (Implement feature `isolate_most_least_significant_one` for integer types) - rust-lang#137183 (Prune dead regionck code) - rust-lang#137333 (Use `edition = "2024"` in the compiler (redux)) - rust-lang#137356 (Ferris 🦀 Identifier naming conventions) - rust-lang#137362 (Add build step log for `run-make-support`) - rust-lang#137377 (Always allow reusing cratenum in CrateLoader::load) - rust-lang#137388 (Fix(lib/fs/tests): Disable rename POSIX semantics FS tests under Windows 7) - rust-lang#137410 (Use StableHasher + Hash64 for dep_tracking_hash) - rust-lang#137413 (jubilee cleared out the review queue) r? `@ghost` `@rustbot` modify labels: rollup
|
@bors r- |
bors
added
S-waiting-on-author
|
Any way we can keep |
RalfJung
reviewed
Feb 23, 2025
Comment on lines
+2791
to
+2793
| // The core and alloc crates can't directly be tested. We could | ||
| // silently ignore them, but replacing them with their test crate | ||
| // is less confusing for users. |
There was a problem hiding this comment.
Is it still possible to run doc-tests now? If ./x test library/core silently aliases ./x test library/coretests, then it becomes impossible to run the doctests in libcore...
There was a problem hiding this comment.
Right, that should probably be handled using a separate doctest only cargo test invocation. cargo test -p core -p alloc will override the test = false in their respective Cargo.toml. So cargo test -p core -p alloc --doc would be necessary to only test doctests I think.
|
☔ The latest upstream changes (presumably #137571) made this pull request unmergeable. Please resolve the merge conflicts. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Same rationale as #135937. This PR has some extra complexity though as a decent amount of tests are testing internal implementation details rather than the public api. As such I opted to include the modules containing the types under test using
#[path]into the alloctests package. This means that those modules still need#[cfg(test)], but the rest of liballoc no longer need it.