From: Zack M. Davis <code@zackmdavis.net>
Date: Sun, 1 Jul 2018 03:22:19 +0000 (-0700)
Subject: choose a less arbitrary span when parsing the empty visibility modifier
X-Git-Url: https://git.lizzy.rs/?a=commitdiff_plain;h=9df9c9df7bdcd688bcad9e91b9e2669f01d9f858;p=rust.git

choose a less arbitrary span when parsing the empty visibility modifier

Visibility spans were added to the AST in #47799 (d6bdf296) 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.)
---

diff --git a/src/libsyntax/parse/parser.rs b/src/libsyntax/parse/parser.rs
index 673157d0ffa..1f062656b81 100644
--- a/src/libsyntax/parse/parser.rs
+++ b/src/libsyntax/parse/parser.rs
@@ -6032,7 +6032,10 @@ pub fn parse_visibility(&mut self, can_take_tuple: bool) -> PResult<'a, Visibili
         }
 
         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;