Skip to content

Commit 9df9c9d

Browse files
committed
choose a less arbitrary span when parsing the empty visibility modifier
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.)
1 parent 33b40f5 commit 9df9c9d

File tree

1 file changed

+4
-1
lines changed

1 file changed

+4
-1
lines changed

src/libsyntax/parse/parser.rs

+4-1
Original file line numberDiff line numberDiff line change
@@ -6032,7 +6032,10 @@ impl<'a> Parser<'a> {
60326032
}
60336033

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

0 commit comments

Comments
 (0)