Stream: t-compiler

Topic: empty error annotations on ui tests


oli (Mar 05 2020 at 10:58, on Zulip):

centril said:

(Please don't do that though)

why not? The exact message is handled in the .stderr files, the annotations are mostly there to ensure we keep emitting an error at that position. It may help readers a bit if there's some message part, but the worry that the error changes completely seems irrelevant to me, because it's still an error, even if a different one now

oli (Mar 05 2020 at 10:59, on Zulip):

The only thing we could change would be to treat lints and errors differently. So //~ DENY_LINT for lints and //~ ERROR for hard errors

centril (Mar 05 2020 at 11:10, on Zulip):

why the error happens is important, and also the readability aspect you mentioned

oli (Mar 05 2020 at 11:22, on Zulip):

I understand that why the error happens is important, but that info is in the ui test

oli (Mar 05 2020 at 11:22, on Zulip):

and not losing an error is more important than message changes

centril (Mar 05 2020 at 11:29, on Zulip):

why the error happens can also be important in terms of semver (e.g. if an error is moved to after parsing), so the test suite should be resistant to simply overwriting them via --bless

centril (Mar 05 2020 at 11:30, on Zulip):

plus, it makes for easier reviews if you can mainly look at the .rs files and skim the .stderr files

nikomatsakis (Mar 05 2020 at 15:10, on Zulip):

I go back and forth on this -- but as I noted elsewhere, I tend feel that a "distinctive substring" is good. Too much detail is counterproductive imo as well (harder to read...)

Last update: May 29 2020 at 17:40UTC