[v2] Added a new V2 AST module, with basic AST constructs

[teofr]

This PR adds a new AST for V2 slang, it's still under active development so it will change.

There's a few things that will most likely change soon:

• All Non terminals keep access to all their children, including terminals that carry no information (like a ;)
• The AST is dependent on an arena, currently using bumpalo, this should probably be abstracted away, and each constructor take a more complex type having an arena, the source, a string interner, etc
• I haven't focused much on the public API for now, eventually we'll need to do this.

Overhauling #1492

[changeset-bot]

⚠️ No Changeset found

Latest commit: a853657

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[OmarTawfik]

nit: WDYT of using YulUncheckedKeyword::new(...) instead?

impl YulUncheckedKeyword {
  pub fn new(...) {
    ...
  }
}

[teofr]

I think that'd be a better option, but it'd require some changes to the current representation, since sequence types are represented as a struct that is wrapped around an Rc<>, using a type alias. If we go down the line of impl new methods, it would require creating a full new type, like shown below:

pub struct AbicoderPragma {
    pub inner: Rc<AbicoderPragmaStruct>,
}

impl AbicoderPragma {
    pub fn new(...) ...
}

#[derive(Debug)]
pub struct AbicoderPragmaStruct {
    pub abicoder_keyword: AbicoderKeyword,
    pub version: AbicoderVersion,
}

I think is too soon to know what the best representation will be, and this should eventually be replaced by @ggiraldez work (or a modification of that).

However, if this is something you think is worth to make the effort I'm happy to do it.

What do you think if, for now, I add a TODO comment with this expected change/improvement?

[teofr]

As a note, there's one reason I can think on why this may not be a good idea down the road: some of these CST nodes should be translated to transparent nodes in the AST in the future.

For example, on the work @ggiraldez is doing for the ir2, a NamedImport is not present as a node, being just syntactic sugar for a PathImport. I expect the V2 parser to generate directly a PathImport, but ideally that logic shouldn't be part of the parser, so the parser would just call a function pub fn new_named_import(...) -> NamedImport, with NamedImport being just a type alias for PathImport.

It's not impossible to have both things, but in the future we may want to have the creation of AST nodes (all of these new_... methods) follow the CST nodes (ie what the parser sees), and have them completely separated from the AST structure (what the user sees).