You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently have these dada_id macros for creating the internal IRs. I dont' even know if they're documented anywhere in particular, but the idea is that you have a
tables -- maps from the id of a node to its data
origins (or spans) -- maps from the id of a node to its origin (e.g., span for a syntax tree, but we link BIR nodes to syntax tree nodes)
Creating a new node in this setup is kind of tedious. You have to create the id:
id!(pubstructFoo);
then declare a data
pubstructFooData{ ... }
implement DebugWithDb in this weird way, and then add those entries to two big macros, which in turn create various traits that allow you to do things like foo.data(tables) (or tables[foo], I haven't decided which I like better) and foo.origin_in(origins) (or `origins[foo]).
I think we can make this a LOT cleaner. I'd like something lke
/// declare each kind of node, along with its "data" type and origin, here in one consolidated placedeclare_ir!{(Expr,ExprData,Span),(Name,NameData,Span),
...
}// declare the data structs separately#[derive(...)]structExprData{ .. .}
and then probably pick one way to get data. If we adopt anchored spans (see #212) then we can be less careful with how we store data/spans (right now, I try to put spans in another field of a tracked struct, so that we don't "see" them unless we report errors).
I suspect the right answer is to have that macro generate a Ir struct and let you do expr.data(ir) and expr.span(ir), though ir[expr].fields is also appealing (the Index trait doesn't permit expr[ir].data, which I think I would like best).
The text was updated successfully, but these errors were encountered:
We currently have these
dada_id
macros for creating the internal IRs. I dont' even know if they're documented anywhere in particular, but the idea is that you have aCreating a new node in this setup is kind of tedious. You have to create the id:
then declare a data
implement
DebugWithDb
in this weird way, and then add those entries to two big macros, which in turn create various traits that allow you to do things likefoo.data(tables)
(ortables[foo]
, I haven't decided which I like better) andfoo.origin_in(origins)
(or `origins[foo]).I think we can make this a LOT cleaner. I'd like something lke
and then probably pick one way to get data. If we adopt anchored spans (see #212) then we can be less careful with how we store data/spans (right now, I try to put spans in another field of a tracked struct, so that we don't "see" them unless we report errors).
I suspect the right answer is to have that macro generate a
Ir
struct and let you doexpr.data(ir)
andexpr.span(ir)
, thoughir[expr].fields
is also appealing (theIndex
trait doesn't permitexpr[ir].data
, which I think I would like best).The text was updated successfully, but these errors were encountered: