Stream: t-compiler

Topic: diagnostics: duplcated span label

matklad (Jul 06 2019 at 14:38, on Zulip):

I see this code in the lexer:

let mut err = self.struct_span_fatal(pos, pos, "unterminated raw string");
err.span_label(self.mk_sp(pos, pos), "unterminated raw string");

is it ok that we duplicate the message, or should we just remove the span_label?

pnkfelix (Jul 08 2019 at 07:52, on Zulip):

does git blame reveal anything about why it was added? (or was it there from the beginning?)

Vadim Petrochenkov (Jul 08 2019 at 09:49, on Zulip):

cc @Esteban Küber

Vadim Petrochenkov (Jul 08 2019 at 09:50, on Zulip):

IIRC, the general idea is "no label - bad", so labels are added even if they duplicate the primary message.

Vadim Petrochenkov (Jul 08 2019 at 09:56, on Zulip):

If there's no label, then the most valuable place on the diagnostic space - text attached to the precise pointer to an error location ^^^ - becomes vacant.

pnkfelix (Jul 08 2019 at 10:02, on Zulip):

@Vadim Petrochenkov perhaps we could encode that philosophy ("no label -
bad") directly into the diagnostic API? E.g., have struct_span_foo take two message arguments, rather than expecting callers to call span_label themselves ?

pnkfelix (Jul 08 2019 at 10:03, on Zulip):

(and having it take two message arguments might encourage diagnostic authors to consider varying the text...)

Esteban Küber (Jul 08 2019 at 10:41, on Zulip):

Its something I've toyed with but it does make the API more unwieldy
Well probably end up with that regardless

Esteban Küber (Jul 08 2019 at 10:43, on Zulip):

As for the original question petrochencov is spot on. Normally we can benefit by restating with a different wording that can help understanding, but in this case there's very little gramatical wiggle room

Last update: Nov 20 2019 at 01:15UTC