rustc_typeck: export modules and fields for sub-passes.

[eddyb]

Needed for driving parts of type-checking manually.

[rust-highfive]

r? @huonw

(rust_highfive has picked a reviewer for you, use r? to override)

[llogiq]

👍, this would really help with rust-clippy.

[nrc]

@bors r+ rollup

[bors]

📌 Commit 65f3067 has been approved by nrc

[pythonesque]

This seems like it will make it much harder to refactor typeck. Are we not worried about breaking its consumers at this juncture?

[llogiq]

For the record, I'm absolutely ok with any breakage until it's stabilized. Generally, I feel that if I use unstable APIs, even if publicly available, any breakage that may occur is my problem.

Btw. I found a way to implement my lint without requiring method lookup, at the cost of possible false positives, so the method lookup could be considered optional in this case. However, method lookup will still be quite useful for other lints – e.g. for suggesting methods or suppress warnings depending on availability.

[bors]

⌛ Testing commit 65f3067 with merge cfceeca...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt

[nrc]

@pythonesque no - just because it is public doesn't mean it is stable. Anyone who uses compiler internals should be prepared for breakage at any time.