Stop UI tests if an unknown revision name is specified#123882
Stop UI tests if an unknown revision name is specified#123882tgross35 wants to merge 1 commit intorust-lang:masterfrom
Conversation
|
Some changes occurred in src/tools/compiletest cc @jieyouxu |
This comment has been minimized.
This comment has been minimized.
608bdb4 to
7c77d4a
Compare
|
Hm, looks like we use this behavior to disable tests. Is there a better way to mark that specific revisions should be skipped? A similar check should probably be added to |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
jieyouxu
left a comment
There was a problem hiding this comment.
There are mostly two places that deal with directive parsing:
EarlyPropsdirective parsing:rust/src/tools/compiletest/src/lib.rs
Line 762 in 7106800
TestPropsdirective parsing:(note that immediately after generic test prop handling there's also revision-specific test prop handling).rust/src/tools/compiletest/src/runtest.rs
Line 127 in 7106800
This is currently a mess -- both in terms of parsing / validationg / updating test props and in terms of error handling. I've been meaning to rework this a little but didn't get to it yet.
Hm, looks like we use this behavior to disable tests. Is there a better way to mark that specific revisions should be skipped?
The proper fix I would think is to either introduce a new directive, something like skip-revisions: a b c, or to change the grammar of revisions to accept something like a, !b where b is skipped.
A similar check should probably be added to //@ attributes
Yes, right now compiletest directive parsing is super lenient, but that is not user friendly -- as a test writer, I want to have helpful errors pointing out my tests have unknown revisions etc. The current way directive parsing is setup is split into (I think) three phases: early test prop parsing (for gathering aux builds and revisions), late test prop parsing (for generic non-revisioned directives) and late per-revision test prop parsing (for revisioned directives). I want to say that we really should be unifying the directive parsing, validation and config update to not have these three separate phases because it can let some malformed/unknown revision directives silently slip through.
|
But validations like the one proposed on this PR ought to not be so painful and tricky to add. I feel like we should collect all the directives and error annotations in one go, then perform parsing and validations immediately after. |
|
I think the long term solution (before |
|
Update: we have a tidy check for unknown revisions (implemented by #124706) with an In any case, thank you very much for the PR, we really do have some whacky footguns in our test suites / test runner that is definitely worth fixing. |
|
Closing this PR since it has been addressed by a tidy check, thank you for the PR! |
|
Ah I totally forgot about this one, thank you for the update! |
There currently isn't anything to let you know that an invalid revision is specified in an error directive like
//[foo,bar,unexpected]~. Add an error if this happens.There might be a better place to do this, is there anywhere we validate the test file before running?