Repository navigation
compiletest: technically potential false positives for filecheck annotations #125825
Description
This is a fun one: in #121561 I added checks to error if we detect any legacy-directives-like comments (which are of the form // <known_directive_name>.
In codegen tests, we have filecheck directives that can be revisioned:
//@ revisions: known_directive_name
// known_directive_name: noundef... but unfortunately, // known_directive_name looks like a legacy directive to compiletest so we might error here even though it is not actually a legacy directive (it just "looks" like one for the heuristic I added).
Technically a bug (false positive), but in practice changing the revision name to something else would sidestep this check.
Note: the legacy directive check would also fire on
// this is a block of comment that has a
// ignore in the middle of the sentence
// that looks like a legacy directive
Activity
jieyouxu commentedon May 31, 2024
Realized this in #125813 (comment), the long term solution is probably to have compiletest directive handling be cooperative between "base" directives and test suite "customized" directives.
workingjubilee commentedon Jun 1, 2024
fwiw despite noting the issue, I think the prefix doesn't matter too much: I reviewed FileCheck's code (as much as I understood it, anyways) and it seems FileCheck is very simple. I don't think it is aware of any comment styles itself. I think it literally just scans for the prefix on a line and assumes you won't introduce code that resembles a FileCheck directive.
jieyouxu commentedon Oct 17, 2024
compiletest triage: I deleted the legacy directive check so this is no longer a problem.