> Having two IRs (or even having a 1st-stage IR for each frontend language) sounds like something that a compiler project would want to avoid in the long term
Can you please share the reason behind why it should be this way ?
I'm not a compiler engineer, so I'm just sharing my own point of view, but to me it sounds like a heavy maintenance burden. Whenever possible I would want to avoid having multiple versions of an important subsystem in any large program that I worked on.
This is true, I tried to make gccrs only have the AST and go from that stright to GCC GENERIC. This had a lot of problems for Rust in my opinion.
Many things in Rust are syntactic sugar and can be handled by desugaring the AST into another IR so you dont even have to think about it in other passes. The main issue for me is how complicate the type inference is.
So if i wanted to use GCC GENERIC for type resolution for this example:
```
let a;
a = 123;
let b:u32 = 1;
a += b;
```
How do you resolve the type of 'a' you must use inference variables and then update the TREE_TYPE as you go so this means walking the tree's over and over again as type information is gathered over time on the inference variable. Using a separate IR and using id's and side tables makes all of this much much more simple for Rust.
b3morales|3 years ago
philberty|3 years ago
Many things in Rust are syntactic sugar and can be handled by desugaring the AST into another IR so you dont even have to think about it in other passes. The main issue for me is how complicate the type inference is.
So if i wanted to use GCC GENERIC for type resolution for this example:
``` let a; a = 123; let b:u32 = 1; a += b; ```
How do you resolve the type of 'a' you must use inference variables and then update the TREE_TYPE as you go so this means walking the tree's over and over again as type information is gathered over time on the inference variable. Using a separate IR and using id's and side tables makes all of this much much more simple for Rust.