-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
String interpolation followed by a dot is missing string literals #15514
Comments
Remarkably,
|
I also don't see yet what is wrong here. There is no error reported and it generates the correct code. |
I took a look and will follow up. The dot is tokenized FSR after self type looks ahead, maybe something to do with string interpolation as two tokens, the part and the embedded ident. |
Probably this edge case results from a tweak to lookahead #14562 My proposed fix is defensive. I'll consider whether it's possible to tweak scanning the interpolation instead. |
I still don't understand what is wrong. |
I was about to comment on the mechanics, which were challenging enough that I hadn't taken a global view yet. Calling lookahead at INTERPOLATIONID populates current token at STRINGPART and next at IDENT, but reset makes current INTERPOLATIONID and next at STRINGPART, so IDENT is dropped. getNextToken winds up with last STRINGPART, so when it sees the dot it takes it as DOT. Again, it's only with the interpolation in "self-type position". It works either to avoid lookahead in that case, or resort to LookaheadScanner. I'll look at whether producing STRINGPART can be less eager in producing the next IDENT. One idea is that if it's done in postProcess, then lookahead won't do it, much like fusion of case class. |
I mean globally rather than the mechanics. It does produce produce the correct string, no? |
It looks like I edited my previous comment. I'll show the spurious syntax error in a minute after a recompile. Maybe a couple of minutes. I was about to go read some early morning headlines. The unexpected token is DOT. Sorry, Dotty.
|
Ah, now I get it. I tried with normal console but that was still 3.1.3. |
There was a missing set of parentheses in parser which caused a lookahead from INTERPOLATIONID, which should be illegal, since the lookahead then migth set the next TokenData which is subsequently overwritten by reset. We now demand that lookahead cannot be called if the current token is a INTERPOLATIONID. There were two many variants `lookahead` in the Scanner, which only differered in camelCase or not. Rename one to`peekAhead` to make the code clearer.
Compiler version
3.2.0-RC1
Minimized code
Output
This is the tree representing the string interpolation:
Notice it only contains
"Hello "
literal.Expectation
The main part is
elems = List(Literal(const = ( = "Hello ")), Literal(const = ( = ".toStr!")))
The text was updated successfully, but these errors were encountered: