feat: strip prefix from methods in code generation

[ematipico]

Summary

Part of #1725

Closes #1733

This PR improves the codegen by forcing to use labels when writing ungrammar.

Test Plan

cargo test
cargo check
cargo lint

[xunilrj]

I hate that we can't have "type" as identifiers in Rust. There is one option: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=528a1f56f1209a1b4e5492ecec89c4ac

pub struct A {
    r#type: String
}

It is not great, but maybe it is something we want?

[ematipico]

Does it work for methods? Because ty is a method in this case.

[MichaReiser]

It does work but it also requires to change the call-sites to n.r#type() playground

We may be able to change the type name in the future. For example, is this a type reference or a type binding?

[ematipico]

Personally, I wouldn't call it type at all because it could create confusion depending on what we are evaluating.

For example:

function foo<T, S, V>(opts: Options): Foo {}

If we had a simple r#type() function, what's the type referred to? Foo or <T, S, V>? I'd prefer to have more descriptive names.

[MichaReiser]

There might have been a misunderstanding in #1733 The title says that labels should be enforced but the content of the task sets the goal to remove the need for explicit labels:

Change the codegen to strip the Js extensions from field names to reduce the need for explicit labels. For example, ExpressionStatement must use an explicit label for its inner expression so that it isn't named js_expression.

I personally would find it valuable if I don't need to prefix all children because it makes the grammar super verbose.

[MichaReiser]

Why do we still need this if we use explicit labels anyway? Or is this for the node types?

[ematipico]

It's because type is a reserved keyword and we ca still do something like:

Foo = type: Type

Which would cause creating something like:

struct Foo {
	pub fn type() -> SyntaxResult<Type> {}
}

We could make it better, and throw an error during the code generation saying that type is denied as name for a label.

[ematipico]

There might have been a misunderstanding in #1733 The title says that labels should be enforced but the content of the task sets the goal to remove the need for explicit labels:

Change the codegen to strip the Js extensions from field names to reduce the need for explicit labels. For example, ExpressionStatement must use an explicit label for its inner expression so that it isn't named js_expression.

I personally would find it valuable if I don't need to prefix all children because it makes the grammar super verbose.

I can close the PR if you want. Sorry for the misunderstanding.

[MichaReiser]

There might have been a misunderstanding in #1733 The title says that labels should be enforced but the content of the task sets the goal to remove the need for explicit labels:

Change the codegen to strip the Js extensions from field names to reduce the need for explicit labels. For example, ExpressionStatement must use an explicit label for its inner expression so that it isn't named js_expression.

I personally would find it valuable if I don't need to prefix all children because it makes the grammar super verbose.

I can close the PR if you want. Sorry for the misunderstanding.

I do find it valuable that we automatically strip the Js prefix because it would then not be required to have explicit labels and I think your PR already accounts for that, doesn't it?

[ematipico]

There might have been a misunderstanding in #1733 The title says that labels should be enforced but the content of the task sets the goal to remove the need for explicit labels:

Change the codegen to strip the Js extensions from field names to reduce the need for explicit labels. For example, ExpressionStatement must use an explicit label for its inner expression so that it isn't named js_expression.

I personally would find it valuable if I don't need to prefix all children because it makes the grammar super verbose.

I can close the PR if you want. Sorry for the misunderstanding.

I do find it valuable that we automatically strip the Js prefix because it would then not be required to have explicit labels and I think your PR already accounts for that, doesn't it?

I removed the logic that forces to use a label and kept the stripping part. Thank you for the suggestions!

[MichaReiser]

And our code gen becomes better and better every day :)

[MichaReiser]

Nit: We may now end up stripping multiple prefixes (probably super rare). Might be safer to find the first prefix and then strip it Playground

 let prefixes = HashSet::from(["js", "ts", "tsx"]);
  let input = "js_expression";
  
  
  let (prefix, tail) = input.split_once('_').unwrap_or(("", input));
  
  let name = if prefixes.contains(prefix) {
      tail
  } else {
      input
  };

[ematipico]

Ultra rare but let's do it! The safer, the better