add AST for template literals

[tsnobip]

Add AST for string template literals.

Template literals in rescript are now translated to template literals in JS too.

This should enable better semantic highlighting inside string templates.

[tsnobip]

I'm really not sure about this, should it be static or dynamic?

[nojaf]

You probably want to add some conversation tests for this.
See #7318

[nojaf]

rescript/analysis/src/CompletionFrontEnd.ml

Lines 1143 to 1159 in 48f6ec3

	(*
	A dot completion for a tagged templated application with an expr hole.
	Example:
	sh`echo "meh"`.
	*)
	| Pexp_apply
	{
	funct = {pexp_desc = Pexp_ident {txt = Lident "."; loc = _}};
	args =
	[
	(* sh`echo "meh"` *)
	(_, ({pexp_desc = Pexp_apply _} as innerExpr));
	(* recovery inserted node *)
	(_, {pexp_desc = Pexp_extension ({txt = "rescript.exprhole"}, _)});
	];
	}
	when Res_parsetree_viewer.is_tagged_template_literal innerExpr ->

will also need some revisiting.

[pkg-pr-new]

Open in StackBlitz

rescript

npm i https://pkg.pr.new/rescript-lang/rescript@8132

@rescript/darwin-arm64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/darwin-arm64@8132

@rescript/darwin-x64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/darwin-x64@8132

@rescript/linux-arm64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/linux-arm64@8132

@rescript/linux-x64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/linux-x64@8132

@rescript/runtime

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/runtime@8132

@rescript/win32-x64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/win32-x64@8132

commit: df2e4d1

[tsnobip]

rescript/analysis/src/CompletionFrontEnd.ml

Lines 1143 to 1159 in 48f6ec3

	(*
	A dot completion for a tagged templated application with an expr hole.
	Example:
	sh`echo "meh"`.
	*)
	| Pexp_apply
	{
	funct = {pexp_desc = Pexp_ident {txt = Lident "."; loc = _}};
	args =
	[
	(* sh`echo "meh"` *)
	(_, ({pexp_desc = Pexp_apply _} as innerExpr));
	(* recovery inserted node *)
	(_, {pexp_desc = Pexp_extension ({txt = "rescript.exprhole"}, _)});
	];
	}
	when Res_parsetree_viewer.is_tagged_template_literal innerExpr ->

will also need some revisiting.

@nojaf I think I'll need help on that, btw this file uses a lot of wildcard pattern matching, it'd be cool to list the remaining cases so that the compiler would complain when adding a new case!

[nojaf]

I think I'll need help on that

One approach I can think of here is to do a git blame on those lines.
See which PR introduced them. In that PR you will hopefully find the matching code example that trigger this.

One you have that sample, I would run npx bsc -dparsetree A.res -only-parse -ignore-parse-errors with a recent 12.0.2 compiler from npm.

And then run dune exec bsc -- -dparsetree A.res -only-parse -ignore-parse-errors to see what the new compiler gives you.

Then updating the pattern matches should ensure things play out as they did.

it'd be cool to list the remaining cases so that the compiler would complain when adding a new case!

Something for another PR perhaps. Would not try to solve that here.