Tracking Issue for compiletest directive handling bugs and papercuts

[jieyouxu]

This is a tracking issue to collect bugs and papercuts related to compiletest directive handling (incl. parsing/syntax, error reporting, validation and actual wiring up to how tests get run). This is explicitly not for feature requests like negative ui error annotations.

[jieyouxu]

Technically #130981 is not a compiletest directive issue per-se, but we probably want to lint on that during directive collection and validation.

[fmease]

Another fun footgun I just found:

Edition directives like //@ edition 2018 (where there's no colon after the directive name) get silently ignored. That's because in header::check_directive we split the trimmed line after //@ by either whitespace or colon to obtain the directive name (and therefore accept the directive name edition as valid which is fine on its own) but later on inside TestProps::load_from we parse the edition using parse_name_value_directive (inside parse_edition) which re-splits the "original" trimmed line by colon only and discards the directive entirely if it doesn't find one.

I presume this may affect lot more directives. Potentially all that use parse_name_value_directive.

I know that one isn't supposed to report new issues inside tracking issues but I couldn't be bothered to open a new issue especially since I presume the future "compiletest-parser-next"(tm) will behave correctly from the start in this artificial case. Well, I suppose we might want to make the grammar more strict and require a colon after the directive name if arguments follow.

[jieyouxu]

Edition directives like //@ edition 2018 (where there's no colon after the directive name) get silently ignored.

That is #123760 right?

[fmease]

Oh, shoot! You are right, I should've looked more closely at all the opened issues. My bad >.<

[jieyouxu]

No worries, there's a lot of them 😆