Skip to content

Commit

Permalink
choose a less arbitrary span when parsing the empty visibility modifier
Browse files Browse the repository at this point in the history
Visibility spans were added to the AST in #47799 (d6bdf29) as a
`Spanned<_>`—which means that we need to choose a span even in the case
of inherited visibility (what you get when there's no `pub` &c. keyword
at all). That initial implementation's choice is pretty
counterintuitive, which could matter if we want to use it as a site to
suggest inserting a visibility modifier, &c.

(The phrase "Schelling span" in the comment is meant in analogy to the
game-theoretic concept of a "Schelling point", a value that is chosen
simply because it's what one can expect to agree upon with other agents
in the absence of explicit coördination.)
  • Loading branch information
zackmdavis committed Jul 1, 2018
1 parent 33b40f5 commit 9df9c9d
Showing 1 changed file with 4 additions and 1 deletion.
5 changes: 4 additions & 1 deletion src/libsyntax/parse/parser.rs
Expand Up @@ -6032,7 +6032,10 @@ impl<'a> Parser<'a> {
}

if !self.eat_keyword(keywords::Pub) {
return Ok(respan(self.prev_span, VisibilityKind::Inherited))
// We need a span for our `Spanned<VisibilityKind>`, but there's inherently no
// keyword to grab a span from for inherited visibility; an empty span at the
// beginning of the current token would seem to be the "Schelling span".
return Ok(respan(self.span.shrink_to_lo(), VisibilityKind::Inherited))
}
let lo = self.prev_span;

Expand Down

0 comments on commit 9df9c9d

Please sign in to comment.