-
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: add basic test coverage for stable --crate-type
flag
#134906
Conversation
--crate-type
--crate-type
flag
16d3c41
to
3572361
Compare
tests/ui/cli/crate-type-flag.rs
Outdated
//! | ||
//! This test does not try to check if the output artifacts are valid. | ||
|
||
// FIXME(#132309): add a proper `supports-crate-type` directive. |
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.
This is a known could-be-improved compiletest directive handling aspect #132309 to not have all the random ignore-*
s, didn't want to fix that in this PR.
tests/ui/cli/crate-type-flag.rs
Outdated
|
||
//@ revisions: multivalue multivalue_combined | ||
|
||
//@[multivalue] compile-flags: --crate-type=lib,rlib,staticlib |
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.
I never knew this was a valid form, just stumbed across this while reviewing #134720 and was wondering why the crate-type parser accepted a list_list
.
tests/ui/cli/crate-type-flag.rs
Outdated
//@ revisions: underscore_proc_macro | ||
|
||
//@[underscore_proc_macro] compile-flags: --crate-type=proc_macro | ||
//@[underscore_proc_macro] error-pattern: "unknown crate type: `proc_macro`" |
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.
I intentionally used error-pattern
because the stderr snapshots can be easy to accidentally bless away, but this forces the stderr to contain the unknown crate type error message (fuzzily matched).
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.
You could even use //@ dont-check-compiler-stderr
for the 2 tests, so that the stderr snapshots are not saved, and are impossible to bless away ^^.
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.
I believe the stderr snapshots are still compared when I only have error-pattern
. This is (1) useful to detect if the exact error message changed, but can be easily reblessed (2) let's you preview what the error message looks like (more specifically say if we add a suggestion) e.g. #134720.
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.
If you find this confusing, then that's #134888 😆
tests/ui/cli/crate-type-flag.rs
Outdated
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.
This test is under tests/ui/cli
(new subdirectory) because I couldn't find a better home and didn't want to throw it directly under tests/ui/
. I imagine other stable cli flags likely are also under-tested...
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.
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.
I imagine other stable cli flags likely are also under-tested...
Undoubtedly yes. Well, apart from tests/ui/invalid-compile-flags/
I know of tests/ui/extern-flag/
for --extern
which contains 16 UI tests.
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.
Ah thanks for the pointers. I stared at ls -d tests/ui/*/
without noticing that directory...
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.
Please use the preexisting
tests/ui/invalid-compile-flags/
1 instead. See discussion in #133277.
FTR, that directory would be a bit misleading for this test. This test has both "positive coverage", i.e. does a basic smoke test of the simple 1-crate-type cases and multi-crate-type cases, and it also has "negative coverage", i.e. that some invalid crate-type formulations are rejected with an error.
Indeed:
tests/ui/invalid-compile-flags/branch-protection-missing-pac-ret.rs
tests/ui/invalid-compile-flags/codegen-option-without-group.rs
tests/ui/invalid-compile-flags/debug-option-without-group.rs
tests/ui/invalid-compile-flags/function-return/requires-x86-or-x86_64.rs
tests/ui/invalid-compile-flags/function-return/thunk-extern-requires-non-large-code-model.rs
tests/ui/invalid-compile-flags/invalid-llvm-passes.rs
tests/ui/invalid-compile-flags/print-without-arg.rs
tests/ui/invalid-compile-flags/print.rs
tests/ui/invalid-compile-flags/reg-struct-return/requires-x86.rs
tests/ui/invalid-compile-flags/regparm/regparm-valid-values.rs
tests/ui/invalid-compile-flags/regparm/requires-x86.rs
All of these seems to be exercising invalid compile-flags (i.e. are all negative coverage).
EDIT: started a discussion in https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Slightly.20reorganizing.20compile.20flags.20test.20coverage, but I'm going to stuff this test under the existing directory in this PR.
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.
Anyway, moved the test under invalid-compile-flags/
since I didn't want to make a new directory.
@bors rollup=iffy (exercises all the |
tests/ui/cli/crate-type-flag.rs
Outdated
//@ revisions: underscore_proc_macro | ||
|
||
//@[underscore_proc_macro] compile-flags: --crate-type=proc_macro | ||
//@[underscore_proc_macro] error-pattern: "unknown crate type: `proc_macro`" |
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.
You could even use //@ dont-check-compiler-stderr
for the 2 tests, so that the stderr snapshots are not saved, and are impossible to bless away ^^.
4a5a2d3
to
912f6e3
Compare
👍 r=lqd,fmease when green |
912f6e3
to
92e8e84
Compare
//@[unknown] compile-flags: --crate-type=🤡 | ||
//@[unknown] error-pattern: "unknown crate type: `🤡`" | ||
|
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.
Remark: changed this to use an actual Unicode emoji, to check that we can handle non-ASCII inputs as well.
@bors r=lqd,fmease |
☀️ Test successful - checks-actions |
Finished benchmarking commit (93722f7): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary -2.6%, secondary 1.8%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (secondary 2.4%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 761.456s -> 759.393s (-0.27%) |
I experimented locally with making the compiler panic if multiple crate types are passed to a single
--crate-type
flag, and it turns out not only does the compiler successfully bootstrap, only two ui tests failed:These are not specific tests for the
--crate-type
flag, only their auxiliary happens to use a--crate-type
with two crate types://@ compile-flags: -C codegen-units=3 --crate-type=rlib,dylib -g
I was not able to find a specific test in run-make test suite either.
So this PR tries to add some basic test coverage for the stable
--crate-type
flag's interface (including to check that--crate-type
accepts multiple crate types), since I imagine it might be slightly awkward if we accidentally regressed this.r? compiler