Open
Description
I don't know about other contributors, but I have to look at the source implementation (or trial-and-error) every time I see or try to use one of these compiletest directives. IMO, we should audit the design of these directives, and possibly revamp them entirely.
Concrete confusions:
check-run-results
check both run stderr and stdout and puts them into snapshot files (on bless), then compares the subsequent run stderr and stdout against the snapshot.error-pattern
doesn't only check stderr (whose stderr? compiler? run?), it can also check stdout (or both??) depending oncheck-stdout
,dont-check-compiler-*
, and also it can check also compiler stderr or stdout I think??normalize-*
(that is notnormalize-stdout
ornormalize-stderr
) I believe can simultaneously apply to {compiler,run} {stderr,stdout}.run-rustfix
will run rustfix and try to apply all non-placeholder suggestions, including non-machine-applicable ones likeMaybeIncorrect
ones.rustfix-only-machine-applicable
is likerun-rustfix
but only tries to applyMachineApplicable
suggestions.forbid-output
is likeerror-pattern
but named completely differently. I don't remember which output pattern of {compiler,run}x{stderr,stdout} it is forbidding.
EDIT:
regex-error-pattern
is likeerror-pattern
but accepts a regex...
Metadata
Metadata
Assignees
Labels
Area: The compiletest test runnerArea: The testsuite used to check the correctness of rustcCategory: This is a bug.Call for participation: Hard difficulty. Experience needed to fix: A lot.This issue needs exploration and design to see how and if we can fix/implement itCall for partcipation: This issues needs some investigation to determine current statusRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)Relevant to the compiler team, which will review and decide on the PR/issue.
Type
Projects
Status
Backlog