Introduce new entity kinds into existing class hierarchy, e.g. DirectCallExpr, FunctionDeclRefExpr, VarDeclRefExpr, etc.

[ex0dus-0x]

It would be convenient to support a FunctionDecl::name() that parses out the function declaration's name, which can be further grabbed in call_expr.direct_callee().name(). Ideally, we want a string type, but a Token could also suffice.

This could be expanded to grab identifiers from other types of declarations and objects.

[pgoodman]

Is FunctionDecl::name() not already a thing? A FunctionDecl is a NamedDecl, and NamedDecl has name().

[pgoodman]

direct_callee can't always return a function decl, because you might have an indirect call, so you'd always need to have ->name(), and even for that, check if it's a direct call.

Maybe what could be interesting is a more aggressive bootstrap: treat CallExpr as though it is an abstract base class of DirectCallExpr and IndirectCallExpr. We could hook things up in the code to make that work, and then move direct_callee into DirectCallExpr, making it not return a std::optional. Thoughts?

[ex0dus-0x]

Ah brain fart, it does exist, as the auto-gen approach made me think that a .name() method should also be populated for the class directly.

Having this distinction makes a lot more sense.

[pgoodman]

I think more could be introduced, e.g. FunctionDeclRefExpr. Also, we'd want to make the bootstrapper actually record how names map to storage locations, so then we should have a derived class contain a more specific implementation of the method.

One key thing to making this all work is to take over kind for Decl, and make it use MX_APPLY_FUNC rather than MX_APPLY_METHOD. Then we could introduce our own kinds. Inside of Main.cpp, we could also declare what the derived classes "look like," so that the boostrapper sees them as though they are real. We'd need to tweak other things, like making sure that CallExpr isn't treated as a concrete class type.

[pgoodman]

I think breaking out binary and unary operators could be nifty, e.g. AssignExpr.