Return proper AST nodes from format_args!() expansion

[CohenArthur]

Needs #2822
Fixes #2856

This PR creates the FormatArgs AST node, and starts the process of building one as part of the format_args!() macro expansion. Having a dedicated AST node is what is being done in modern versions of rustc - it allows for certain optimizations like flattening and inlining of format_args arguments which reduce the generated code size.

This AST node should be converted into the proper function call as part of HIR lowering.

[CohenArthur]

It might be easier to start by expanding format_args calls as a a regular macro expansion - which is what is done in #2893. So I'll drop the last commit here and we can revisit expansion as part of HIR lowering later.

The reason I'm not doing it now is that I would really like to get this over the line, and while expanding as part of HIR lowering has certain benefits, it's also harder and requires modifications of our HIR builders in order to ensure we're using the proper DefIds, etc. Doing it this way is much easier.

[badumbatish]

I'm trying to understand the codebase/ Can i ask if the class ASTLoweringExpr is just implementing different visiting methods so an AST representing an expression can accept this visitor and the new ASTLoweringExpr class will be the HIR?

[CohenArthur]

(good initiative!)

yes, basically all of our "lowering visitors" are simple classes which take care of a subset of the AST nodes we have. So you'll have an ASTLoweringExpr, which takes care of lowering all expr-like nodes - function calls, literal expressions, binary operations, etc.
you'll also have an ASTLoweringStmt (https://github.com/Rust-GCC/gccrs/blob/master/gcc/rust/hir/rust-ast-lower-stmt.h) for all statements, and so on.

The goal of these visitors is to take in an AST node (so if you look at ASTLoweringStmt, there's an override for the visit function which takes an AST::LetStmt node, as variable declarations are statements: declaration.

If you look at the implementation of this function, you'll see there's not much going on - if we look at all that a let statement can be, we get something like this:

let ComplexPattern { a, b, c }: ComplexPattern = get_complex_pattern();

so we have to "visit" and "lower" each of those elements - the pattern, the type, and the initial expression. but in its simplest form a let statement can also be this:

let a;

with just a pattern, no type annotation and no inital expression.

then, we get mappings for our new HIR node we're going to be creating, as all HIR nodes can be refered to using a sort of index/mapping, and we just create our new HIR::LetStmt node. This visitor is structured in such a way that it keeps an HIR::Stmt* translated member, which will store the translated/lowered version of the AST node it received.

each of these top-level visitors (such as ASTLoweringStmt will then return the HIR node they've created: https://github.com/Rust-GCC/gccrs/blob/7064be37a38b4c3c8ad8193e13312e2c558303dc/gcc/rust/hir/rust-ast-lower-stmt.cc#L28C1-L44C2

hope that helps :) feel free to keep asking questions like these!

[CohenArthur]

It might be easier to start by expanding format_args calls as a a regular macro expansion - which is what is done in #2893. So I'll drop the last commit here and we can revisit expansion as part of HIR lowering later.

The reason I'm not doing it now is that I would really like to get this over the line, and while expanding as part of HIR lowering has certain benefits, it's also harder and requires modifications of our HIR builders in order to ensure we're using the proper DefIds, etc. Doing it this way is much easier.

actually it's probably worth keeping the commit anyway because this is something we should probably be doing in the future - it just sets up scaffolding for doing so. I'll add documentation about how this isn't the case yet