brownplt / pyret-lang

The Pyret language.
Other
1.07k stars 109 forks source link

Strange Error Message With Bad Multi-line String Literal in Pyret Compiler Test #1369

Closed InnPatron closed 6 years ago

InnPatron commented 6 years ago

Writing a Pyret Compiler test with an incorrect string literal:

check "complex examples":
  does-pass(
"  
examples:
    f(2) is 4
    f(3) is 9

    fun f(x):
      x * x
    end
"
) is false
end

Creates an unhelpful and strange error message (truncated):

UNKNOWN VALUE: Atom { name: 'CHECK', value: 'check', key: '\'CHECK:check', asString: '\'CHECK', pos: SrcLoc { startRow: 14, startCol: 0, startChar: 445, endRow: 14, endCol: 5, endChar: 450 } }

InnPatron commented 6 years ago

Attempting to compile this code with the experimental CLI yields a sane error message (truncated):

Parse failed, next token is ('UNTERMINATED-STRING "\" ") at ... Pyret thinks your program has an incomplete string literal around ...

blerner commented 6 years ago

I can't reproduce this in CPO -- I see "Pyret thinks the string " is unterminated." on line 3 (of the snippet you showed; your original code must've had additional text in it), rather than an internal parse error about a CHECK Atom. How were you running this?

The "Parse failed" line could be eliminated; it's a warning message that I've used in the past. The real error message is the next line that you truncated: "Pyret thinks your program has an incomplete string literal around <some source location>; you may be missing closing punctuation."

InnPatron commented 6 years ago

Closing.

Tired-me shouldn't file issues. I had accidentally plugged in my experimental error checking mechanisms into the compiler. Sorry about that.

Removing it produces the correct error message.

blerner commented 6 years ago

That's all right -- I'm curious to hear what your experimental error checking mechanisms are doing, and how to help them work past this parsing glitch... :)