"help" messages in compiler output is ignored

[oli-obk]

issue-11714.rs
    Line 14:     ; //~ HELP consider removing this semicolon:
issue-13428.rs
    Line 18:     ;   //~ HELP consider removing this semicolon
    Line 23:     ;   //~ HELP consider removing this semicolon
issue-2354.rs
    Line 11: fn foo() { //~ HELP did you mean to close this delimiter?
liveness-return-last-stmt-semi.rs
    Line 20:     x * 2; //~ HELP consider removing this semicolon
parenthesized-box-expr-message.rs
    Line 12:     box(1 + 1) //~ HELP perhaps you meant `box() (foo)` instead?

Removing these will still pass make check.

[kmcallister]

Perhaps compiletest should yell loudly if there are any unparsed //~ comments?

[oli-obk]

kmcallister: this already happens, it's the other direction that is not checked

[ftxqxd]

I think this is intentional. It’d be painful to have to annotate every single help/note message in every test that omits them, and it’s very rarely useful to check that a help/note message is not omitted (which is all this would do).

[oli-obk]

almost.
if you add a help message, other help messages should not be ignored anymore, since you are explicitly checking for help messages

[pnkfelix]

(pointed here from #30778); it seems like a fine idea to me

[fhahn]

I also think it makes sense to have a way to make tests fail if there are unexpected note/help messages (e.g. making sure a new note/help messages does not show up in unexpected places). I guess we currently do not fail on unexpected help/note messages for historical reasons (as far as I remember, earlier versions of Rust did not have help/note messages). However failing on unexpected help/note messages as default now would require adding a lot of additional annotations.

So providing a way to opt in seems reasonable to me.

[nikomatsakis]

@fhahn opt-in seems good, for the reasons you cite. I've also rarely actually wanted a failure in those cases in the tests I write, at least.

[alexcrichton]

I personally like the idea that if any help/note are specified then they must be exhaustively specified, and otherwise they're entirely optional.

Seems like a good way to ensure that the diagnostics are kept in check and they don't accidentally blow up to 1k help messages by accident.

[nikomatsakis]

In discussion in the compiler meeting we agreed that "match all help/note if we match any help/note" is a reasonable heuristic and we should just do that.

If we ever want to test that there are NO note/help, we can always add something like #[rustc_error] (or modify #[rustc_error]) to emit a "fake" NOTE.