Support modifiers on namespace, in theory. (#3462)

In theory because none are allowed. This is to improve consistency in
handle_decl_name_scope's modifier handling, removing the namespace
special-case.

I noticed there's a crash bug on `impl <declaration>` which I'll address
separately.

This builds on #3461.
This commit is contained in:
Jon Ross-Perkins
2023-12-06 22:45:19 +00:00
committed by GitHub
parent d73729179a
commit 9b194a31c9
8 changed files with 108 additions and 50 deletions
+2 -8
View File
@@ -47,6 +47,7 @@ static auto TokenIsModifierOrIntroducer(Lex::TokenKind token_kind) -> bool {
case Lex::TokenKind::Impl:
case Lex::TokenKind::Interface:
case Lex::TokenKind::Let:
case Lex::TokenKind::Namespace:
case Lex::TokenKind::Private:
case Lex::TokenKind::Protected:
case Lex::TokenKind::Var:
@@ -248,14 +249,7 @@ auto HandleDeclScopeLoop(Context& context) -> void {
// they can't have modifiers and don't use bracketing parse nodes that
// would allow a variable number of modifier nodes.
case Lex::TokenKind::Namespace: {
if (saw_modifier) {
CARBON_DIAGNOSTIC(NamespaceAfterModifiers, Error,
"`namespace` unexpected after modifiers.");
context.emitter().Emit(*context.position(), NamespaceAfterModifiers);
OutputInvalidParseSubtree(context, state.subtree_start);
} else {
introducer(NodeKind::NamespaceStart, State::Namespace);
}
introducer(NodeKind::NamespaceStart, State::Namespace);
return;
}
case Lex::TokenKind::Semi: {