[WIP] Don't re-export rustc_ast items in rustc_hir

[jyn514]

• BorrowKind
• ImplPolarity
• IsAuto
• CaptureBy
• Movability
• Mutability

While working on this I realized that there are many different enums
named BorrowKind, so it should really keep the prefix and just change
it from hir:: to ast::.

Partial fix for rust-lang/compiler-team#368.

r? @ghost - I still need to fix all the warnings and move BorrowKind back to ast::BorrowKind

[jyn514]

@bors rollup=never

This will cause a ton of conflicts.

[ecstatic-morse]

Please don't do this. Now every time I work with the HIR, I have to remember that Mutability is actually defined in rustc_ast? What are we gaining here? How does writing hir::ExprKind::AddrOf(ast::BorrowKind::Ref, ast::Mutability::Mut, e) make for better code?

[jyn514]

The goal is to reduce interdependence in the rustc_* crates by making it clear where things come from; hopefully this will allow us to remove some crates from Cargo.toml, making the build more parallel. I also think this will make it easier to split up rustc_middle (#65031).

Maybe rustc_hir was a bad place to start? Would you be ok with instead removing the pub use rustc_hir::Mutability in rustc_middle::mir?

[ecstatic-morse]

I don't care if my 20 minute compilation gets a few seconds faster if it becomes more difficult to write code.

hopefully this will allow us to remove some crates from Cargo.toml, making the build more parallel. I also think this will make it easier to split up rustc_middle.

I don't buy the first part. Luckily we have benchmarks for rustc on the perf server now, so there's no need to hope. These changes either make things faster or they don't. Compile times for rustc_middle are dominated by the query system. If you want to make the build meaningfully faster, look there.

[petrochenkov]

hopefully this will allow us to remove some crates from Cargo.toml, making the build more parallel

That is unlikely to happen with rustc_ast and rustc_hir though.
Also, if some pieces of AST are lowered to HIR trivially, then reexporting them instead of introducing new types will avoid extra work and extra code.

[jyn514]

Ok, this change is not super useful then.