Refactor cargo lint tests #13880
Refactor cargo lint tests #13880
Conversation
|
r? @weihanglo rustbot has assigned @weihanglo. Use |
rustbot
added
the
S-waiting-on-review
tests/testsuite/cargo_lints.rs
Outdated
| .run(); | ||
| } | ||
|
|
||
| // LINT_SPECIFIC_TESTS |
There was a problem hiding this comment.
I am fine with have cargo_lints.rs for organizing every lint test, though I don't understand why we can't have nested UI tests. I believe the amount of lint specific tests will grow beyond controls like testsuite/build.rs.
There was a problem hiding this comment.
Nesting tests more deeply would not be a problem; the problem, from my understanding, is that they would diverge from how other UI tests are structured.
Muscraft
force-pushed
the
refactor-cargo-lint-tests
branch
from
a3015ec to
b79fd59
Compare
There was a problem hiding this comment.
Looks good to me, and looking forward to documenting the lint development process in the future :)
Something is failing rustfix tests on nightly and I am working on it:
failures:
---- everything stdout ----
failed: ./tests/everything/multiple-solutions.rs
thread 'everything' panicked at crates/rustfix/tests/parse_and_replace.rs:233:9:
1 out of 9 fixture asserts failed
error: test failed, to rerun pass `-p rustfix --test parse_and_replace`
(run with `env RUST_LOG=parse_and_replace=info` to get more details)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
|
@bors try |
Refactor cargo lint tests In #13621, it was brought up that [the lints tests are nested more deeply than other UI tests](#13621 (comment)). This got me wondering if there was a better way to structure all the lint tests. What I came up with was: - Lints should not have UI tests, only parts of the diagnostic system, i.e., how warnings, errors, notes, etc., look - This is because UI tests should focus on parts of the system that make up each lint's output - We can always add UI tests for each lint if desired - All tests related to the linting system should live in `tests/testsuite/lints/` - Tests related to `[lints.cargo]` should stay in `lints_table.rs` as it is for the whole lints table - Each lint will get a file in `lints/` for all of its tests - This makes `lints/mod.rs` smaller and targeted only at tests for the linting system itself - It makes it much easier to know where to place a test
|
☀️ Try build successful - checks-actions |
|
@bors r+ Thanks for the refactor! |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
Update cargo 7 commits in 0ca60e940821c311c9b25a6423b59ccdbcea218f..4de0094ac78743d2c8ff682489e35c8a7cafe8e4 2024-05-08 01:54:25 +0000 to 2024-05-09 16:09:22 +0000 - Fix docs for unstable script feature (rust-lang/cargo#13893) - Refactor cargo lint tests (rust-lang/cargo#13880) - test(rustfix): run some tests only on nightly (rust-lang/cargo#13890) - Old syntax suggestion (rust-lang/cargo#13874) - docs: clarify dash replacement rule in target name (rust-lang/cargo#13887) - Add local-only build scripts example in check-cfg docs (rust-lang/cargo#13884) - docs(changelog): also mention `--message-format=json` (rust-lang/cargo#13882) r? ghost
In #13621, it was brought up that the lints tests are nested more deeply than other UI tests. This got me wondering if there was a better way to structure all the lint tests.
What I came up with was:
tests/testsuite/lints/[lints.cargo]should stay inlints_table.rsas it is for the whole lints tablelints/for all of its testslints/mod.rssmaller and targeted only at tests for the linting system itself