Clarify whitespace lex error in qualified identifier lexing #3845
Conversation
This reverts commit 1390079.
|
Right now most of the parser tests live in the main compiler repo, even though it arguably would make more sense to put them into the |
There was a problem hiding this comment.
I like the overall approach; I think this will be an easy PR to land once you add a few tests per @hdgarrood's comment.
| @@ -53,6 +53,7 @@ data ParserErrorType | |||
| | ErrQualifiedName | |||
| | ErrEmptyDo | |||
| | ErrLexeme (Maybe String) [String] | |||
| | ErrQualifierLexeme Char | |||
There was a problem hiding this comment.
By analogy with ErrImportInDecl, ErrTypeInConstraint, etc., should this be ErrLexemeInQualified?
| @@ -128,6 +129,10 @@ prettyPrintErrorMessage (ParserErrorInfo {..}) = case errType of | |||
| "Illegal whitespace character " <> displayCodePoint hd | |||
| ErrLexeme (Just a) _ -> | |||
| "Unexpected " <> a | |||
| ErrQualifierLexeme hd | isSpace hd -> | |||
| "Unexpected whitespace character " <> displayCodePoint hd <> ", expected qualifier" | |||
There was a problem hiding this comment.
Don't you mean ‘expected identifier or operator’ instead of ‘expected qualifier’? The qualifier has already been seen at this point in the parse, right?
Also, it looks like the other error messages of this nature follow an ‘Expected X, saw Y’ pattern; I'd expect these messages to match that.
This intends to close #3801 . See issue for motivation/some discussion.
This PR adds a new lex error for when an unexpected character is encountered when tokenizing a qualified identifier.
My hope is that this indicates that the error is likely caused by a missing identifier, whereas the old error said "Illegal whitespace".
I'm not sure how useful it is to print out the unexpected whitespace character - I'm willing to remove that if others agree.
I'm not sure if parser tests exist/where they are, but if there's a useful way of writing a test for this, I'd be happy to add it if someone points me in the right direction.