We have to talk about that whole minimal reproducible example thing again... ;)

class Main { static function main() { var s = "foo"; var s2 = '\t${s.}'; } }

class UserMove { }

haxe --display Main.hx@70

Fatal error: exception Interp.Invalid_expr
Raised at file "typer.ml", line 400, characters 14-33
Called from file "typer.ml", line 2776, characters 12-105
Called from file "typer.ml", line 2780, characters 1-10
Called from file "typer.ml", line 2863, characters 16-39
Called from file "typer.ml", line 2672, characters 13-41
Called from file "list.ml", line 57, characters 20-23
Called from file "typer.ml", line 2666, characters 10-534
Called from file "typer.ml", line 2794, characters 11-34
Called from file "typer.ml", line 2795, characters 13-19
Called from file "typer.ml", line 2808, characters 9-16
Called from file "typer.ml", line 2872, characters 10-38
Called from file "typecore.ml", line 287, characters 32-64
Called from file "typeload.ml", line 2378, characters 21-72
Called from file "typecore.ml", line 378, characters 3-6
Called from file "typeload.ml", line 2630, characters 51-59
Called from file "typecore.ml", line 365, characters 3-6
Called from file "main.ml", line 1503, characters 2-21
Called from file "main.ml", line 637, characters 3-11
Called from file "main.ml", line 1752, characters 1-35

I'm not sure what's going on here, but it's not a regression so I prefer leaving it for after 3.2.

There's something wrong with the position that is passed to parse_expr_string. In my example it receives characters 66-68 while it should be 68-70. This probably causes the parser resuming to fail, which in turn causes the main field to be omitted, which in turn causes the exception.

Sadly the relevant string interpolation code is not exactly easy to follow.

"The format_string implementation is the only place that has more 1 than the short lambda issue." - Anonymous Haxe maintainer

@ncannasse: Should "\t" count as 1 or 2 "characters" in this context? I think the issue is that the IDE sees it as 2, but to to lexer it's just one and the completion position is then off.

\t should always be one character. Actually in all positions we're talking about byte position in file, so for instance "é" in UTF8 takes 2 bytes.

This is actually the same issue as #2244. The problem in both situations is that we run unescape on the entire interpolation string, which messes things up position- and otherwise.

IMO we shouldn't run unescape until we actually type the string. That might lead to some macros breaking, but it's simply the right thing to do.

I tried fixing this but it's a bit of a mess. The unescape really messes everything up, but we have to run it at some point and make sure that we don't forget about it.

The sample does not crash the compiler anymore.
Completion is not provided yet, but I consider this fixed as there's no crash anymore and completion issue could be tracked as the part of #2244