Currently, name resolution and type inference is based on the concrete syntax trees (and LocalSyntaxPtrs). This is suboptimal for three reasons:
One solution to this problem is to lower SyntaxNodes into a hir::Expr, defined as follows:
pub type Expr = Id<ExprData>;
#[derive(Eq, PartialEq)] // for salsa
pub struct ExprTable { // ExprTable for a specific item, most commonly function
exprs: Arena<ExprData>,
}
#[derive(Eq, PartialEq)]
enum ExprData {
/// This is produced if syntax tree does not have a required expression piece
Missing,
Path(hir::Path),
Binary { lhs: Expr, rhs: Expr, op: BinOp }
}
This representation is position-independent and salsa friendly. To be able to map to concrete syntas though, we'll need the following pair of queries:
// This one is syntax-dependent, we'll need to GC it
fn compute_def_expr_table(def_id: DefId) -> (ExprTable, FxHashMap<LocalSyntaxPtr, Expr>, FxHashMap<Expr, LocalSyntaxPtr>) {
}
// This is a salsa-friendly projection
fn def_expr_table(def_id: DefId) -> ExprTable {
compute_def_expr_table(def_id).0
}
I'll work on initial macro expansion support next, and after that I can do hir::Expr, if @flodiebold doesn't beat me to it :) I feel like we should introduce hir::Expr before diving too deep into type inference, so as to avoid rewriting too much of the match expressions
Here's some more random notes about this:
ParenExpr in HIRfor and while let loops into loop when lowering to its HIR, I'm not sure if we want to do the sameif let -> matchself params should probably be represented explicitly (i.e. &self should result in the same HIR as self: &Self etc.) (though that's not directly related to expressions, I guess...)hir::Pat for patterns at the same time (since they'll appear in match expressions etc.)ast::TypeRefs should be turned into hir::TypeRefs, of courseI'll have a go at this now.
This is done now.
Most helpful comment
I'll have a go at this now.