Skip to content

Just use trees for HIR? #8713

Open
Open
@matklad

Description

EDIT: this now has a design doc: https://hackmd.io/@matklad/rJzQhvk2u/edit

One of our early design decisions was to keep all semantic info out of the syntax trees. I think that worked well for the compiler side of rust-analyzer -- we managed to do a bunch of relatively clear IRs, which are relatively incremental.

However, I am not so convinced that this split works quite as well for the hir API. When implementing, eg, assists, working with syntax is easy. Patterns like node.ancestors().find_map(ast::Expr::cast) are emerging nice idioms. Going from syntax to semantics and back creates a lot of friction, both because there are two layers to start with, and because the bridges between them are unclear.

So I am thinking, what if hir exported API which looked exactly as our syntax-tree based API, but with additional semantic info? So that, you can ask .type for an expression, .resolve for path, etc.

When you ask for .parent of a module/file, you transparently get the module in another file.

For macro calls, there are two children: .arg() and .expansion(), and .expansion() goes into another file.

Similarly, .parent transparently goes via expansion stack.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    Broken WindowBugs / technical debt to be addressed immediatelyC-ArchitectureBig architectural things which we need to figure up-front (or suggestions for rewrites :0) )

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions