-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tests: use minicore more #137599
tests: use minicore more #137599
Conversation
minicore makes it much easier to add new language items to all of the existing `no_core` tests.
Some changes occurred in tests/codegen/stack-probes-inline.rs cc @rust-lang/project-exploit-mitigations, @rcvalle Some changes occurred in tests/codegen/sanitizer cc @rust-lang/project-exploit-mitigations, @rcvalle Some changes occurred in tests/ui/sanitizer cc @rust-lang/project-exploit-mitigations, @rcvalle |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this! Most of the tests look good to me, however I noticed a few tests that has minor problems, should not / cannot use minicore
, and a few unexpected changes. With the changes in this PR, I think I can see a better guideline for when to use minicore
. In general, I think minicore
...
- Should be used when one wants a
no_core
ui/assembly/codegen test for ABI/codegen/layout purposes, and maybe some other use cases - Should not be used if the test is exercising diagnostics or
lang_item
-handling itself, or if usingminicore
can complicate debugging (such as when a resolve test fails)
We should add that to rustc-dev-guide
. Maybe you have suggestions for refinements?
tests/ui/associated-types/associated-types-ICE-when-projecting-out-of-err.rs
Outdated
Show resolved
Hide resolved
tests/ui/associated-types/associated-types-ICE-when-projecting-out-of-err.stderr
Show resolved
Hide resolved
527ce54
to
92eb445
Compare
This makes sense to me, but I think diagnostics changing by itself doesn't mean that minicore shouldn't be used, it depends on the specific change - some tests will have a diagnostic change for irrelevant reasons (as in |
Yeah, the classic "It Depends" situation 😆 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
@bors r+ rollup=maybe |
…youxu tests: use minicore more minicore makes it much easier to add new language items to all of the existing `no_core` tests. Most of the remaining tests that *could* use minicore either fail because.. 1. LLVM IR output changes and doesn't pass the test as written. I didn't look into these further. 2. The test has revisions w/ different compilation flags, expecting some to fail, and when using minicore, minicore is compiled with those flags and fails in the expected way because of the flags rather than the test, and that's considered a failure. But these tests can be changed and make adding new language items a lot easier. r? `@jieyouxu`
…youxu tests: use minicore more minicore makes it much easier to add new language items to all of the existing `no_core` tests. Most of the remaining tests that *could* use minicore either fail because.. 1. LLVM IR output changes and doesn't pass the test as written. I didn't look into these further. 2. The test has revisions w/ different compilation flags, expecting some to fail, and when using minicore, minicore is compiled with those flags and fails in the expected way because of the flags rather than the test, and that's considered a failure. But these tests can be changed and make adding new language items a lot easier. r? ``@jieyouxu``
Rollup of 10 pull requests Successful merges: - rust-lang#134943 (Add FileCheck annotations to mir-opt/issues) - rust-lang#137017 (Don't error when adding a staticlib with bitcode files compiled by newer LLVM) - rust-lang#137197 (Update some comparison codegen tests now that they pass in LLVM20) - rust-lang#137540 (Fix (more) test directives that were accidentally ignored) - rust-lang#137551 (import `simd_` intrinsics) - rust-lang#137599 (tests: use minicore more) - rust-lang#137673 (Fix Windows `Command` search path bug) - rust-lang#137676 (linker: Fix escaping style for response files on Windows) - rust-lang#137693 (Re-enable `--generate-link-to-defintion` for tools internal rustdoc) - rust-lang#137770 (Fix sized constraint for unsafe binder) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#137599 - davidtwco:use-minicore-more, r=jieyouxu tests: use minicore more minicore makes it much easier to add new language items to all of the existing `no_core` tests. Most of the remaining tests that *could* use minicore either fail because.. 1. LLVM IR output changes and doesn't pass the test as written. I didn't look into these further. 2. The test has revisions w/ different compilation flags, expecting some to fail, and when using minicore, minicore is compiled with those flags and fails in the expected way because of the flags rather than the test, and that's considered a failure. But these tests can be changed and make adding new language items a lot easier. r? ```@jieyouxu```
minicore makes it much easier to add new language items to all of the existing
no_core
tests.Most of the remaining tests that could use minicore either fail because..
But these tests can be changed and make adding new language items a lot easier.
r? @jieyouxu