Just use trees for HIR?

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.

Begin with the linked design document, then compare its proposed tree-based HIR API with the current syntax/HIR boundary described in the issue. Trace the existing entry points for semantic lookup, parent traversal, and macro expansion. Done means an agreed design and implementation plan; the issue names no target file or test.